4 ms·

> The middle road is simply a better engineering option, use a practical language that supports both paradigms. I recommend reading "The curse of the excluded

> The middle road is simply a better engineering option, use a practical language that supports both paradigms. I recommend reading "The curse of the excluded middle" paper by Erik Meijer on why this approach does not work.

red_admiral 2y ago
Functional programming has found its way into Java, where it works ok for some tasks; scheme/kotlin might advertise themselves as FP in the sense of "even more FP-ish than Java" but they're really mixed paradigm too, and not just because of backwards compatibility with other JVM libraries. We've made the middle road work. It is not the magical 10x speed upgrade that some managers hoped for if you just sprinkle some FP on top of the project like icing, but it works quite well in practice because you have the right tools for dealing with different kinds of subproblems. Meijer's paper is what I would call "FP maximalist". (Or "Haskell maximalist", as even OcaML manages without hiding all IO away in monads.) It's a defensible opinion to have, but doesn't have anything to do with the work environments that I have experience with.
raincole 2y ago
It was from 2014. In the past decade, we've seen "the middle way" has won. - Every mainstream OOP languages now support passing functions as parameters. - Optional type annotation became mainstream, e.g. Typescript and modern Python.
- the_af 2y ago
  > Optional type annotation became mainstream, e.g. Typescript and modern Python. It became mainstream indeed but, in my opinion, it's still a mess. Optional type annotations seem like the worst of every possible world to me, and it leads to unprincipled [1] developers to just not use them or use them so inconsistently it doesn't matter and we revert to "no type annotations at all". Just my experience, of course. ---- [1] which, in the wild, is the most common type of developer. And really, features should help with the most common developer, not the most principled ones.
  - mike_hearn 2y ago
    Typescript/Python aren't good examples of mainstream adoption of Haskell related ideas. Haskell always has types but has inference. A better example would be Kotlin or Swift style languages, where type inference is much more pervasive than in the past albeit deliberately limited so as to not be as extensive as in Haskell.
    - the_af 2y ago
      I don't think either Swift or Kotlin have "optional type annotations" of the sort mentioned in the comment I was replying to... In this context "optional" means "you can either use or not use type annotations", which is not related to type inference [1] but is a way to gradually add types, usually in a half-baked, unsatisfying way. [1] because unlike with Kotlin or Swift, there's no inference when you leave out the annotations, but instead you "switch off" static typechecking for portions of the code you don't want to annotate.
      - mike_hearn 2y ago
        Yes I know, but I think we're discussing the extent to which ideas from FP languages leaked into the mainstream? Optional-as-in-dynamic typing didn't come from the FP world, whereas optional-as-in-inferred did.
- mrkeen 2y ago
  In Haskell, you pay the penalty of using map-reduce style semantics ("why can't I just use for-loops which are so much simpler?") instead of mutation. But the benefit is you get your nice determinism properties. The middle-way languages adopted the penalties, but not the benefits. So the real winner was "lose-lose".
  - raincole 2y ago
    No. The middle-way languages didn't adopt functional programming's properties. They adopted the syntax. The syntax alone, even without the immunatbility and other properties from functional programming, is extremely useful to elimiate boilerplate like Observer and Strategy patterns.
- skitter 2y ago
  Optional type annotations are used to improve dynamical languages by adding static typing; we don't see static languages adding untyped places (there's type inference, but there's nothing dynamic about that).
- zelphirkalt 2y ago
  If that is all the points you make for the "middle way" to have won, then that way is actually not very middle, but still quite far towards OOP. FP needs FP data structures. Without those, any somewhat complex program will quickly desolve into very non FP style.
whizzter 2y ago
Most of the "horrible" examples in that paper are uncommon/unrealistic constructs to prove a point, yes there are real footguns in that are analogous to them but even with junior developers around I've yet to see many in practice.

red_admiral 2y ago

Functional programming has found its way into Java, where it works ok for some tasks; scheme/kotlin might advertise themselves as FP in the sense of "even more FP-ish than Java" but they're really mixed paradigm too, and not just because of backwards compatibility with other JVM libraries. We've made the middle road work. It is not the magical 10x speed upgrade that some managers hoped for if you just sprinkle some FP on top of the project like icing, but it works quite well in practice because you have the right tools for dealing with different kinds of subproblems. Meijer's paper is what I would call "FP maximalist". (Or "Haskell maximalist", as even OcaML manages without hiding all IO away in monads.) It's a defensible opinion to have, but doesn't have anything to do with the work environments that I have experience with.

raincole 2y ago

It was from 2014. In the past decade, we've seen "the middle way" has won. - Every mainstream OOP languages now support passing functions as parameters. - Optional type annotation became mainstream, e.g. Typescript and modern Python.

the_af 2y ago
> Optional type annotation became mainstream, e.g. Typescript and modern Python. It became mainstream indeed but, in my opinion, it's still a mess. Optional type annotations seem like the worst of every possible world to me, and it leads to unprincipled [1] developers to just not use them or use them so inconsistently it doesn't matter and we revert to "no type annotations at all". Just my experience, of course. ---- [1] which, in the wild, is the most common type of developer. And really, features should help with the most common developer, not the most principled ones.
- mike_hearn 2y ago
  Typescript/Python aren't good examples of mainstream adoption of Haskell related ideas. Haskell always has types but has inference. A better example would be Kotlin or Swift style languages, where type inference is much more pervasive than in the past albeit deliberately limited so as to not be as extensive as in Haskell.
  - the_af 2y ago
    I don't think either Swift or Kotlin have "optional type annotations" of the sort mentioned in the comment I was replying to... In this context "optional" means "you can either use or not use type annotations", which is not related to type inference [1] but is a way to gradually add types, usually in a half-baked, unsatisfying way. [1] because unlike with Kotlin or Swift, there's no inference when you leave out the annotations, but instead you "switch off" static typechecking for portions of the code you don't want to annotate.
    - mike_hearn 2y ago
      Yes I know, but I think we're discussing the extent to which ideas from FP languages leaked into the mainstream? Optional-as-in-dynamic typing didn't come from the FP world, whereas optional-as-in-inferred did.
mrkeen 2y ago
In Haskell, you pay the penalty of using map-reduce style semantics ("why can't I just use for-loops which are so much simpler?") instead of mutation. But the benefit is you get your nice determinism properties. The middle-way languages adopted the penalties, but not the benefits. So the real winner was "lose-lose".
- raincole 2y ago
  No. The middle-way languages didn't adopt functional programming's properties. They adopted the syntax. The syntax alone, even without the immunatbility and other properties from functional programming, is extremely useful to elimiate boilerplate like Observer and Strategy patterns.
skitter 2y ago
Optional type annotations are used to improve dynamical languages by adding static typing; we don't see static languages adding untyped places (there's type inference, but there's nothing dynamic about that).
zelphirkalt 2y ago
If that is all the points you make for the "middle way" to have won, then that way is actually not very middle, but still quite far towards OOP. FP needs FP data structures. Without those, any somewhat complex program will quickly desolve into very non FP style.

whizzter 2y ago

Most of the "horrible" examples in that paper are uncommon/unrealistic constructs to prove a point, yes there are real footguns in that are analogous to them but even with junior developers around I've yet to see many in practice.