Disappointed. This article is basically just tables of contents. No critical appraisal. No indication that the books were actually read or learned from.
Edit: for example, the "texas ranges" pun from LYAH is taken literally and presented as if Haskell has such a thing.
I've just started learning Haskell (and am currently about three-quarters of the way through the LYAH book). The single thing that has helped me the most was having spent a bit of time learning and programming in Elm last year. This gave me the opportunity to learn some of the foundational concepts and language characteristics that exist in both languages like immutability, higher-order functions, algebraic data types, programming without null, etc., all in a much more approachable environment.
Another vote for this. I started with Haskell through RWH and http://haskellbook.com/, and while I could write and understand code, I was really struggling with how to solve problems with Haskell.
Elm was just easier enough (but not too easy) that I could practice much more quickly. It also helped that I was writing a web app I could look at, rather than somewhat more contrived Haskell exercises.
After ~5 full days of Elm in my free time over a month or so, I came back to Haskell and found it much easier to get stuck into solving real problems.
Hmm ... this is a blog post listing the three usual free Haskell books. Why change its title "Master Haskell Programming with Free Books" to Open-source? First, this is against HN rules and second there is nothing open source there, these are free books.
One thing that has tripped me up trying to learn Haskell is that it always seems like each book has a different idea as to when particular aspects of the language should be introduced, and a lot of them are guilty of using more advanced constructs before explaining them. It's almost inevitable a Haskell text throws the IO monad at the reader and follow sit up with something like "Don't worry about what a monad is, we'll cover that later" Sure, I get it, we want people to understand their Haskell programs can actually do something, but I think introducing the instance before the concept in this case often makes things more mysterious and confusing than they need to be. perhaps it is because Haskell is so mathematical, but I feel as though a text book that presents Haskell almost in the form of a logical proof--i.e. shows how the concepts directly build upon one another--would make more sense than one that tries to approach the language like other traditional programming languages.
I also don't think most Haskell texts spend time acclimating the reader to the shift in thinking functional programming requires. Granted, that isn't the primary purpose of these books, but I think the difficulty in shifting the way one thinks about programs is the hardest part of learning Haskell--especially since Haskell is very functional in nature--more so than some other functional languages which are usually hybrids at least to a certain extent. Reading some more theoretical/general works on functional programming has helped me a bit in this regard, such as Functional Programming: Practice and Theory and An Introduction to Functional Programming Through Lambda Calculus
As far as books on Haskell go, I've found Real World Haskell to be the best--though it does cover a few topics too quickly in my opinion--it may almost be better as a second introduction to the language than a first. Haskell Programming from First Principles is also pretty good (not free).
I also wish Haskell texts would explain that all functions only take one argument earlier on. Most of them, with the noble aim of easing the reader in, present functions such as: `f :: a -> a -> b` early on and ask the reader to treat it simply as a function that takes two arguments. While this is nice at first, I think this approach only makes wrapping one's head around the one argument/higher order functions idea more difficult later when the author inevitably outs the first explanation as a white lie. Basically, you've understood a concept in one way and now you have to toss that understanding aside. What! You're just making more work for me. In the case of languages that require more or less a whole distinct framework of thinking about programs I'd rather tackle the difficult conceptual stuff up front so I can get used to thinking in a different way rather than delay this shift in thinking till the latest possible point and find out all my little toy programs and exercises were rather naive.
I think that's partly why some general texts on functional programming tend to be more effective--their focus is the conceptual shift in thought, not a language. With Haskell, I believe this shift in thinking is a necessary prerequisite, so It'd be good if Haskell books could integrate it more smoothly, or if necessary just state up front that if one does know the fundamental concepts underlying functional programming one should learn those first.
I've never been a huge fan of LYAH's method either. It is nice to have jokes, puns, and graphics peppered about the text, but I find it distracts me more than helps me. I'm also a bit wary about learning mathematical and logical concepts through analogy in general. It's often necessary when starting out, but a heavy reliance on analogy can really bite you in the long run since mathematics and logic have much to do with systemic relations and definitions, and it isn't always easy to res...
9 comments
[ 3.1 ms ] story [ 34.9 ms ] threadEdit: for example, the "texas ranges" pun from LYAH is taken literally and presented as if Haskell has such a thing.
You can get through the Elm tutorial in about a day. And the rest, is just playing around with the language in a trivial app.
Two weekends of Elm, followed by the the UPenn Spring '13 Haskell course are the smoothest Haskell learning plan I've seen.
Elm was just easier enough (but not too easy) that I could practice much more quickly. It also helped that I was writing a web app I could look at, rather than somewhat more contrived Haskell exercises.
After ~5 full days of Elm in my free time over a month or so, I came back to Haskell and found it much easier to get stuck into solving real problems.
http://cis.upenn.edu/~cis194/spring13/lectures.html
I also don't think most Haskell texts spend time acclimating the reader to the shift in thinking functional programming requires. Granted, that isn't the primary purpose of these books, but I think the difficulty in shifting the way one thinks about programs is the hardest part of learning Haskell--especially since Haskell is very functional in nature--more so than some other functional languages which are usually hybrids at least to a certain extent. Reading some more theoretical/general works on functional programming has helped me a bit in this regard, such as Functional Programming: Practice and Theory and An Introduction to Functional Programming Through Lambda Calculus
As far as books on Haskell go, I've found Real World Haskell to be the best--though it does cover a few topics too quickly in my opinion--it may almost be better as a second introduction to the language than a first. Haskell Programming from First Principles is also pretty good (not free).
I also wish Haskell texts would explain that all functions only take one argument earlier on. Most of them, with the noble aim of easing the reader in, present functions such as: `f :: a -> a -> b` early on and ask the reader to treat it simply as a function that takes two arguments. While this is nice at first, I think this approach only makes wrapping one's head around the one argument/higher order functions idea more difficult later when the author inevitably outs the first explanation as a white lie. Basically, you've understood a concept in one way and now you have to toss that understanding aside. What! You're just making more work for me. In the case of languages that require more or less a whole distinct framework of thinking about programs I'd rather tackle the difficult conceptual stuff up front so I can get used to thinking in a different way rather than delay this shift in thinking till the latest possible point and find out all my little toy programs and exercises were rather naive.
I think that's partly why some general texts on functional programming tend to be more effective--their focus is the conceptual shift in thought, not a language. With Haskell, I believe this shift in thinking is a necessary prerequisite, so It'd be good if Haskell books could integrate it more smoothly, or if necessary just state up front that if one does know the fundamental concepts underlying functional programming one should learn those first.
I've never been a huge fan of LYAH's method either. It is nice to have jokes, puns, and graphics peppered about the text, but I find it distracts me more than helps me. I'm also a bit wary about learning mathematical and logical concepts through analogy in general. It's often necessary when starting out, but a heavy reliance on analogy can really bite you in the long run since mathematics and logic have much to do with systemic relations and definitions, and it isn't always easy to res...