5 ms·

Fully functional programming (e.g. Haskell) isn't popular because it isn't ideal and computers work imperatively. Even in a "functional" task (e.g. compiling)

Fully functional programming (e.g. Haskell) isn't popular because it isn't ideal and computers work imperatively. Even in a "functional" task (e.g. compiling) sometimes you just want an imperative algorithm. And while Haskell allows this via state monads, they're clunky. Meanwhile there's practically no tradeoff to writing functional code in an imperative language. In fact there's lots of functional code in most C++/Java/Python programs. Most "imperative" languages are actually hybrid functional and imperative, supporting "functional" constructs like lambdas and pattern matching. 99% of the time a functional program will get executed sequential and strict anyways. The other 1% of the time, in an imperative language you can explicitly encode functionality (e.g. generic stream operators which work concurrently and on lazy streams).

cheeze 5y ago
Functional programming absolutely has its use cases, and I love a bit of functional style thrown into imperative language one hundred percent. That being said, I often end up arguing with 'pure functional programmers' at work - they can be incredibly hard to work with and married to the idea that _everything needs to be functional_ because its their preference, even though your average college student is going to be able to pick up and iterate on code that just uses a damn for loop or whatnot. I _like_ functional, I find it incredibly useful, but like everything else, its just a tool to solve a problem and there are tradeoffs. But some of the most annoying and must-do-things-academically-because-look-how-cool-monads-are this-is-the-only-proper-way people are very vocal about functional, which is a pretty big turnoff IMO. Haskell is a good example. There are totally cases where Haskell will make your life easier. But if you're trying to reinvent the wheel and redefine our architecture by injecting haskell everywhere you can because _you like it_, that drives me absolutely bonkers.
- jimmaswell 5y ago
  What are the use cases you've seen functional programming in real business?
  - pharmakom 5y ago
    Precisely modelling the business domain using immutable objects and pure functions is a killer feature of FP for the real world.
  - tephra 5y ago
    I'd imagine one of the more common use cases is data processing. At my last job I was part of a team that built a data processing platform and we did it in a mostly functional style.
  - dnautics 5y ago
    https://www.youtube.com/watch?v=yTkzNHF6rMs https://www.youtube.com/watch?v=yTkzNHF6rMs Of course this approach requires an impure functional language (so you can have side-effect calls).
- theCodeStig 5y ago
  Have you tried to see the pure FP viewpoint, rather than argue?
  - sweezyjeezy 5y ago
    I have personally been from an FP acolyte and back, there's some great stuff there, it will improve your non-FP code to learn an FP language. That said, bending over backwards to fit the FP mindset is suboptimal, the same way as writing fully OO code is. e.g. IMO some stuff from FP should _generally_ be avoided in favour of making code easier to read and debug - e.g. recursion, maps, monads, generators etc. etc.
lostcolony 5y ago
"Meanwhile there's practically no tradeoff to writing functional code in an imperative language." I would have to disagree with you there. It partly depends on what you mean, but I quickly give up on functional solutions in, say, Javascript (despite Javascript technically having all the bits I'd need!) just because of the lack of immutable data structures and cheap copying. Not to mention the constant pain point of asking "does this modify in place, or does it return a new" when dealing even with the standard library, let alone -user- code. I either need a library like Immutable.js, or I need to jump through hoops that are both not ergonomic, AND have performance penalties, or I embrace mutation (and at that point frequently rule out a fully recursive approach because the bookkeeping involved far outweighs any benefit).
- macintux 5y ago
  Agreed. Constraints (primarily in this context immutability) are invaluable. Writing functional, immutable style in Python is handy but can be maddening when you never know what to expect from libraries.
- eurasiantiger 5y ago
  > Not to mention the constant pain point of asking "does this modify in place, or does it return a new" when dealing even with the standard library, let alone -user- code I don’t see how this is a pain point, JS is pass-by-value for primitives and pass-by-reference objects. Ergonomics, sure, but isn’t the lack of pattern matching a much bigger obstacle the lack of immutable semantic sugar? Immutability is easy to gain, though, just make your variable object writable: false.
  - lostcolony 5y ago
    Because any recursive algorithm that needs to backtrack requires special care. That is, let's say I have a sodoku solver. I write a recursive solution wherein I guess the next value on the sudoku board based on the constraints. When an execution path completes and fails to be solved; my board is now populated with that 'bad' state, and I've lost the state I was in prior to the recursive call, at each level of recursion. I either need to make copies at every step (very unwieldy and inefficient), or explicitly write the 'undo' mechanism for each step. It's doable, but it's extra bookkeeping and logic to keep track of. Whereas immutable data structures give me an ergonomic and reasonably efficient way to maintain the prior state, and to create the next state. And, the mix of mutation and non-mutation constantly messes with me. Array.concat returns a new array, but Array.push() modifies the array in place. Array.slice returns a new array; Array.splice modifies the array in place. This -constantly- messes with me. The lack of a feature is just inconvenience that I work around. Having a mix of modalities causes me to trip over myself constantly.
mamcx 5y ago
I use F# a lot and like it, but imperative code was problematic to do. Now using Rust, I think I'm even more functional than ever. One key thing is that I can put a simple loop here and there (inside functions) and still the interfaces are functional.
- pharmakom 5y ago
  F# has mutable and while loops also. I’m surprised you are finding Rust good for functional programming to be honest. It lacks a do-notation system, currying by default and guaranteed tail-call optimisation.
  - mamcx 5y ago
    > It lacks a do-notation system, currying by default and guaranteed tail-call optimisation. And instead gives plain structs with separate impls, traits like Into/From that cut tons of custom-made transformation code, more uniform iterators (in F# some things not implement iterators that other things do, because everyone need to implement again all of them) and other idioms that are very practical. Is a tradeoff, sure.
phillipcarter 5y ago
> isn't popular because it isn't ideal and computers work imperatively. Eh, I think it has more to do with tooling and framework support. Imagine if the world were flipped and C++/Java/Python had zero IDE support, slow compilers, and weird/unreliable build and package management tooling, and only third-party bindings to any platform or framework. And Haskell had incredible IDE support, a fast compiler, great build and package management tooling, and official support for stuff everywhere you wouldn't have to think twice about using in a commercial context. You'd use Haskell.
sullyj3 5y ago
There are tradeoffs to writing functional code in langauges designed primarily for imperatively. Another comment mentioned efficiency. Another is that in a pure language, you can look at a function and know for a fact that nothing you're seeing can ever be mutated. This eliminates a massive source of cognitive load when trying to read and understand code, as well as eliminating all sorts of bugs related to the program being in the wrong state. If you're trying to write functional code in a language not designed for it, you're missing out on those benefits. Now, it's absolutely the case that the tradeoff may be worth making depending on the person and circumstance. But it does exist.
- Ginden 5y ago
  > Another is that in a pure language, you can look at a function and know for a fact that nothing you're seeing can ever be mutated. This eliminates a massive source of cognitive load when trying to read and understand code, as well as eliminating all sorts of bugs related to the program being in the wrong state. If you're trying to write functional code in a language not designed for it, you're missing out on those benefits. When you write functional code in imperative languages, these constraints aren't enforced by language, but they should be enforced by convention and code review.

cheeze 5y ago

Functional programming absolutely has its use cases, and I love a bit of functional style thrown into imperative language one hundred percent. That being said, I often end up arguing with 'pure functional programmers' at work - they can be incredibly hard to work with and married to the idea that _everything needs to be functional_ because its their preference, even though your average college student is going to be able to pick up and iterate on code that just uses a damn for loop or whatnot. I _like_ functional, I find it incredibly useful, but like everything else, its just a tool to solve a problem and there are tradeoffs. But some of the most annoying and must-do-things-academically-because-look-how-cool-monads-are this-is-the-only-proper-way people are very vocal about functional, which is a pretty big turnoff IMO. Haskell is a good example. There are totally cases where Haskell will make your life easier. But if you're trying to reinvent the wheel and redefine our architecture by injecting haskell everywhere you can because _you like it_, that drives me absolutely bonkers.

jimmaswell 5y ago
What are the use cases you've seen functional programming in real business?
- pharmakom 5y ago
  Precisely modelling the business domain using immutable objects and pure functions is a killer feature of FP for the real world.
- tephra 5y ago
  I'd imagine one of the more common use cases is data processing. At my last job I was part of a team that built a data processing platform and we did it in a mostly functional style.
- dnautics 5y ago
  https://www.youtube.com/watch?v=yTkzNHF6rMs https://www.youtube.com/watch?v=yTkzNHF6rMs Of course this approach requires an impure functional language (so you can have side-effect calls).
theCodeStig 5y ago
Have you tried to see the pure FP viewpoint, rather than argue?
- sweezyjeezy 5y ago
  I have personally been from an FP acolyte and back, there's some great stuff there, it will improve your non-FP code to learn an FP language. That said, bending over backwards to fit the FP mindset is suboptimal, the same way as writing fully OO code is. e.g. IMO some stuff from FP should _generally_ be avoided in favour of making code easier to read and debug - e.g. recursion, maps, monads, generators etc. etc.

lostcolony 5y ago

"Meanwhile there's practically no tradeoff to writing functional code in an imperative language." I would have to disagree with you there. It partly depends on what you mean, but I quickly give up on functional solutions in, say, Javascript (despite Javascript technically having all the bits I'd need!) just because of the lack of immutable data structures and cheap copying. Not to mention the constant pain point of asking "does this modify in place, or does it return a new" when dealing even with the standard library, let alone -user- code. I either need a library like Immutable.js, or I need to jump through hoops that are both not ergonomic, AND have performance penalties, or I embrace mutation (and at that point frequently rule out a fully recursive approach because the bookkeeping involved far outweighs any benefit).

macintux 5y ago
Agreed. Constraints (primarily in this context immutability) are invaluable. Writing functional, immutable style in Python is handy but can be maddening when you never know what to expect from libraries.
eurasiantiger 5y ago
> Not to mention the constant pain point of asking "does this modify in place, or does it return a new" when dealing even with the standard library, let alone -user- code I don’t see how this is a pain point, JS is pass-by-value for primitives and pass-by-reference objects. Ergonomics, sure, but isn’t the lack of pattern matching a much bigger obstacle the lack of immutable semantic sugar? Immutability is easy to gain, though, just make your variable object writable: false.
- lostcolony 5y ago
  Because any recursive algorithm that needs to backtrack requires special care. That is, let's say I have a sodoku solver. I write a recursive solution wherein I guess the next value on the sudoku board based on the constraints. When an execution path completes and fails to be solved; my board is now populated with that 'bad' state, and I've lost the state I was in prior to the recursive call, at each level of recursion. I either need to make copies at every step (very unwieldy and inefficient), or explicitly write the 'undo' mechanism for each step. It's doable, but it's extra bookkeeping and logic to keep track of. Whereas immutable data structures give me an ergonomic and reasonably efficient way to maintain the prior state, and to create the next state. And, the mix of mutation and non-mutation constantly messes with me. Array.concat returns a new array, but Array.push() modifies the array in place. Array.slice returns a new array; Array.splice modifies the array in place. This -constantly- messes with me. The lack of a feature is just inconvenience that I work around. Having a mix of modalities causes me to trip over myself constantly.

mamcx 5y ago

I use F# a lot and like it, but imperative code was problematic to do. Now using Rust, I think I'm even more functional than ever. One key thing is that I can put a simple loop here and there (inside functions) and still the interfaces are functional.

pharmakom 5y ago
F# has mutable and while loops also. I’m surprised you are finding Rust good for functional programming to be honest. It lacks a do-notation system, currying by default and guaranteed tail-call optimisation.
- mamcx 5y ago
  > It lacks a do-notation system, currying by default and guaranteed tail-call optimisation. And instead gives plain structs with separate impls, traits like Into/From that cut tons of custom-made transformation code, more uniform iterators (in F# some things not implement iterators that other things do, because everyone need to implement again all of them) and other idioms that are very practical. Is a tradeoff, sure.

phillipcarter 5y ago

> isn't popular because it isn't ideal and computers work imperatively. Eh, I think it has more to do with tooling and framework support. Imagine if the world were flipped and C++/Java/Python had zero IDE support, slow compilers, and weird/unreliable build and package management tooling, and only third-party bindings to any platform or framework. And Haskell had incredible IDE support, a fast compiler, great build and package management tooling, and official support for stuff everywhere you wouldn't have to think twice about using in a commercial context. You'd use Haskell.

sullyj3 5y ago

There are tradeoffs to writing functional code in langauges designed primarily for imperatively. Another comment mentioned efficiency. Another is that in a pure language, you can look at a function and know for a fact that nothing you're seeing can ever be mutated. This eliminates a massive source of cognitive load when trying to read and understand code, as well as eliminating all sorts of bugs related to the program being in the wrong state. If you're trying to write functional code in a language not designed for it, you're missing out on those benefits. Now, it's absolutely the case that the tradeoff may be worth making depending on the person and circumstance. But it does exist.

Ginden 5y ago
> Another is that in a pure language, you can look at a function and know for a fact that nothing you're seeing can ever be mutated. This eliminates a massive source of cognitive load when trying to read and understand code, as well as eliminating all sorts of bugs related to the program being in the wrong state. If you're trying to write functional code in a language not designed for it, you're missing out on those benefits. When you write functional code in imperative languages, these constraints aren't enforced by language, but they should be enforced by convention and code review.