[dawidloubser]

I guess the more succinct the code, the more the reliance on understanding what a function actually does - either through experience, or by reading the docs. The words function is simply:

  words :: String -> [String]

So that

  words "foo bar baz"
  -- Produces: ["foo","bar","baz"]

In my experience, both the blessing and the curse of Haskell's incredible succinct expressiveness is that, like other specialised languages - for example using latin for succinctly-expressed legal terms - you need a strong understanding of the language and its standard library - similar to the library of commonly used "legal terms" in law circles - to participate meaningfully.

Haskell, and languages like Go (which anybody with a bit of programming experience can easily follow) have very different goals.

Like many in this discussion, I too have developed a love/hate thing with Haskell. But boy, are the good parts good ...

[devjab]

I recently learned that things like Goroutines aren’t naturally written with buffers and channels. Granted anyone who reads the original documentation would likely do it correctly, but apparently that’s not how they are intuitively written. so while it may be easy to read it might be harder to write than I was assuming.

So maybe there a difference where Haskell has an advantage? I mentioned it in my previous comment but I don’t know Haskell at all, but if this is “the way” to do splits by word then you’ll know both to read and write it. Which would be a strength on its own, since I imagine it would be kind of hard to do wrong since you’ll need that Haskell understanding in the first place.

[instig007]

It all comes down to knowing the FP vocabulary. Most of FP languages share the names of the most widely used functions, and if you're well versed in Haskell you'll have 80/20 ratio of understanding them all, where the 20% part would be language-specific libraries that expand and build upon the 80% of the FP vocabulary.