This is a great observation. I’m a major fan of functional programming, but let’s be honest: imperative, sequential programming is far more intuitive. If you open a cookbook, a recipe is often given as a series of steps, with state (because the real world is stateful) and goto instructions all over the place. That’s actually fine, because on the small scale, imperative programming is actually more intuitive. This is why, when we show a Haskell one-liner along side ten lines of Java code and say, “See, the Haskell is more beautiful”, we’re actually only convincing the already converted; the people who are familiar with Java are going to see the Haskell as “line noise” and prefer the more verbose Java, because it better matches how they’re used to thinking.
The case for functional programming is that, at 50+ lines (much less 50,000+ lines) of code, or when you do need parallelization for performance reasons, unscrupulous imperative programming starts to break down in horrible and hard-to-track ways. Sequestered imperative programming with well-managed state is fine (see Haskell’s do-notation) but the default should be to use stateless interfaces as much as you can and, when state must exist (as, say, a performance optimization) to document the hell out of it.
To avoid the slightly inconvenient fact of imperative/sequential programming being more intuitive to most people, however, doesn’t work, just as selling functional programming as a negative (“it doesn’t have mutable state”) is not going to make our case, either.
It doesn’t surprise me that “one-pass” concurrent code is possible in Erlang, because I see the same thing when writing Go.
In reality, this just speaks to becoming comfortable with the means of abstraction and combination that the host language provides. When you start programming, everything goes in main() until you realize that functions can be used to avoid copy-paste bugs where you forgot to change a to b, and can group together x and y and associated operations into a class.
This is a great observation. I’m a major fan of functional programming, but let’s be honest: imperative, sequential programming is far more intuitive. If you open a cookbook, a recipe is often given as a series of steps, with state (because the real world is stateful) and goto instructions all over the place. That’s actually fine, because on the small scale, imperative programming is actually more intuitive. This is why, when we show a Haskell one-liner along side ten lines of Java code and say, “See, the Haskell is more beautiful”, we’re actually only convincing the already converted; the people who are familiar with Java are going to see the Haskell as “line noise” and prefer the more verbose Java, because it better matches how they’re used to thinking.
The case for functional programming is that, at 50+ lines (much less 50,000+ lines) of code, or when you do need parallelization for performance reasons, unscrupulous imperative programming starts to break down in horrible and hard-to-track ways. Sequestered imperative programming with well-managed state is fine (see Haskell’s do-notation) but the default should be to use stateless interfaces as much as you can and, when state must exist (as, say, a performance optimization) to document the hell out of it.
To avoid the slightly inconvenient fact of imperative/sequential programming being more intuitive to most people, however, doesn’t work, just as selling functional programming as a negative (“it doesn’t have mutable state”) is not going to make our case, either.
[Comment removed by author]
It doesn’t surprise me that “one-pass” concurrent code is possible in Erlang, because I see the same thing when writing Go.
In reality, this just speaks to becoming comfortable with the means of abstraction and combination that the host language provides. When you start programming, everything goes in
main()until you realize that functions can be used to avoid copy-paste bugs where you forgot to changeatob, and can group togetherxandyand associated operations into a class.