I think part of it is that there aren't many functional programming languages with a standard specification, multiple implementations, lots of users, an active research community, and where results of research feed into the implementations and the standard.

Haskell ticks all these boxes.

SML has most of those things, except the last: it was effectively frozen in 2001. This is discussed in section 9.3 of the HOPL IV History of Standard ML https://dl.acm.org/doi/10.1145/3386336

OCaml lacks a standard and multiple implementations, and seems to me to be doing better than SML in the other areas.

Isn't GHC the only full implementation of Haskell 2010? I am not sure how much the multiple implementations matter when there is only one full implementation of the last specification, which itself lags 10 year behind the only implementation massively used.

Haskell certainly is not the pinnacle in language design.

IMHO it is the first successfully implemented research language, though. I think that Haskell is the first language that, at the same time, had substantial commercial and research applications[1]. As such, it showed that the CS of PL is indeed of practical relevance.

Rust on the other hand, mostly applies this scientific research. And successfully so. Hence I call it the "engineering" part.

[1] To a certain degree this is also true for Lisp and SML, of course. But I think SML fell out of fashion quite quickly both in academia and industry. Lisp is, well, lisp. People that start using it seldom search for another language afterwards.

Having learned programming in those days, it feels really weird that now is fashionable to assert that Haskell === FP.

I can explain it this way:

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

> SML has many of those features

So does Java in 2020, but I was writing about:

>> 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.

> Modern Java(which looks more and more like an OCaml on the JVM)

Could you please elaborate on that? Is it related to the new features, like lambdas, pattern matching with switch and so on?

Algebraic Data Types (sealed classes/sum types + records/product types), pattern matching, local type inference. Moreover, Substrate VM (part of Graal) will help you achieve faster startup time and lower runtime memory overhead since it will be AOT compiled to a standalone executable, something that OCaml does right now.