4 ms·

Apparently, someone doesn’t really get what makes functional programming hard to understand? It’s not writing the occasional pure function. Code review or pair

Apparently, someone doesn’t really get what makes functional programming hard to understand? It’s not writing the occasional pure function. Code review or pair programming might help here, to learn the team’s common idioms.

IshKebab 1y ago
Yeah this 100%. FP isn't hard because of FP - it's all the other things that popular FP languages come with that makes them hard to understand. Arguably most of them are not related to FP; they're just style choices: 1. Global type inference. 2. Implicit syntax (no brackets for function calls, commas to separate arguments, semicolons to end statements/expressions, etc.) 3. Currying & point free style. 4. Tendency to have very deep nested expressions. The gap between `let foo =` and it's actual value can often be hundreds of lines. I'm sure you can write FP code that avoids these issues and is easy to follow but it doesn't seem like people do that in practice. Rust avoided all of these issues fortunately. (Oh I forgot about monads.)
- amluto 1y ago
  Also: avoidance of mutable state, even locally. A lot of functions can be more straightforwardly expressed using mutable variables and data structures, and most functional languages can handle local mutable state, but a lot of code in functional languages avoids it. Conversely, a lot of code written in imperative languages would be clearer and/or less bug-prone if it avoided mutable state and used persistent data structures. I wish there was a mainstream, high performance language that made both styles equally ergonomic.
  - deleted 1y ago
    [deleted]
  - delta_p_delta_x 1y ago
    > I wish there was a mainstream, high performance language that made both styles equally ergonomic. Unironically, C++.
    - ndriscoll 1y ago
      Or depending on what "high performance" means (e.g. if Java or Go would be considered acceptable), Scala.
    - Mond_ 1y ago
      > > I wish there was a mainstream, high performance language that made both styles equally ergonomic. > Unironically, C++. At best C++ falls under "equally unergonomic".
  - Philpax 1y ago
    Does Rust not meet that description?
    - amluto 1y ago
      Rust is very good at making things immutable. But that doesn't mean it's particularly fun to, for example, append or prepend something to a list and retain a reference to both the old and the new list. Compare to most "functional" languages, in which prepending an item to a list and ending up with immutable references to the old and new lists is almost the defining feature of the language.
      - IshKebab 1y ago
        Yeah although I find FP languages' obsession with singly linked lists to be a real flaw because they have such awful performance characteristics. And also pretty bad ergonomics often. The number of times stuff comes out backwards...
      - Mond_ 1y ago
        Considering the performance implications of a full commitment to immutable data structures, I think Rust does a pretty good job here. Dynamic arrays / vectors / slices or whatever you want to call them are probably the most important or fundamental non-plain-old-data data structure, and in a purely immutable environment these are essentially impossible (or have awful performance characteristics).
  - calebh 1y ago
    In my experience the main benefit of functional programming is function purity. I am completely fine with mutation inside of a function since the all of the mutation logic is self-contained in a single small block of text. I think everyone should take a shot at writing a non-trivial functional program to see the benefit. Once you understand what makes it great, you can apply what you've learned to the majority of OOP/impure languages.
  - brabel 1y ago
    Flix has "regions", which are a way to allow mutation locally while keeping the language purely functional otherwise: See Region-based Local Mutation in https://flix.dev/ https://flix.dev/
- jen20 1y ago
  Also the unwillingness of so many enterprise developers to learn anything that wasn't commonplace in 2001, regardless of whether they were in the workforce by then.
- elevation 1y ago
  > I forgot about monads I've been solving business problems with code for decades. I love pure, composable functions, they make my job easier. So do list comprehensions, and sometimes, map and filter. Currying makes sense. But for the life of me, no forum post or FP tutorial that I could find explained monads in clear language. I've googled "what is a monad" once a year, only to get the vague idea that you need monads to handle IO. I wondered if my brain was broken, but now I'm wondering if most FP adherents are simply ineffective communicators: they've got an idea in their head but can't/won't express it in a way that others after them can understand. In other words, the exact same reason why TFAuthor was corrected by his employer.
  - OhMeadhbh 1y ago
    https://www.bi6.us/CO/N/20250330.HTML#/033002 https://www.bi6.us/CO/N/20250330.HTML#/033002
  - vjerancrnjak 1y ago
    I felt similar with lenses. The problem lens solve is horrible. You don’t even want that problem. FP can be the pragmatic as well. You’re going to glue up monad transformers, use lenses like there’s no runtime cost, and compute whatever you need in days but at least you know it works. Maybe there’s accidentally quadratic behavior in lifting or lenses but that’s by design. The goal is to just throw software at things as fast as possible as correctly as possible.
    - AdieuToLogic 1y ago
      > I felt similar with lenses. The problem lens solve is horrible. You don’t even want that problem. Lenses abstract properties in a composable manner. How is this problem horrible? > FP can be the pragmatic as well. You’re going to glue up monad transformers, use lenses like there’s no runtime cost, and compute whatever you need in days but at least you know it works. Maybe there’s accidentally quadratic behavior in lifting or lenses but that’s by design. The goal is to just throw software at things as fast as possible as correctly as possible. Any abstraction can be used inappropriately. Slavish adherence to an approach in spite of empirical evidence is a statement about those making decisions, not the approach itself. In other words: A poor craftsman blames his tools.
- mrkeen 1y ago
  > (Oh I forgot about monads.) This demands an equivalent article which takes the same form as TFA. A coworker complains about monads, so the manager insists all monads be taken out. So Brian gets to work on the codebase, removing all Lists, Optionals, Streams, Functions, Parsers, Transactions, ...
jazzypants 1y ago
This is written by the same guy who made a big stink about how JS promises weren't pure monads and somehow that was a problem-- a zealot, in other words.
- frozenlettuce 1y ago
  well, promises' computations start as soon as they are created, so they are not composable. and there' no cancellation/resource control as well. so I guess that the criticism is valid

IshKebab 1y ago

Yeah this 100%. FP isn't hard because of FP - it's all the other things that popular FP languages come with that makes them hard to understand. Arguably most of them are not related to FP; they're just style choices: 1. Global type inference. 2. Implicit syntax (no brackets for function calls, commas to separate arguments, semicolons to end statements/expressions, etc.) 3. Currying & point free style. 4. Tendency to have very deep nested expressions. The gap between `let foo =` and it's actual value can often be hundreds of lines. I'm sure you can write FP code that avoids these issues and is easy to follow but it doesn't seem like people do that in practice. Rust avoided all of these issues fortunately. (Oh I forgot about monads.)

amluto 1y ago
Also: avoidance of mutable state, even locally. A lot of functions can be more straightforwardly expressed using mutable variables and data structures, and most functional languages can handle local mutable state, but a lot of code in functional languages avoids it. Conversely, a lot of code written in imperative languages would be clearer and/or less bug-prone if it avoided mutable state and used persistent data structures. I wish there was a mainstream, high performance language that made both styles equally ergonomic.
- deleted 1y ago
  [deleted]
- delta_p_delta_x 1y ago
  > I wish there was a mainstream, high performance language that made both styles equally ergonomic. Unironically, C++.
  - ndriscoll 1y ago
    Or depending on what "high performance" means (e.g. if Java or Go would be considered acceptable), Scala.
  - Mond_ 1y ago
    > > I wish there was a mainstream, high performance language that made both styles equally ergonomic. > Unironically, C++. At best C++ falls under "equally unergonomic".
- Philpax 1y ago
  Does Rust not meet that description?
  - amluto 1y ago
    Rust is very good at making things immutable. But that doesn't mean it's particularly fun to, for example, append or prepend something to a list and retain a reference to both the old and the new list. Compare to most "functional" languages, in which prepending an item to a list and ending up with immutable references to the old and new lists is almost the defining feature of the language.
    - IshKebab 1y ago
      Yeah although I find FP languages' obsession with singly linked lists to be a real flaw because they have such awful performance characteristics. And also pretty bad ergonomics often. The number of times stuff comes out backwards...
    - Mond_ 1y ago
      Considering the performance implications of a full commitment to immutable data structures, I think Rust does a pretty good job here. Dynamic arrays / vectors / slices or whatever you want to call them are probably the most important or fundamental non-plain-old-data data structure, and in a purely immutable environment these are essentially impossible (or have awful performance characteristics).
- calebh 1y ago
  In my experience the main benefit of functional programming is function purity. I am completely fine with mutation inside of a function since the all of the mutation logic is self-contained in a single small block of text. I think everyone should take a shot at writing a non-trivial functional program to see the benefit. Once you understand what makes it great, you can apply what you've learned to the majority of OOP/impure languages.
- brabel 1y ago
  Flix has "regions", which are a way to allow mutation locally while keeping the language purely functional otherwise: See Region-based Local Mutation in https://flix.dev/ https://flix.dev/
jen20 1y ago
Also the unwillingness of so many enterprise developers to learn anything that wasn't commonplace in 2001, regardless of whether they were in the workforce by then.
elevation 1y ago
> I forgot about monads I've been solving business problems with code for decades. I love pure, composable functions, they make my job easier. So do list comprehensions, and sometimes, map and filter. Currying makes sense. But for the life of me, no forum post or FP tutorial that I could find explained monads in clear language. I've googled "what is a monad" once a year, only to get the vague idea that you need monads to handle IO. I wondered if my brain was broken, but now I'm wondering if most FP adherents are simply ineffective communicators: they've got an idea in their head but can't/won't express it in a way that others after them can understand. In other words, the exact same reason why TFAuthor was corrected by his employer.
- OhMeadhbh 1y ago
  https://www.bi6.us/CO/N/20250330.HTML#/033002 https://www.bi6.us/CO/N/20250330.HTML#/033002
- vjerancrnjak 1y ago
  I felt similar with lenses. The problem lens solve is horrible. You don’t even want that problem. FP can be the pragmatic as well. You’re going to glue up monad transformers, use lenses like there’s no runtime cost, and compute whatever you need in days but at least you know it works. Maybe there’s accidentally quadratic behavior in lifting or lenses but that’s by design. The goal is to just throw software at things as fast as possible as correctly as possible.
  - AdieuToLogic 1y ago
    > I felt similar with lenses. The problem lens solve is horrible. You don’t even want that problem. Lenses abstract properties in a composable manner. How is this problem horrible? > FP can be the pragmatic as well. You’re going to glue up monad transformers, use lenses like there’s no runtime cost, and compute whatever you need in days but at least you know it works. Maybe there’s accidentally quadratic behavior in lifting or lenses but that’s by design. The goal is to just throw software at things as fast as possible as correctly as possible. Any abstraction can be used inappropriately. Slavish adherence to an approach in spite of empirical evidence is a statement about those making decisions, not the approach itself. In other words: A poor craftsman blames his tools.
mrkeen 1y ago
> (Oh I forgot about monads.) This demands an equivalent article which takes the same form as TFA. A coworker complains about monads, so the manager insists all monads be taken out. So Brian gets to work on the codebase, removing all Lists, Optionals, Streams, Functions, Parsers, Transactions, ...

jazzypants 1y ago

This is written by the same guy who made a big stink about how JS promises weren't pure monads and somehow that was a problem-- a zealot, in other words.

frozenlettuce 1y ago
well, promises' computations start as soon as they are created, so they are not composable. and there' no cancellation/resource control as well. so I guess that the criticism is valid