[IshKebab]

> FP is such a different paradigm than the leading imperative/OO design that most are comfortable with.

I don't think most of FP is at all hard for most programmers to understand. Hell I interviewed plenty of Javascript devs that couldn't solve a simple fizzbuzz level question because they didn't know how to do for loops - they only knew how to use `.forEach()`!

The hard bits in Haskell are:

1. Purity. I get it, but it definitely makes things harder.

2. Weird syntax: pervasive currying / single argument functions / lack of grouping syntax / waaaay too many operators, etc. E.g. from your link:

        let singlewords = words contents
            list = f singlewords

This is just a collection of words. No clue of what is a function call, what is a variable name, etc. Allow me to recreate the experience of reading Haskell, if you think the above is reasonable:

    file read lines put
    lines iter while cbr empty
    for do <~> x IO::print

3. General unfriendliness to people who aren't hardcore Haskellers. E.g. suppose I want to match a regex. In Go, Python, Rust, Javascript, etc. there's one obvious way to do it. Haskell? How about you pick between 8 alternatives... https://wiki.haskell.org/index.php?title=Regular_expressions

There are other flaws, like global type inference & lazy IO, but I think those are the main ones.

[trealira]

From the Haskell snippet, f is just "map read" specialized for lists of Integers, so inlining it would read like this :

  let list = map read (words contents)

The equivalent Python is basically this:

  list = [int(word) for word in contents.split()]

I'm just writing this for the benefit of others here.

[instig007]

> waaaay too many operators, etc.

Haskell doesn't have operators, it's based on expressions consisting of function compositions, some of which can be infix and look like operators.

> This is just a collection of words. No clue of what is a function call, what is a variable name, etc.

That's by design, because all of them are expressions that can either reduce immediately or require runtime data to reduce fully.

> How about you pick between 8 alternatives...

How about you pick either of those and start using for real, and then come to the point it either works well or you find inefficiencies to look specific alternatives for? It doesn't take much.