Live data from Hacker News

Why Haskell Is Worth Learning

spin.atomicobject.com

41–50 of 114 posts

Re: Why Haskell Is Worth Learning

#41
post #34
post #7

Earlier quoted context omitted.

At university the very first language we are taught is Haskell. Lots of people had never programmed before, in anything and everyone managed fine. Nothing scary at all, no need for an understanding of category theory or anything. Monads are (fairly) simple things that just have a really bad reputation, partly the fault of the haskell docs which make them seem complex. Firstly: Functors are things we can map over in a…

I know monads are supposed to be simple, but I've been playing with Haskell on and off for years now and I still can't figure out how do-notation desugars into >>= operations.

It's not intuitive, but it's straightforward once you understand the semantics. There are basically two cases. Case 1:

    x 
is rewritten as:

    monadicFunctionA >>= \x -> monadicFunctionB
The important thing here is that x is just the variable name in an lambda expression that you don't see. Case 2:

    monadicFunctionA
    monadicFunctionB
is rewritten as:

    monadicFunctionA >> monadicFunctionB
Where >> === >>= \_ ... . Given these rules, you can approximate do-notation like so:

    monadicFunctionA >>=
    \x -> monadicFunctionB >>
    monadicFunctionC ...

Re: Why Haskell Is Worth Learning

#42
post #19

Earlier quoted context omitted.

I felt that way up until last week! I somehow felt I was special, that cabal-hellfires had burnt a ring around me. Then next thing I knew I had a 4 page cabal conflict problem and had to just toast .ghc and .cabal and start over. It's a real problem.

Your response makes it sound like you just had a simple problem like you get with any language, and followed bad advice on solving it based on the assumption that "cabal is just bad and you have to do this". The big give away is that you didn't need to delete your .cabal directory, advice to do so is coming from someone who doesn't know the basics of how cabal works. It is just storing downloaded sources, all deletin…

You're right that I'm not very fluent on how Cabal works. It worked well enough that I didn't really need to until recently. I'm not claiming either that CPAN is better than Cabal. Could versioning be done better? Probably. I don't even claim to know enough to have a competent suggestion as to how, though.

Doesn't mean things don't break, though.

Re: Why Haskell Is Worth Learning

#43
post #40
post #19

Earlier quoted context omitted.

I felt that way up until last week! I somehow felt I was special, that cabal-hellfires had burnt a ring around me. Then next thing I knew I had a 4 page cabal conflict problem and had to just toast .ghc and .cabal and start over. It's a real problem.

you could look into hsenv and cabal-dev. https://github.com/cakesolutions/the-pragmatic-haskeller http://bob.ippoli.to/archives/2013/01/11/getting-started-wit... Also, problems in the haskell ecosystem don't stay problems for long, this one is the longer end of the tail http://alpmestan.com/posts/2012-11-02-cabal-hackage-what-you...

I do use .hsenv a lot, but for simple playing around with libraries (where I'm also most likely to hit major version overlaps) I liked to keep installing packages into the user level database.

Re: Why Haskell Is Worth Learning

#44
post #34
post #7

Earlier quoted context omitted.

At university the very first language we are taught is Haskell. Lots of people had never programmed before, in anything and everyone managed fine. Nothing scary at all, no need for an understanding of category theory or anything. Monads are (fairly) simple things that just have a really bad reputation, partly the fault of the haskell docs which make them seem complex. Firstly: Functors are things we can map over in a…

I know monads are supposed to be simple, but I've been playing with Haskell on and off for years now and I still can't figure out how do-notation desugars into >>= operations.

    do
      a
      rest
desugars to

    a >>
    do
      rest
and

    do
      x 
desugars to

    a >>= \x ->
    do
      rest

Re: Why Haskell Is Worth Learning

#45
post #42

Earlier quoted context omitted.

Your response makes it sound like you just had a simple problem like you get with any language, and followed bad advice on solving it based on the assumption that "cabal is just bad and you have to do this". The big give away is that you didn't need to delete your .cabal directory, advice to do so is coming from someone who doesn't know the basics of how cabal works. It is just storing downloaded sources, all deletin…

You're right that I'm not very fluent on how Cabal works. It worked well enough that I didn't really need to until recently. I'm not claiming either that CPAN is better than Cabal. Could versioning be done better? Probably. I don't even claim to know enough to have a competent suggestion as to how, though. Doesn't mean things don't break, though.

>Doesn't mean things don't break, though.

Right. The issue is that cabal has unfairly developed a reputation as being broken. People always say stuff like "every other language has this sorted out, why is haskell so bad at it?". When the reality is that the problems you get with cabal are the same ones you get with cpan or pip or anything else.

Re: Why Haskell Is Worth Learning

#46
post #29
post #25

I have to admit that I'm really on the fence about Haskell. My major gripe with this point I think is point (3). Haskell has (IMHO) gone down a similar road to Scala. Scala has literally tied itself into knots to make statically typesafe collections (amongst other things). I see parallels with Haskell (maintaining functionality purity but dealing with the "outside world" through monads). I'm not saying this is wrong.…

Haskell is also very simple--not from an implementation standpoint but from a semantics standpoint. Having polymorphism with no sub-typing (and no casting) is conceptually simple and easy to work with. Parametric polymorphism (like Java's generics but simpler and less horrible) is actually an extremely simple concept. The difficulty comes from a) implementing it in a stupid way after the fact ( cough Java) or b) havi…

It is an issue of the language's qualities if it does not really make it easier to reason about code.

I find reason to question the simplicity of something which is widely acknowledged to take a lot of time to learn, to be mind-bending, and which seems to be impossible to explain simply - without deep theoretical background, academic citations or oversimplifications acknowledged as misleading.

I think it would be mature for the Haskell community to occasionally acknowledge a trade-off of the language. Haskell's flaws are not all "social issues." The virtues of survivors like C and LISP are not all "social issues".

Re: Why Haskell Is Worth Learning

#47
post #7
post #5

Relevant points on Haskell, from another discussion, and sort of echoes my own thoughts: http://news.ycombinator.com/item?id=5314701 http://news.ycombinator.com/item?id=5314507

At university the very first language we are taught is Haskell. Lots of people had never programmed before, in anything and everyone managed fine. Nothing scary at all, no need for an understanding of category theory or anything. Monads are (fairly) simple things that just have a really bad reputation, partly the fault of the haskell docs which make them seem complex. Firstly: Functors are things we can map over in a…

Monads are fairly easily expressed in mathematics but trying to explain them conversationally appears to be an exercise in futility. There are dozens or hundreds of these explanations on the Internet and haven't seen one that hasn't been declared so wrong by the ones-who-know. (edit: and I'm not one-who-knows but I'm pretty sure "side effects might happen here" falls in this category). Classes, objects, functions, and so forth don't have these issues. There are nitpicks and minor variances between how different languages conceive these, but all seem to be fairly easy to explain and understand.

Re: Why Haskell Is Worth Learning

#48
post #25

I have to admit that I'm really on the fence about Haskell. My major gripe with this point I think is point (3). Haskell has (IMHO) gone down a similar road to Scala. Scala has literally tied itself into knots to make statically typesafe collections (amongst other things). I see parallels with Haskell (maintaining functionality purity but dealing with the "outside world" through monads). I'm not saying this is wrong.…

What Lisp are you talking about? If Lisp isn't simple, what is, then? Sure, if you want to become a skilled programmer in Lisp, it would take many years. But that is applicable to anything in life after all.

The original Lisp 1.5 Programmers Manual had 106 pages, including appendices and a glossary. Scheme specification is very small too.

It may be arguable that the lots of parenthesis is unappeling, but not that the language is complex.

Re: Why Haskell Is Worth Learning

#49
post #7

Earlier quoted context omitted.

At university the very first language we are taught is Haskell. Lots of people had never programmed before, in anything and everyone managed fine. Nothing scary at all, no need for an understanding of category theory or anything. Monads are (fairly) simple things that just have a really bad reputation, partly the fault of the haskell docs which make them seem complex. Firstly: Functors are things we can map over in a…

I'm curious what school you went to, there can't be a lot of universities that teach Haskell?

Glasgow University teaches Haskell to 2nd year students.

Re: Why Haskell Is Worth Learning

#50
post #46
post #29

Earlier quoted context omitted.

Haskell is also very simple--not from an implementation standpoint but from a semantics standpoint. Having polymorphism with no sub-typing (and no casting) is conceptually simple and easy to work with. Parametric polymorphism (like Java's generics but simpler and less horrible) is actually an extremely simple concept. The difficulty comes from a) implementing it in a stupid way after the fact ( cough Java) or b) havi…

It is an issue of the language's qualities if it does not really make it easier to reason about code. I find reason to question the simplicity of something which is widely acknowledged to take a lot of time to learn, to be mind-bending, and which seems to be impossible to explain simply - without deep theoretical background, academic citations or oversimplifications acknowledged as misleading. I think it would be mat…

Simple does not imply easy. As an extreme example, a unicycle is simpler than a bicycle--fewer components, simpler structure, no gearing--but also more difficult to learn.

Really, I'll just have to point you to the "Simple Made Easy" talk again. The core point being that there's a difference between something being "simple" and something being "easy", and we should generally strive for the former rather than the latter.

Having a deep theoretical foundation is also not a sign of complexity. Instead, like most of math, it's usually a sign of simplicity. After all, math always strives for elegance and simplicity.

What it means is that a lot of smart people have spent a lot of time thinking things through using a strict framework for reasoning that ensures everything is consistent. The theoretical framework lets us simplify by recasting different concepts using the same fundamental ideas. If we can capture things like state, errors and non-determinism using a single concept, we've made things simpler because now we have a common ground and relationship between seemingly disjoint ideas. This is exactly what Haskell (and the theory behind it) does.

This theoretical foundation, coupled with the relative simplicity and consistency of the language, actually make code much easier to reason about in Haskell than in other languages, except for some performance issues. Basically, as long as your main concern is in semantics--and, for 90% of your code, it is--Haskell makes life easier than any other language I know. You can manipulate the code purely algebraically, without worrying about what it does, and be content that the meaning remains the same.

Having well designed libraries with actual algebraic laws governing their behavior, a powerful type system and very transparent syntactic sugar is what makes the code particularly easy to reason about. A simple, elegant semantics also really helps. You can really see the influences of a good denotational semantics when using the language.

Now, reasoning about performance is sometimes an issue. It's certainly reasonably hard without additional tooling. Happily, there are some nice tools like criterion[1] to make life easier for you.

[1]: http://www.serpentine.com/blog/2009/09/29/criterion-a-new-be...

Also, the Haskell community does acknowledge trade-offs. They're just not the same trade-offs that people not knowing Haskell lambast. Which should not be a surprise--you can't expect somebody who hasn't really learned Haskell or its underlying ideas to have a thorough idea of what its real problems (or even its real advantages) are.

Post reply on HN