Hacker News Reader

Comment by xenomachina | Hacker News Reader

One thing this article doesn't really make clear is how someone reading the code can actually determine which of these things is being done. Code that looks the same but magically does something different doesn't seem like an improvement to anyone who wants to be able to maintain their code.

I know enough Haskell to know that the "magic" comes from which instance of Monad is being used, but between the weirdness of overloaded values, the fact that the "do" syntax doesn't really make it obvious which value is the important one, and Haskell programmers' aversion to using parens, I still find this stuff impossibly hard to read. This is largely why I gave up on Haskell after trying to learn it for 3 years.

View on HN

Well, the `do` syntax makes it patently obvious what is the important value, it is the one being assigned into variables within the block and used as argument of functions. It hides the not so useful one that is the name of the monad you are using.

You know the kind of "magic" by looking at the type declaration on the line just above that `do`. If there's no type declaration there, I hope the code is simple enough that it is self explanatory, otherwise it's plain bad code.

Things are made more complex when the monad type is generic. But then, this just makes it patently visible that the monad does not matter at all and the code must work as intended on any kind of "magic" you can throw at it.

About the aversion to using parens, matched operators make your code brittle and hard to change. This is not obvious if you have never seen any other way of organizing code, but it is a large effect.

> the `do` syntax makes it patently obvious what is the important value

Given that it seems that the majority of people who attempt to learn Haskell end up giving up, I'd argue that very little about it is "patently obvious".

> it is the one being assigned into variables within the block and used as argument of functions

I think this is part of what confounds me when it comes to Haskell (aside from the terrible syntax and horrible coding conventions): when I'm reading an expression I understand the overall expression by understanding what the sub-expressions do. That is, I can start at the leaves of the expression tree and work my way up to the root.

In Haskell, sometimes this is not possible, because sometimes the type of the subexpression is constrained by something higher up in the AST. This leaves me not knowing where to start with trying to decipher the type of an expression.

> About the aversion to using parens, matched operators make your code brittle and hard to change. This is not obvious if you have never seen any other way of organizing code, but it is a large effect.

What are "matched operators"?

The aversion to using parens means that I can't even parse code unless I know the fixity rules of all of the operators in an expression. I'm sure you'll say this is easy to pick up after a while, but that has not been my experience.

> In Haskell, sometimes this is not possible, because sometimes the type of the subexpression is constrained by something higher up in the AST.

The point is that this constraint always have the exact same format. It may have some different semantics, but Haskell makes you abstract over those to get into the operational function, while the compiler verifies anything that isn't local operations to fit your overall structure.

Really, learning Haskell is the process of learning to abstract semantics away from your code. It's a hard process, it's not something natural.

> What are "matched operators"?

Those are operators that require a matching. Usually parenthesis, square brackets and braces. Haskell has the unmatched operators `.` and `$` that people use instead, and for reading it you do have to understand their priority. Most operators do not a set fixity, but those two are a must.

> > In Haskell, sometimes this is not possible, because sometimes the type of the subexpression is constrained by something higher up in the AST.

> The point is that this constraint always have the exact same format.

I'm not sure how to even parse that sentence. Let me phrase as a question: when trying to understand a given piece of code, how can I determine the type of an expression when its type is someone determined by its sub-expressions (like virtually any other typed language), but sometimes is determined by what consumes it?

The way people can deal with the complex is by decomposing them into smaller parts, understanding those, and then composing that to understand the whole. It seems that in Haskell you are required to understand the whole thing at once, because you can't reliably determine the type of a sub-expression out of context.

> > What are "matched operators"?

> Those are operators that require a matching. Usually parenthesis, square brackets and braces.

And how do "matched operators" make code more brittle and harder to maintain?

I think the opposite is true: to maintain code you must first be able to read it, and what you call "matched operators" are far superior for readability compared to having to remember fixity rules. Even after 3 years of dealing with Haskell I found myself constantly misreading code because I didn't get the fixity right.

Could you please give a concrete example? The majority of Haskell expressions have what is called a "principal type". The type of such an expression is independent of its subexpressions or super- expressions.

A concrete example of what?

A concrete example of an expression that you have difficulty determining the type of.

It's been a few years since I gave up on Haskell, but I remember anything involving `do` (especially containing a `return`) or `sequence` seemed to require a lot of guesswork about what type was involved. Pretty much anything where the type of a subexpression would be an overloaded type has a high potential for being confusing.

Another example of what I'm talking about is the fact that even the expression "5 == 5" gives an error unless the kludgy type defaults are enabled. The fact that they felt the need to add type defaults and MR to the language is a pretty strong sign that they screwed up the usability of the type system.

Haskellers would tell you that what they appreciate about this is that you don't have to understand sequence and return! They do the "same thing" for all monads in the sense that they obey well-defined laws.

"5 == 5" is a different issue, and ironically is ambiguous because it's so simple. Most practical arithmetic expressions would have some way of disambiguating the type.

There are two answers I can think of:

1. You know what the code is doing to the extent that you know how monads work. As in, you know that you’re going to do some monadic action that returns a, then another one that returns b, etc. The code as written is generic so it’s not specified what the actions are.

2. And this is the much more common case; the code in question is being used within a particular context (I.e. for a particular monad that the programmer is working with) and the context makes it obvious what is actually being done by the monadic actions. Here the genericness is not in writing a function that can be used in multiple places, but in having a portable concept of “a pipeline of actions that return things and could fail” which you can use wherever you need it.

Type at point in an IDE helps. You can also use type holes and let the compiler infer types that you can use as a guide to fill in.

Yeah, I feel like a powerful enough IDE could probably make Haskell usable. Something that made the types obvious, and also the nesting of subexpressions. Despite trying for 3 years, I never felt like I could even reliably parse Haskell code in my head (too many fixity rules, not enough parens) let alone infer the types of things.

What resources did you use

What kind of resource do you mean?

It's been a few years now. I know I read LYAH, and I think also one of the O'reilly books. I used GHC and vim+syntastic. I used Hoogle for looking stuff up. I asked lots of questions on Stack Overflow, Reddit, and one of the IRC channels. Even after 3 years, everything with Haskell felt like rolling a boulder up a hill. The only reason I'd persisted as long as I did was because the idea of a purely functional statically typed language really appeals to me. Despite those features being what I've wanted in a language for decades, too much about Haskell makes it unusable for me.

I did learn some useful stuff in the process, but came away with the conclusion that virtually all of the good stuff in Haskell does not really need to be coupled to all of the terrible stuff in Haskell.

I think for some people (I suspect a tiny minority) of the people who attempt to learn Haskell, they get past the terrible stuff and either stop seeing it, or become brainwashed into thinking it's unavoidable/necessary. Perhaps it only works for the 5% of people who's brain happens to be wired the right way, I don't know. Most people, though, give up. To make matters worse, if you are not one of those people for whom the weirdness of Haskell "clicks", and you mention that parts of it make no sense to you, you'll get very little help from the Haskell community. Most will tell you things like "I use Haskell every day, and this doesn't bother me". Great.

That said, during the time I was trying to learn Haskell I did see some small improvements being made in the usability department. The biggest by far was that they finally turned off MR by default. Still, too little too late for me, so I ended up giving up on Haskell and moving on to other languages where I can actually understand my own code a day or two later.

As an aside, MR was a great example what's wrong with Haskell: 99% of the time the language designers don't seem to care about usability at all, but the 1% of the time they actually try to do something to help usability, their attempts completely backfire. map vs fmap is another example of this, though not nearly as horrendous as MR.

Reply on news.ycombinator.com