> Haskell’s core principles, like purity and isolation of side-effects, [are] understood and appreciated by more today than ever before
If I were to summarize what I think are the most important ideas in the modern functional programming world, I would start with purity and isolation of side-effects (and the mechanisms that have arisen to manage side-effects). However, it seems like most discussion about functional programming centers on type systems and most of what gets imported to other languages is just fancy ways to do iteration. Purity and side-effect isolation, it seems, is seen as a weird curiosity that must be broken in order to write Real Software (TM). It feels like I've slowly watched functional programming get lost in translation the same way object oriented programming was.
I'm sure the past decade or two of hype around FP has done some good to real code bases by exposing new ideas to developers who might never have seen them before, but I worry that in another ten years, I'll open up someone's code and find a nested callback hell where state mutations are impossible to track.
The nice thing of functional languages is the establishment of invariants. A large part of that lies in purity / isolated side-effects. However, much of it comes from the type system.
When ported to 'imperative' languages, those factors from the type system help establish invariant given that people don't use all the footguns. Whilst it is sad there are still footguns that can ruin your invariants, getting better types helps you move away from the footguns. Moreover, it is much harder to export purity to different languages than it is to export good type systems.
And really, the good thing that is being taken over is 'make it easier to reason about correctness through invariants'.
Functional languages don't establish invariants, invariants is an abstract math concept and math way of thinking. Side-effects, on the other hand, have an important place in programming and CS.
The functional notation really helps to establish a variant. In fact, most proofs of correctness for imperative programs essentially consider e.g. the body of a for loop to be a function.
I agree with you, but the point of the type systems is that they allow you to keep your purity while still giving the flexibility. A powerful type system is closer to a very powerful linter.
Example: it is fine to have internal state in pure functions, as long as that state doesn't break purity. Haskell's State Monad helps you ensure that. If you're doing FP in a multi-paradigm language, however, it's easy to make a mutation hell.
--
I think the problem with FP and OOP are never with the core concepts themselves, but rather the implementations in the form of multiparadigm languages. They make the escape hatches are too convenient and bad engineering is too accessible.
It took me a while to understand why types are so important coming from stateful programming languages but it's surprisingly simple. In a stateful language types are limited to expressions and statements are not typed. In a pure functional language, where there are no statements other than declarations, the whole program has an inherent type.
In a stateful language a complex type system will eliminate errors in some expressions e.g. "Oh, you tried to add a float number to a file handle!".
In a pure functional case a complex type system will eliminate composition errors in the whole program e.g. "Oh, you tried to throw an exception in the code which does not expect any exceptions!".
Naturally, type systems capable of typing a whole program tend to be more complex than ones only needed to type a single expression.
If I were to summarize what I think are the most important ideas in the modern functional programming world, I would start with purity and isolation of side-effects (and the mechanisms that have arisen to manage side-effects). However, it seems like most discussion about functional programming centers on type systems and most of what gets imported to other languages is just fancy ways to do iteration. Purity and side-effect isolation, it seems, is seen as a weird curiosity that must be broken in order to write Real Software (TM). It feels like I've slowly watched functional programming get lost in translation the same way object oriented programming was.
I'm sure the past decade or two of hype around FP has done some good to real code bases by exposing new ideas to developers who might never have seen them before, but I worry that in another ten years, I'll open up someone's code and find a nested callback hell where state mutations are impossible to track.