Learn You a Haskell for Great Good
learnyouahaskell.com
learnyouahaskell.com
I took a programming languages class taught in Racket, and by the end of that semester I felt like I had finally "gotten" what functional programming was all about.
Tried LYAH again and... it still didn't quite stick. Not sure why. But I was determined, because I'd heard about Haskell so much on the internet.
So I took a follow-up "class" where we just implemented projects in the functional languages of our choice, and I chose to do everything in Haskell. I asked my research advisor (I work in a PL research lab) for guidance, and that's when Haskell really started to make sense for me. I'm not sure why LYAH wasn't good for me, when it's touted as being a great starting place for so many people, but now Haskell is one of my favorite languages by far.
It's not. It's a terrible starting resource. Majority of people I anecdotally hear gave up on Haskell seem to mention LYAH. Yes the material is there, but it's not presented in a way that generally sticks and fits pieces together. I guarantee someone will reply to this thread and say it worked for them, but in general people seem to be unsuccessful with it.
There are better options out there.
Fairly sure it was recommended in here in the past and that's how I came to know it, can't give credit because I sadly don't remember.
[1]https://www.seas.upenn.edu/~cis194/spring13/lectures.html
Also this is one of the best references while you're learning (not good as a tutorial, but chock full of invaluable resources): http://dev.stephendiehl.com/hask/ . TBH I wish every language had an equivalent of this guide.
The beginner material in the Haskell WikiBook is pretty solid: https://en.wikibooks.org/wiki/Haskell
While not purely functional, I also recommend JacaScript Allongé.
Both are free online!
I also recommend reading these web documents as a supplement:
http://dev.stephendiehl.com/hask/
https://wiki.haskell.org/All_About_Monads
https://wiki.haskell.org/Typeclassopedia
https://www.fpcomplete.com/blog/2017/09/all-about-strictness
I am now reading Haskell High Performance Programming (https://www.packtpub.com/application-development/haskell-hig...), and while the book is more intermediate (it assumes that you can find the documentation and read the Haskell code yourself), I think it is a good overview of how to use modern Haskell in real projects.
Real World Haskell was the first book that made it to a wider audience. And while was is full of useful information, it is a very uneven book that works badly as an introduction to Haskell. We once had a reading group where we read RWH, most colleagues dropped out after the first 3-4 chapters.
In comparison, LYAH was a book that was far more straightforward as an introduction. And I know a few people that have gone through it cover to cover.
Although it's been a while since I read it, I really liked Graham Hutton's 'Programming in Haskell'. It was short & clear.
This is a bad statistic to use on its own. Imagine if I said "Majority of people I anecdotally hear gave up on web development seem to mention HTML". See the problem?
LYAH is not intrinsic to Haskell programming.
Imagine a hypothetical universe where all Haskell books are equally good, but some are more popular than others (maybe they have well known authors, or catchy titles, or are available for free online, or something). In particular, imagine Haskell Book Number 7 (HB#7 for short) gets 99% "market share".
Then if someone says "most people who gave up on Haskell used this book", you should not conclude that it reflects badly on the book. It's just a consequence of the book being popular, so it's the one people tend to try to use, so it's "the one that didn't work for them".
If you want to learn whether the book is better or worse than average, you need to split people into two groups: one group used this book, the other group used some other book, and compare which group does better. (Ideally, you should assign people to a group based on a coin flip, but even just looking at what happens "naturally" without your interference is better than nothing.)
Back to our non-hypothetical universe: LYAH does not have 99% market share, but it's pretty popular. I heard of it, and I've never looked for a book on Haskell. So to some extent the same logic applies.
As you say, though, LYAH is almost certainly not at 99% market share. It's definitely not at the 100% market share HTML has in Web development.
The universe is too complex to design a statistically-valid study for everything you want to know (though I definitely understand the urge to do that). At the end of the day, anecdotal evidence may not be great, but it's often better than nothing, and nothing is often the only other practical option.
True. The trick is to sort of mentally keep track of how much better than nothing it is, so you know which pieces of anecdotal evidence you can trust with only 40% confidence, and which you can trust with something more like 90%.
But yeah, definitely WAY better than nothing.
Also, learning Idris is another great learning exercise if you want to stretch the ways to think about programming.
I know this book isn't really popular (reading these comments) but to me it holds a lot of emotional value and I felt obligated to share my experience. I'll always be grateful for what this book taught me, and thankful to Miran for writing it.
For me too. I had some experience of FP and was also a PHP programmer. It's one of the funniest programming books I've ever read, references to Avril Lavigne amongst category theory appeals to my sort, but clearly it's not a book for everyone.
So I found it fun to learn and the concept of Applicative Functors in between Monoids and Monads has stuck. As well as the examples of monads, such as walking on a tight rope with birds landing either side.
I'm still not doing pure FP and so I forget much of the content, but its a pleasure to pick up and re-read.
In my opinion, Learn You A Haskell is a poor resource to learn the language and for some readers seems to be actually counterproductive (I have two friends who got through LYAH and then tried actually using Haskell, realized they have no idea how to actually use the language, and give up on Haskell altogether :( If only they'd used The Haskell Book...)
>This site can’t be reached >haskellbook.com refused to connect.
HN readers hitting the site?
LYAH however is a few days read. It lets you to get closer to start learning haskell, but not even in the same league.
LYAH is more appealing for early learners, since it's free.
LYAH may not be the greatest Haskell tutorial. But it makes an easy read. That means, you are not afraid to go back to it again and again, Which is the crucial aspect of learning anything sufficiently complex or new or both..
Lesson learned: don't fall for the marketing of art.
Generally the best way to learn is by actually doing projects: http://www.haskellforall.com/2017/10/advice-for-haskell-begi...
Half the examples contain jokes or cutesy animal sounds (onomatopoeia). I like jokes, but it is distracting me. Especially when I don't understand the cultural reference.
My biggest gripe with the book is that the examples can feel quite contrived. Its probably super hard to make a book featuring all concepts without having contrived examples. But I remember reading a chapter and some arbitrary abstraction is introduced. Problem is, based on that example, I don't realize when the abstraction is useful.
It might be impossible to write a Haskell book that is neither terse not unnecessarily verbose.
Since you can get some chapters for free, I'd recommend you just download them and see if you like the style.
Change it to http://www.haskellbook.com
I got started with Haskell Data Analysis Cookbook. As an experienced programmer, I LOVE the "cookbook" format. E.g., "Keeping and representing data from a CSV file" or "Examining a JSON file with the aeson package". If you need to actually USE the language, this is a great way to get started. Complete programs are shown.
Unfortunately, most books dive into the language _implementation_ instead of teaching its _interface_. (This probably points to a Haskell design weakness: deep learning of the impl. is nec. for success.)
But my REAL wish: Because I'm like many people and have experience with dozens of languages. I want books that leverage that knowledge and experience. E.g., to explain monads, just say it's an interface specification, and give the API. It'll make sense to me.
I understand the wish but I personally believe it is a bad idea. I think Haskell is just too different due to purity and laziness and trying to adapt your intuitions from imperative programming is going to mostly fail, badly. I suggest it's better to approach Haskell with a completely blank mind and learn the correct intuitions through just being very rigorous at the beginning.
I have written a bit of Haskell myself but I still get surprised by evaluation order, for example. But it has paid off, I think, it's a lot more understandable and modular and beautiful code that I write in Haskell than elsewhere.
Just jump to the bottom and go through as many pages as possible. Going through Functors, Applicatives, and only then Monads puts everything in a broader context and makes Monads easier to understand.
I think people should learn it for this exact reason -- it really does change how you program as well as thinking about programming even if on a daily basis you're not writing pure Haskell or Clean or Scheme or whatnot.
Common programming concepts like "iteration", "state", "formal methods", "parrallellism" are concepts that functional programming makes you reconsider from a new perspective.
Not necessarily by wrapping everything in IO monads in my non-functional code or anything like that. But trying to keep bits of business logic in pure functions (where possible, of course) sure makes my job easier.
Haskell is a very solid production language and you can put industrial grade software in Haskell out there, and it is in fact used by a fairly serious amount of companies at this point.
Instead of just taking Haskell features and porting them into already adopted languages, I'd really like to see more companies just go directly with Haskell, or Clojure, or Ocaml and F#. It does work.
Unfortunately there are some places where aspects of the standard infrastructure around Haskell block production application.
In particular, we have applications with very hard latency requirements and also with complex type/binding requirements (where a direct structural type system is needed):
But let that not be a pock on the overall great mission to make FP more accessible.
That being said, one should have looked at these:
- cabal Nix-style builds
- ghicd for continuous type-checking
- stylish-haskell for light code formatting
- brittany for slightly more invasive code formatting
- hlint for lintingIt is very much written by a (young) 20-something targeting other 20-somethings with a similar sense of humor. Came out in 2011, which puts the author at 24 years old. So ... you know.
Went to high school with the dude for 4 years. He's cool.
[0]https://www.manning.com/books/get-programming-with-haskellIt’s certainly not a book for the profane, despite its approachable aspect.
In addition, the IRC channel was immensely helpful along the way.
Nowadays I just use haskell for a few things at work or for toy projects, and the initial steps were taken with LYAH. (Beginner level though and I think I learned more from irc than the book in the end)
After all that, you will have an editor that can run/debug some Haskell.
Still, as a free resource it does cover some fun things. I just felt the book wasn't practical.
Here are some FREE Functional Programming (Haskell,Purescript)learning resources from 101 to building product: https://github.com/functionalflow/brains/projects/9
More, over 20 FREE FP books: https://github.com/allenleein/brains/tree/master/Zen-of-Func...
(no referral link)
I've used Rust, SML, and a bit of Scala so I don't feel like it should be that difficult to pick up Haskell. Next time I get the urge, I'll try Hutton's book.
Well it's fine for beginners, because beginners want easy explanations and many examples to start with, instead of very precise definitions which requires a precise math vocabulary.
If you're learning the basics of Computer Science you usually don't have to do this so Haskell is a great language then.
If you'd like to see for yourself what that course was like, here are lecture notes (and assignments, and mid-term exam): https://www.cmi.ac.in/~madhavan/courses/programming08/index....
Orwell (Haskell predecessor) was used later at Oxford, and I think ML at the other university. "Preparing to study Computer Science at Cambridge" once said "Teaching yourself to program can lead to your picking up bad habits that will hinder your progress later. In particular, you should avoid languages like C++."
Much of the language seemed like magic, but ANU had a culture of throwing students in the deep end to keep us humble about what we knew.
While LYAH may not be ideal, isn't calling it "terrible" a tad too harsh?
FWIW I learned Haskell using LYAH and enjoyed it thoroughly. It was my first time learning a language with such a high focus on functional programming, but I think this book did a good job of teaching it.
Some chapters are really basic and easy to read (like the chapter on recursion), and others are insanely dense and thick and basically unintelligible the first time through (like the chapter on functors).
We tried reading it for a book club once, and the weeks with the easy chapters there was no discussion to be had and the weeks with the difficult chapters ended up being "did anyone understand any of this?" and trying to figure it out together - which was somewhat helpful, but the book just really ended up being an excuse for us to learn together and not a resource in and of itself.
If anyone is familiar with it, Landau and Lifschitz is my kind of book ;)
EDIT: I've just skimmed the Hutton book. It looks great! That's what I mean. You don't have to be dense or incomprehensible or dry. Just stick to the point and explain as clear and concise as possible.
I rarely speak with enthusiasm... but teaching or explaining programming to people just gets me really, really excited. Putting myself in the shoes of a novice who is about to have some realization about the nature of an algorithm makes me shiver with anticipatory glee.
It's hard not to put that into my writing. It's not fake in the slightest—it's the only time I can let it shine through just how much I love this stuff, and it'd be fake to hide it. Even the constant "cute analogies" are part-and-parcel of this exuberance—symptoms of temporary hypomania brought about during the writing process.
Certainly, I could go back and edit all this stuff away. But, really, should I? I never had a role-model who was as excited about programming as I am. I wish I had had one. I, therefore, find it hard to restrain myself from being that person for others.
Definitely overstated and not good advice for beginners.
My advice to beginners would be:
- Read all the Haskell books available at your disposal. (In addition to LYAH and the Hutton book, I would say Learning Haskell From First Principles and Get Programming with Haskell are great, https://www.manning.com/books/get-programming-with-haskell, http://haskellbook.com/)
- When you hit something that doesn't make sense in one source, try referencing it in another source.
- When you have some experience writing programs in Haskell, refer to some older books like Real World Haskell. There may be a few issues compiling the examples, but nearly all the techniques in the book are still widely used and you learn about the language has progressed in the last few years. This gives you a compass to read and maintain older Haskell source code).
- Read as much Haskell code as you can from popular libraries (Pandoc, XMonad, and smaller libs as well).
1. Someone who has never programmed before, and is perhaps young. Someone who has to be guided. A novice.
2. Someone who is new to this particular language, but is experienced at programming generally; who is attempting to learn the language to use it "in anger" (i.e. with a specific goal in mind and a timeline for that goal); and who is willing to "do whatever it takes" to learn the skill. A journeyman beginning a new path.
A novice needs a definitive textbook. A journeyman-beginner, on the other hand, needs definitive primary sources, however scattered.
If you're a high-school student learning precalculus, what do you need? A math textbook.
If you're a post-graduate student learning some specific arcane sub-discipline of math to see whether it could be used to solve the novel problem you've decided to do your thesis on, what do you need? Primary sources. All the journal papers in that field you can get your hands on. There's no one textbook that could possibly help you; the only truth you will find is the truth "between the lines" of everything you read.
When I was first learning to code I can remember deciding to stick with one learning resource so as to not overwhelm myself. Eventually I hit a road block and wasn’t able to push past it. I blamed myself for not being able to understand what I was reading. I wasn’t smart enough.
When I tried again years later, instead of sticking with one resource I flicked between several different ones at once. Seeing how different people explained the same concept was extremely helpful in getting things to “click”.
Then again, Hutton's book seems legitimately criticized too for beginners looking at the reviews I'm seeing on Amazon with some preferring or suggesting LYAH as a needed complement. So to each their own.