If you were a Java/C/C# programmer in the 2000s, you missed out on:
* lambda abstractions
* Generics (prior to 2004)
* Higher-kinded Generics
* Primitives in Generic collections
* no nulls
* do-notation
* ML type system
* global, decidable type inference
* Pattern matching
* Functions as first-class objects
* Currying
* And most importantly *side-effect-free* functions
As a someone who picked up Haskell around 2010 as my first functional language, I liked what I saw, and I assumed that other functional languages were probably similar. My inner evangelist was all "You should use FP instead of Java, because lambdas are ergonomic", "You should use FP because nulls are bad", "You should use FP because functions are easier to test than methods".
Over the last decade I've realised that those statements aren't really truthful. Many functional languages allow null. Many functional languages won't enforce side-effect-free functions for you. So it was never really about FP, it was about Haskell. Anyway, that's how they got conflated in my mind.
SML has many of those features. Sure, Haskell popularized them, but it doesn't mean that computer scientists began studying these concepts only after Haskell became a thing
>> it feels really weird that now is fashionable to assert that Haskell === FP
When Googling "functional programming", you get back pages of definitions emphasising "pure functions", "no side-effects", "mathematical functions", "avoiding shared state", "referential transparency". So what Haskell provides is what the blogosphere has been labeling as "functional programming" for a decade. Those definitions could be wrong, but they're the definitions that are floating around out there.
