In my experience learning, teaching, and watching other people learn FP, it's far easier to learn FP with a language which is actually designed for it, e.g., Elm.

JavaScript isn't that. It carries too much legacy baggage. Too many gotchas; too many pointy bits. It's also just super noisy.

There's a reason why someone had to write The Good Parts. I don't buy the idea either that modern JavaScript is somehow devoid of the kinds of problems that existed when Crockford wrote that book. I mean, how many people still think that `const` gives you an immutable value?

n.b. I'm not sure why the Haskell snippet was included. It's confusing, and doesn't even make sense given that `main` is defined twice.

This is my experience as well. I had a co-worker that really pushed for FP in JavScript using Ramda.js. the principles were appealing, but because JavaScript doesn't have native syntax for many of the principles like pattern matching, you end up with hard to read code that's a bunch of nested arrays or chains wrapped in helper functions like "compose([fn1, fn2])(data)".

I later tried to learn F# and while the syntax was foreign, it turned out that it was MUCH easier to write FP code because the language had native operators for composition, etc. The code was also much easier to read.

I think it would be great if JavaScript got some FP syntax natively (see the pattern matching proposal). But hacking functional principals using arrays and helper functions just leads to hard to read code, especially for people not familiar with the specific FP library you chose to use.

Do you have a link to the pattern matching proposal? IMO if you added pattern matching and made everything (blocks, if-else, switch statements, etc) expressions then JavaScript would be pretty decent for writing in a functional style.