4 ms·

From my own experience, Haskell is hard to learn. I have no grounding in maths, but that hasn't stopped me learning most languages. It's a pretty massive barrie

From my own experience, Haskell is hard to learn. I have no grounding in maths, but that hasn't stopped me learning most languages. It's a pretty massive barrier to Haskell though, and I find that a lot of the community really struggle to explain things in terms that non-haskellers will understand. The biggest problem I've found is a real inability to explain _why_ the things it does are cool, or what real-world applications they have. I must admit that I also don't think it's a very pretty language. I like my code to be easy to read, and I just don't feel like Haskell fills that requirement. But that's obviously very subjective. At the end of the day, I've found Rust more fun to learn and use, so I've been putting my time into that lately. Haskell is cool, but the time investment is high and the community is small, and I like to build things, rather than spend hours trying to figure out what a string of symbols mean.

wink 8y ago
Sounds relatable. I've tried to have a look at it a couple of times and usually gave up. And it was never fun, and I usually enjoy trying out new languages a lot. My only positive experience was when I finally got something done in PureScript, which, for lack of knowledge, looks very similar. I especially detest languages with overly an overly "cryptic" alphabet of non-word modifiers, operators, etc. Perl was bad (but I've come to like it, 20 years later), Scala was worse and Haskell takes the crown with all the <*> and <=> and so on :|
wwwater 8y ago
I think it's hard to explain why the things it does are cool, because it's related to the aesthetic sense of beauty and it's very difficult to explain that one. It's like you take a person who is doing number theory, and you ask them to explain why they are so fascinated that you can approximate prime numbers distribution with a particular function. I think it's related to aesthetics of seeing how things are connected into a "bigger picture". It gives you an immense sense of beauty, once you are able to see that things, that you thought are not related, are connected into a bigger picture, and are actually very much related. In Haskell a lot of things are about this "bigger picture", while in many popular languages the things are just a bunch of practical tools, that have nothing to do with each other.
buvanshak 8y ago
> I just don't feel like Haskell fills that requirement.. About readability, Haskell in unreadable until you understand some basic precedence rules really well and until you internalize a hand full of things like function composition operator or the $ thing. Then it becomes extremely readable. Think of writing in shorthand [1]. For someone who does not know it, it looks quite cryptic. But once you internalize it, it becomes extremely concise and information dense. So it is a case of a big initial investment and low long term/usage cost vs low initial investment and much higher usage cost. So that, in a way answers the question raised by the post. Why hasn't Haskell taken over. It is because human beings are risk averse. ie we have preference for a sure outcome over a gamble with higher or equal expected value. [1] https://en.wikipedia.org/wiki/Shorthand https://en.wikipedia.org/wiki/Shorthand
- spronkey 8y ago
  Shorthand isn't necessarily a good act to follow, as most shorthand requires a solid understanding of context, and it's not uncommon that the person who wrote the shorthand is the only one who can completely understand it in original form. Personally, I'm familiar enough with Haskell to be able to slowly work my way through most code, but I'm not at the level where I would be confident in writing anything but simpler programs. I find idiomatic Haskell suffers from what I call "have to limit my line length-itis" - i.e. "Ord" instead of "Ordered", using "x" and "xs" as identifiers instead of e.g. "first" and "rest". This makes for compact code, but not necessarily very readable code. And for anyone who wants to tell me that it's closer to mathematic notation, well, frankly, maths could take a few hints from modern software engineering about readability. Then there's the dissonance between actually declaring an algorithm a la Haskell/FP, and actually describing how the algorithm works. It is sometimes nice to declare algorithms compositionally. This thing I want is the max of this joined on to five of these filtered by this criteria. Lovely. But opaque as to the implementation. I've found that in my experience with most software I write, the parts where the exact implementation isn't that important don't take a long time to implement. Immutability, idempotency, and removing side effects can work just the same in non-FP languages here. The other parts, which almost always involve some sort of IO, require very precise control over implementation, or state, or timing, and are often very difficult to declare with "is" - sometimes the only sensible way I can seem to think of them is a series of processes. When I try to implement this sort of thing functionally it feels like a retrofit, and never as elegant as the simple imperative "do this, then this, then that". I'm not trying to be anti-Haskell or anti-FP - I love and use FP principles every day. But I'm definitely in the camp that thinks "pure FP" is the best solution to only a small set of problems. To me, where Haskell fails is that it has very little to offer for these imperative problems. Which, for many applications, makes it almost worse than even a crappy old imperative lang.
addicted 8y ago
One of the issues I think with learning Haskell concepts are that once you learn and understand a certain concept, it becomes obviously easy. At which point it becomes difficult to relate with someone who doesn’t yet understand that concept, and to whom what seems intutitively obvious to you seems insurmountably hard.

wink 8y ago

Sounds relatable. I've tried to have a look at it a couple of times and usually gave up. And it was never fun, and I usually enjoy trying out new languages a lot. My only positive experience was when I finally got something done in PureScript, which, for lack of knowledge, looks very similar. I especially detest languages with overly an overly "cryptic" alphabet of non-word modifiers, operators, etc. Perl was bad (but I've come to like it, 20 years later), Scala was worse and Haskell takes the crown with all the <*> and <=> and so on :|

wwwater 8y ago

I think it's hard to explain why the things it does are cool, because it's related to the aesthetic sense of beauty and it's very difficult to explain that one. It's like you take a person who is doing number theory, and you ask them to explain why they are so fascinated that you can approximate prime numbers distribution with a particular function. I think it's related to aesthetics of seeing how things are connected into a "bigger picture". It gives you an immense sense of beauty, once you are able to see that things, that you thought are not related, are connected into a bigger picture, and are actually very much related. In Haskell a lot of things are about this "bigger picture", while in many popular languages the things are just a bunch of practical tools, that have nothing to do with each other.

buvanshak 8y ago

> I just don't feel like Haskell fills that requirement.. About readability, Haskell in unreadable until you understand some basic precedence rules really well and until you internalize a hand full of things like function composition operator or the $ thing. Then it becomes extremely readable. Think of writing in shorthand [1]. For someone who does not know it, it looks quite cryptic. But once you internalize it, it becomes extremely concise and information dense. So it is a case of a big initial investment and low long term/usage cost vs low initial investment and much higher usage cost. So that, in a way answers the question raised by the post. Why hasn't Haskell taken over. It is because human beings are risk averse. ie we have preference for a sure outcome over a gamble with higher or equal expected value. [1] https://en.wikipedia.org/wiki/Shorthand https://en.wikipedia.org/wiki/Shorthand

spronkey 8y ago
Shorthand isn't necessarily a good act to follow, as most shorthand requires a solid understanding of context, and it's not uncommon that the person who wrote the shorthand is the only one who can completely understand it in original form. Personally, I'm familiar enough with Haskell to be able to slowly work my way through most code, but I'm not at the level where I would be confident in writing anything but simpler programs. I find idiomatic Haskell suffers from what I call "have to limit my line length-itis" - i.e. "Ord" instead of "Ordered", using "x" and "xs" as identifiers instead of e.g. "first" and "rest". This makes for compact code, but not necessarily very readable code. And for anyone who wants to tell me that it's closer to mathematic notation, well, frankly, maths could take a few hints from modern software engineering about readability. Then there's the dissonance between actually declaring an algorithm a la Haskell/FP, and actually describing how the algorithm works. It is sometimes nice to declare algorithms compositionally. This thing I want is the max of this joined on to five of these filtered by this criteria. Lovely. But opaque as to the implementation. I've found that in my experience with most software I write, the parts where the exact implementation isn't that important don't take a long time to implement. Immutability, idempotency, and removing side effects can work just the same in non-FP languages here. The other parts, which almost always involve some sort of IO, require very precise control over implementation, or state, or timing, and are often very difficult to declare with "is" - sometimes the only sensible way I can seem to think of them is a series of processes. When I try to implement this sort of thing functionally it feels like a retrofit, and never as elegant as the simple imperative "do this, then this, then that". I'm not trying to be anti-Haskell or anti-FP - I love and use FP principles every day. But I'm definitely in the camp that thinks "pure FP" is the best solution to only a small set of problems. To me, where Haskell fails is that it has very little to offer for these imperative problems. Which, for many applications, makes it almost worse than even a crappy old imperative lang.

addicted 8y ago

One of the issues I think with learning Haskell concepts are that once you learn and understand a certain concept, it becomes obviously easy. At which point it becomes difficult to relate with someone who doesn’t yet understand that concept, and to whom what seems intutitively obvious to you seems insurmountably hard.