Laziness can muddy the waters, but it’s also optional in functional programming. People using haskell in a practical setting usually avoid it and are coming up with new language extensions to make strict evaluation the default (like in records for example).
What you’re really saying is the causal link between assembly and the language is less obvious, which is certainly true as it is a very high level language. However, if we’re talking about the causality of the language itself, then functional languages enforce a more transparent causal structure of the code itself.
You can be certain that a function that isn’t tainted by IO in haskell, for example, isn’t going to involve dozens of different causal structures. An imperative function like AnimalFactory.create(“dog”) could involve dozens of different dependencies (e.g. through singletons or dependency injection) making the dependency graph (and causal structure) obfuscated. This lack of transparent guarantees about state and dependencies in imperative languages makes concurrent/parallelprogramming (and even plain code) very difficult to reason about and test.
Moreover, the concessions that haskell has given way to are probably temporary. Haskell is a research language and functional solutions to problems like IO and event driven programs have been put forward but are not yet widely accepted. And even ignoring these solutions, you still have a basic paradigm where you have top level imperative style code with everything else being functional.
And while it can be more difficult to debug functional programs, they’re easier to test, and they’re less prone to runtime bugs. And really, the debugging problem is one of laziness and difficult to use debuggers. Debugging F# with visual studio’s debugger isn’t that difficult.
(Note: that when I talk about functional programming, I’m talking about a paradigm that avoids mutable state and data rather than idiomatic approaches to container manipulation)
Laziness can muddy the waters, but it’s also optional in functional programming. People using haskell in a practical setting usually avoid it and are coming up with new language extensions to make strict evaluation the default (like in records for example).
What you’re really saying is the causal link between assembly and the language is less obvious, which is certainly true as it is a very high level language. However, if we’re talking about the causality of the language itself, then functional languages enforce a more transparent causal structure of the code itself.
You can be certain that a function that isn’t tainted by IO in haskell, for example, isn’t going to involve dozens of different causal structures. An imperative function like AnimalFactory.create(“dog”) could involve dozens of different dependencies (e.g. through singletons or dependency injection) making the dependency graph (and causal structure) obfuscated. This lack of transparent guarantees about state and dependencies in imperative languages makes concurrent/parallelprogramming (and even plain code) very difficult to reason about and test.
Moreover, the concessions that haskell has given way to are probably temporary. Haskell is a research language and functional solutions to problems like IO and event driven programs have been put forward but are not yet widely accepted. And even ignoring these solutions, you still have a basic paradigm where you have top level imperative style code with everything else being functional.
And while it can be more difficult to debug functional programs, they’re easier to test, and they’re less prone to runtime bugs. And really, the debugging problem is one of laziness and difficult to use debuggers. Debugging F# with visual studio’s debugger isn’t that difficult.
(Note: that when I talk about functional programming, I’m talking about a paradigm that avoids mutable state and data rather than idiomatic approaches to container manipulation)