Hacker News Reader

Comment by rifung | Hacker News Reader

> It is extremely hard to learn, has an extremely confusing + needlessly complicated syntax and

I agree with your other points but what's wrong with the syntax? I actually really like the syntax for the most part

I've been using Haskell on and off for almost ten years, and the "front end" of the language, including its syntax, is pretty much the only thing that I absolutely hate about it.

The endless operators, all the language extensions required in 2019, the madness called Template Haskell, the absurdity of point free style, the multiple ways of achieving things by cleverly using . and $, the uncanny valley of do-notation (why does it look different? F# gets it right). It's too easy to be clever. It's too easy to take shortcuts that the next person won't understand.

I'm completely fine with the underlying semantics! Lazy evaluation, the majestic typechecker, concepts like monads, functors, lenses. Even when it comes to syntax, I love how functions are declared, the way parenthesis work, currying, all the "simple stuff". I adore all those concepts and apply them to other languages. I long for a Haskell-like language without the stuff I mentioned above.

I think the problem is that in Haskell everything feels like an afterthought, everything feels "bolt on" rather than "built in". 99% of the hot stuff is implemented using libraries. That's similar to Lisp and C++, other languages I hate (I also love Lisp parens, but I hate macros). Now that I think about it, I prefer less extensible languages that require adding code to the compiler to extend it: C#, F#, Go, JavaScript.

If you can have better solution to the problem at hand with the library, you will solve it faster. Turnaround time for library is much less than for a compiler.

So if language provides a way to solve something with a library instead of compiler, it provides a way for faster path to solution.

>but what's wrong with the syntax?

I'll just link to this blog about readable Haskell. If everyone followed his advise, it would be much better.

http://www.haskellforall.com/2015/09/how-to-make-your-haskel...

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 :(

Most people that have worked as developers/programmers/etc. that don't have a lot of exposure to or training in fp find it painfully hard to learn. This could be one of those cases.

To them, I would suggest that they remember back to when they learned their first imperative language like Java or C. For me, that was really difficult to wrap my mind around at the time, but now those languages are second nature to me. I kind of suspect that if everyone were exposed to a functional language first, there would be a lot fewer people who think they are extremely hard to learn.

I fondly remember being confused by “return” for weeks (granted, I was 9). What are you returning? And to where? And why was it only one thing? And where did it go when it got there?

It’s easy to forget how hard something was to learn once you already know it.

I remember when I started with Java at University.

Like, "hello, what is a method? What the hell is a class? Come on, stop kidding me, objects have methods???? How do I call them? Wait, how do I _write_ a method?"

What I kept bouncing off of was all the stupid as shit "sally sends a BUY message to Tommy's bagel shop" crap. I just needed about two to four pages worth of text & diagrams demonstrating how objects and structs are pretty much the same thing, and what the OO sugar inheritance and keywords and dynamic dispatch and such do under the hood, which ain't that complicated. Every single book I picked up (back in the '90s, when if you didn't know someone to personally recommend a book it was much harder to figure out which ones were decent and which sucked) wanted to use those awful, cutesy analogies to introduce OO and they just confused the hell out of me, and convinced me something dead-simple was hard.

There are many reasons Haskell is difficult to learn, and the functional programming aspects are only part of it. I'd venture a guess that it's vastly easier to go from say, python to clojure, than from python to haskell. Even neglecting clojure's impure escape hatches.

If you are learning something new and it isn't hard to learn then you are not learning anything truly new. Just variations/flavours of what you already know. If it is really hard then you are truly learning something new. No pain no gain.

Haskell syntax is great except for the indentation/layout rules. There is no simple definition of the grammar with regards to the layout. It's only specified as a headache-inducting operation of a state machine [1], and the implementation is quite hard to read. This is fine for writing Haskell, but quite painful if you want to parse it.

[1]https://www.haskell.org/onlinereport/haskell2010/haskellch10...

I'm not the OP but I would agree and my problem with the syntax is the number of symbols that don't make the semantics clear at all. The Lens library for example, but also a lot of standard stuff like the bind operator, it's extremely complex. Many people also seem to go overboard on the dot notation which can be very hard to read.

++ >> >>> >>= `concat` .

Reply on news.ycombinator.com