5 ms·

Functional programming alone is not very compelling. It's just a slightly different way of organizing your code and data, with different tradeoffs in terms of w

Functional programming alone is not very compelling. It's just a slightly different way of organizing your code and data, with different tradeoffs in terms of what code is easy and what code is hard. If all you do is present examples of using higher-order functions and algebraic data types, people will be pretty justified in saying "this doesn't really change anything important." And that's because it doesn't! Even in Haskell, once you learn the language, code is code. Sure, laziness means learning new ways to think about composing code, but that's just a small detail. In the end, the things that matter are same. Everything you know about performance optimization still applies. The only difference is the look of the code used to express it. You replace for loops with higher-order iteration combinators! Woo! It doesn't really change anything. You replace goto with recursion. Big deal! It's all the same thing. (At least in a language with proper tail-call elimination.) There is no giant breakthrough happening because there really isn't anything to break through... At least as long as all you care about is "functional programming". There are languages where more interesting things are going on than just functional programming, though. And those have actual promise for providing real benefits. Haskell has a type system that provides real benefits in terms of documentation and correctness. That is actually useful. But it's not "functional programming." So yeah. I don't care about functional programming. I care about things that are actually improvements.

Risord 7y ago
I don't either consider living without local mutable variables and loops as a clear improvement. But I do think that designing your application such way that it won't rely (or rely as little as possible) on spooky actions at a distance is.
- chowells 7y ago
  Sure, but that's a best practice in every language. Saying "this language makes you do the thing you swear you're doing anyway" doesn't sound like a practical difference. The second-order effect of "everyone has to do what you're claiming you do" is meaningful, yes. But it's really hard to convince programmers there's value there. Look how many people still say C is a fine language, you just have to not mess up. And not rely on any library that messes up. It's really tough to market the thing everyone should be doing anyway as a feature, even when the difference between "should do" and "is required to do" is huge in practice.
  - Risord 7y ago
    I like pragmatic definition of FP by Eric Normand: We recognize separation between data, calculations (pure functions) and actions (impure stuff) while using always simplest category. To me it seems like especially juniors would get benefit from this separations. So is it more like: "this language makes you do the thing that experienced programmers do once a while and juniors avoid [purity] at all costs". It would be interesting to see how juniors would work with functional(-first) language. Would they be able to craft same not-even-god-knows-what-it-does piece of art? What I have seen so far lot of side effects is typically required.
- johnisgood 7y ago
  Oh local variables in languages like Forth or Factor are handy. I have not yet gotten used to stack-shuffling. Will I ever? :D
  - Risord 7y ago
    Don't have experience about stack oriented languages nor sure is this relevant reply. But to clarify: local mutable variables are fine because effect of changing value is clear due well specified scope. Mutation is not observable from outside of a function. Opposite is true for using mutable data structures (with immutable variables): scope of effect must be checked manually, it's easy to leak function abstraction and with 3rd party code all the bets are off.

Risord 7y ago

I don't either consider living without local mutable variables and loops as a clear improvement. But I do think that designing your application such way that it won't rely (or rely as little as possible) on spooky actions at a distance is.

chowells 7y ago
Sure, but that's a best practice in every language. Saying "this language makes you do the thing you swear you're doing anyway" doesn't sound like a practical difference. The second-order effect of "everyone has to do what you're claiming you do" is meaningful, yes. But it's really hard to convince programmers there's value there. Look how many people still say C is a fine language, you just have to not mess up. And not rely on any library that messes up. It's really tough to market the thing everyone should be doing anyway as a feature, even when the difference between "should do" and "is required to do" is huge in practice.
- Risord 7y ago
  I like pragmatic definition of FP by Eric Normand: We recognize separation between data, calculations (pure functions) and actions (impure stuff) while using always simplest category. To me it seems like especially juniors would get benefit from this separations. So is it more like: "this language makes you do the thing that experienced programmers do once a while and juniors avoid [purity] at all costs". It would be interesting to see how juniors would work with functional(-first) language. Would they be able to craft same not-even-god-knows-what-it-does piece of art? What I have seen so far lot of side effects is typically required.
johnisgood 7y ago
Oh local variables in languages like Forth or Factor are handy. I have not yet gotten used to stack-shuffling. Will I ever? :D
- Risord 7y ago
  Don't have experience about stack oriented languages nor sure is this relevant reply. But to clarify: local mutable variables are fine because effect of changing value is clear due well specified scope. Mutation is not observable from outside of a function. Opposite is true for using mutable data structures (with immutable variables): scope of effect must be checked manually, it's easy to leak function abstraction and with 3rd party code all the bets are off.