> 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.
I recommend reading "The curse of the excluded middle" paper by Erik Meijer on why this approach does not work.
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.
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.
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.
The middle-way languages adopted the penalties, but not the benefits. So the real winner was "lose-lose".
FP needs FP data structures. Without those, any somewhat complex program will quickly desolve into very non FP style.
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.