Thanks. That's a good blog. The $ operator is definitely confusing in Haskell. F# uses <| to indicate a backward pipe, which I find much more intuitive. For example:

    print <| even <| 4 * 2

This means: Take the result of 4 * 2 and send it to `even`, then take that result and send it to `print`. Or you can write it with forward pipes to make it even clearer:

    4 * 2 |> even |> print

The thing about backward pipes is that they're often used to avoid parentheses, which is IMHO a good idea. It's just that thinking of them as "function application" is confusing. F#'s operators makes the data flow clear.

[Side note: The mathematical symbol for function composition is the circle operator, ∘, which is also confusing for the same reason. Does (g ∘ f)(x) mean g(f(x)) or f(g(x))? Personally, I can never remember. If math used F#'s >> and << composition operators instead, there'd be no doubt that f >> g sends the output of f to g, so (f >> g)(x) means g(f(x)).]

> The $ operator is definitely confusing in Haskell

I generally think of it as a sort of open-ended parentheses that encloses the rest of the line. Instead of a backward pipe. It means "evaluate everything after this character first then apply the preceding function to it" just like parentheses would.

    print $ even $ 4 * 2

is equivalent to

    print ( even ( 4 * 2 ))

You're right, and that's why it's usually called "function application" instead of "backward pipe". However, using $ as an operator is confusing because the associativity is ambiguous if you're not already comfortable with it.

> Does (g ∘ f)(x) mean g(f(x)) or f(g(x))?

The function composition operator can be vocalized as, in this case, "g after f". That is, apply the f and then g. Translating '∘' into 'after' is the easiest way to understand it.

Alternatively, I learnt it as "of" (from a mathematical standpoint). "(g ∘ f)(x) " is "g of f of x", so g(f(x))

Haskell provides the (g . f) notation as the standard, and also has (f >>> g) notation buried in one of its more advanced libraries if anyone finds the right-to-left reading too disorienting.

I don't see the above better than

    print(even(4*2))

Yeah, that's a small example, so it's fine either way. But larger examples with lots of parentheses can be overwhelming (see: Lisp).

Note that this is to make Haskell more readable to non-Haskell programmers (which is a bit of a weird goal IMO). It is not for readable Haskell in general. Advice like "not using $" just makes code less readable if you're familiar with Haskell and is quite frankly just bizarre. I do not think you'll find many programmers, Haskell or otherwise, who find lots of nested parenthesis to be the paragon of readability.¹

If the goal is to show snippets of cool Haskell code to other people this article is… fine I guess? But I don't think it's good for much more. Not even for teaching Haskell, since people should probably learn the language as it is used instead of some arbitrary "more readable to non-Haskell programmers" version. Using do-notation is probably even counterproductive for teaching since it obscures what's actually going on.

Honestly this sentiment from the Haskell community that Haskell is somehow bizarre and impenetrable to outsiders and needs to be somehow watered down so that normal people can understand it just feels extremely elitist and if anything only scares people away from Haskell.

―

¹ Lisp programmers aside, but even then in Lisp you're basically just drawing a tree and so the parenthesis kind of fade away, but in languages with infix syntax and operator precedence you can't ignore them.

>Note that this is to make Haskell more readable to non-Haskell programmers (which is a bit of a weird goal IMO). It is not for readable Haskell in general. Advice like "not using $" just makes code less readable if you're familiar with Haskell and is quite frankly just bizarre

This is why no one likes Haskell programmers and why the community just sucks.

You're telling me that it's _more difficult_ for a Haskell programmer to understand parentheses than for a non-haskell programmer to understand functors?

I can't think of a single haskell programmer that doesn't also know at least 2 C-style languages.

Meanwhile, there are many C-style programmers that don't know Haskell at all.

If the goal is to remain an impenetrable fortress / secluded monastery, the Haskell community is a safe bet for the Benedict Option[1]. But if the goal is to become popular and get others to understand the benefits of Haskell, it seems to be a culture problem within Haskell, more than anything else.

[1]: https://www.amazon.com/Benedict-Option-Strategy-Christians-P...

> This is why no one likes Haskell programmers and why the community just sucks.

I like most Haskell programmers and I don't think the community sucks more than any other language community. So I guess that proves that assertion wrong.

> If the goal is to remain an impenetrable fortress / secluded monastery

I am pretty sure there is no such goal :D

> if the goal is to become popular and get others to understand the benefits of Haskell

I am pretty sure that is a goal for some Haskell people and not for others. For me personally I had a lot of fun learning Haskell. It taught me to become a better developer in any programming language.

> Honestly this sentiment from the Haskell community that Haskell is somehow bizarre and impenetrable to outsiders

They’re not inventing that from thin air. I can understand Haskell with a great deal of effort, but it certainly requires a great deal of effort.

My wife is a non-programmer. She knows nothing about code. I could explain what the go code I write does in a few minutes and she could follow it with a minimum of hand waving. I don’t think I could explain any non trivial Haskell code in hours to even professional programmers

I have explained Haskell code in a few minuts to professional programmers and they got it. It took a bit longer to explain monads but it wasn't hours.

I have tried to teach C# to a smart non-programmers friend. That was really really hard. The idea of OO/classes just blew his mind.

I'd quibble with this, but that's probably largely because I used Hudak's "Haskell School of Expression" book as my road into Haskell, which seems to generally aim for readability at the expense of making everything into a monad. I gather it would be considered a bit of an outdated style now, but in retrospect I think it eased me into the pool.

> Honestly this sentiment from the Haskell community that Haskell is somehow bizarre and impenetrable to outsiders and needs to be somehow watered down so that normal people can understand it just feels extremely elitist and if anything only scares people away from Haskell.

What? The thread we're in is descended from a post about how terrible the syntax is!

Awesome advice! Thank you for the link.

Sadly, the author of “Haskell in production” breaks many of the rules in part 2 and code reads like ascii-art :(