What do you think?
Rate this book
Learn You a Haskell for Great Good!
Learn You a Haskell for Great Good! is a fun, illustrated guide to learning Haskell, a functional programming language that's growing in popularity. Learn You a Haskell for Great Good! introduces programmers familiar with imperative languages (such as C++, Java, or Python) to the unique aspects of functional programming. Packed with jokes, pop culture references, and the author's own hilarious artwork, Learn You a Haskell for Great Good! eases the learning curve of this complex language, and is a perfect starting point for any programmer looking to expand his or her horizons. The well-known web tutorial on which this book is based is widely regarded as the best way for beginners to learn Haskell, and receives over 30,000 unique visitors monthly.
176 pages, ebook
First published March 1, 2011
About the author
Miran Lipovača
3 books23 followersMost of his time is spent on doing nothing in particular, but when he's not doing nothing he's either programming, drawing, boxing or playing bass. He even has a cool bass tabs site. He also has a collection of stuffed owls and sometimes he talks to them and they talk back.
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 194 reviews
July 7, 2011
Properly learning Haskell has been on my todo list for years. One of my first more serious attempts was in 2009, when I found a weird little book with lots of cartoons online. As you may have guessed that was Miran Lipovaca's "Learn You a Haskell for Great Good" and I was immediately intrigued by the writing style and cute cartoons. However back then the book was still a work in progress and I eventually stopped reading it before Miran got around to adding the last chapters. I always promised myself to eventually revisit this later, so I was delighted when I found out that No Starch Press is actually releasing an offline version of the book!
LYAH definitely is among the top programming books I read so far. Due to the author’s easy-going and funny style — though I’m sure there will be some readers who won’t appreciate his humor — you might not even notice at first how choke-full of good content this book is, but once you are done with it you realize that you actually learned a lot. This would be an amazing feat for any technical book, but is even more impressive considering Haskell’s reputation as being a very academical and arcane language. Sure, not everything is covered here — Arrows or CPS come to mind — but every book is finite and the selection of topics is absolutely appropriate for beginning Haskell enthusiasts. The only chapter I wasn’t so happy with was the last one on Zippers, not because it wasn’t well written or interesting, but more because it felt a bit tucked on.
What can you expect from this book? Will you be a Haskell guru after reading it? Most likely not, because that takes a long time of practice and actually writing code. Maybe that’s one of the few weak points of LYAH, the code examples are usually rather short and focussed on getting the point across, not “real-world” tasks you are likely to encounter in day to day programming. They still are great for introducing the reader to Haskell’s way of abstracting problems, which I find immensely beautiful and well thought out. Still, a chapter or two on “programming in the large” and how to structure a big Haskell project would have been nice additions, but there are other places for learning more about the language, e.g. the Haskell wiki or the Haskell Wikibook. What the book will do for you is that once you are done with it, you should have a good basic understanding of the language’s key concepts and type system and will be comfortable around terms like “monoid”, “applicative functor” and “monad”. There still we be a long way to go before you can consider yourself a Haskell expert, but you’ll have a very solid grounding to build on.
All in all this is a remarkable book and maybe just what this beautiful language was missing, an easy to read, entertaining yet still thorough introduction to the language, that gives you an idea that Haskell is not only a research subject for computer scientists but a useful tool that can be used to build software.
LYAH definitely is among the top programming books I read so far. Due to the author’s easy-going and funny style — though I’m sure there will be some readers who won’t appreciate his humor — you might not even notice at first how choke-full of good content this book is, but once you are done with it you realize that you actually learned a lot. This would be an amazing feat for any technical book, but is even more impressive considering Haskell’s reputation as being a very academical and arcane language. Sure, not everything is covered here — Arrows or CPS come to mind — but every book is finite and the selection of topics is absolutely appropriate for beginning Haskell enthusiasts. The only chapter I wasn’t so happy with was the last one on Zippers, not because it wasn’t well written or interesting, but more because it felt a bit tucked on.
What can you expect from this book? Will you be a Haskell guru after reading it? Most likely not, because that takes a long time of practice and actually writing code. Maybe that’s one of the few weak points of LYAH, the code examples are usually rather short and focussed on getting the point across, not “real-world” tasks you are likely to encounter in day to day programming. They still are great for introducing the reader to Haskell’s way of abstracting problems, which I find immensely beautiful and well thought out. Still, a chapter or two on “programming in the large” and how to structure a big Haskell project would have been nice additions, but there are other places for learning more about the language, e.g. the Haskell wiki or the Haskell Wikibook. What the book will do for you is that once you are done with it, you should have a good basic understanding of the language’s key concepts and type system and will be comfortable around terms like “monoid”, “applicative functor” and “monad”. There still we be a long way to go before you can consider yourself a Haskell expert, but you’ll have a very solid grounding to build on.
All in all this is a remarkable book and maybe just what this beautiful language was missing, an easy to read, entertaining yet still thorough introduction to the language, that gives you an idea that Haskell is not only a research subject for computer scientists but a useful tool that can be used to build software.
August 26, 2017
The best intro to Haskell that I've seen - easy to understand, fun to read.
The main drawback - not so many practical examples, but this could be improved by reading Real World Haskell: Code You Can Believe In after this book...
The main drawback - not so many practical examples, but this could be improved by reading Real World Haskell: Code You Can Believe In after this book...
Read
October 22, 2019Excellent read, no matetr how much experience you have.
March 22, 2016
I don't usually send fanmail to writers of books I like, but after I finished this book I messaged this guy to say how much fun this book was to read and how much interest it created for me. It is as page turning as fiction. The writer did a very good job at making the content accessible and interesting, and at the same time addressing the readers as intelligent people (it's not a "for dummies" book) and going beyond scratching the surface.
June 18, 2020
Not everyone, including me, will appreciate the jocular style but the book is one of the best to teach functional programming and Haskell that I’ve seen so far.
Amazingly, it also manages to make the reader effortlessly grok the concept and applications of Monads. No mean feat, considering the numerous ‘Monad tutorials’ available on the web that try and often fail to do the same.
Amazingly, it also manages to make the reader effortlessly grok the concept and applications of Monads. No mean feat, considering the numerous ‘Monad tutorials’ available on the web that try and often fail to do the same.
August 22, 2014
Fantastic book, which sets a serious example of how programming books can be made both enjoyable and technically deep.
July 10, 2022
A central example of the Artful Coding Book, which attempt to sweeten a bitter pill with fun drawings, irony, or randomness. (See also why_, Eloquent JS, Land of Lisp, to some extent Zed's Hard Way. Haven't read Clojure for the Brave yet.) They track how indie and loveable the language is: no one ever wrote an Artful book about Java or C#.
The main problem is that Lipovaca spends so long on syntax and basic procedural stuff that you barely get a favour of what's distinctive about Haskell, type inference. But then the monads chapter is the best there is.
friendly and readable about a fearsome subject; to write this, Lipovaca had to give up the powerful rewards to austere superiority.
The main problem is that Lipovaca spends so long on syntax and basic procedural stuff that you barely get a favour of what's distinctive about Haskell, type inference. But then the monads chapter is the best there is.
friendly and readable about a fearsome subject; to write this, Lipovaca had to give up the powerful rewards to austere superiority.
November 25, 2017
The first couple of chapters are a mild introduction to some of the reasons Haskell is still worth a look and feels current today.
I rate this as 2 stars as a didn't like the language and writing style of the book. Feels authored by a 15 year old. Examples:
"Nobuffering usually sucks as buffering mode because it has to access the disk so much"
"It will get called with args (so ["todo.txt", "Spank the monkey"]).."
"for example, if someone runs todo UP YOURS HAHAHAHA"
I rate this as 2 stars as a didn't like the language and writing style of the book. Feels authored by a 15 year old. Examples:
"Nobuffering usually sucks as buffering mode because it has to access the disk so much"
"It will get called with args (so ["todo.txt", "Spank the monkey"]).."
"for example, if someone runs todo UP YOURS HAHAHAHA"
February 13, 2013
I would give even more stars to this book. The quote from the back cover is just right: "...you will not find a better way to learn this powerful language...". Of course, you should read a lot of other great books on Haskell (if you want to), but I think this should be the first one. Definitely, one of my favourite books. Just go and enjoy it, you won't regret!
December 23, 2018
Absolutely horrible, confusing and misinformating.
Unpopular opinion: this book sucks. No, it's not because I just did not understood it or some pretentious reason like that. Haskell is hard but not that hard if taught correctly.
It's because of the following reasons.
1) Tons of implicit cross-references. This book begins to use many concepts from the get-go not explaining how they work. Haskell has a lot of syntactic sugar, so guess what happens:
a) Book tries to familiarize you with a concept.
b) Book gives you an example which raises many more questions (because "what in the hell is happening here exactly"-factor).
c) You think you missed something but actually no, it's just explanations are half a book later.
2) Some things are just plain wrong. Check out the chapter about functors. The thing is -- list is not a freaking functor. The function that is applied to the list is. List is a 'Functor' typeclass, but explaining functors like list is a functor itself is like telling integers are "equalities" (whatever the hell it means), or "shows" or "reads" just because they are of typeclasses 'Eq', 'Show' and 'Read'.
If (2) didn't really made sence for you because you did not read the book think about it this way: there are interface-like entity in Haskell called "typeclass". They are named after functionality (verb-ish) they represent. Hence 'Functor' is an "interface" which is about "this type can be mapped with functor" and not "this type IS a functor".
And if this sounds complicated it's because it kind of is, espetially for newbies in FP, and to figure out what exactly author meant it took me some serious thinking. Even more, trying read and replace the terminology in the sentences to the correct one on the fly.
This is not how you write a book about coplex topics. Official documentation would've done better at sequentially explaining concepts of language, and it most likely would not have this kind of screw-ups with terminology and facts.
Don't. This book will get you as far away from Haskell as possible, never wanting to come back to it because it's confusing and strange. It's not. This book is.
Unpopular opinion: this book sucks. No, it's not because I just did not understood it or some pretentious reason like that. Haskell is hard but not that hard if taught correctly.
It's because of the following reasons.
1) Tons of implicit cross-references. This book begins to use many concepts from the get-go not explaining how they work. Haskell has a lot of syntactic sugar, so guess what happens:
a) Book tries to familiarize you with a concept.
b) Book gives you an example which raises many more questions (because "what in the hell is happening here exactly"-factor).
c) You think you missed something but actually no, it's just explanations are half a book later.
2) Some things are just plain wrong. Check out the chapter about functors. The thing is -- list is not a freaking functor. The function that is applied to the list is. List is a 'Functor' typeclass, but explaining functors like list is a functor itself is like telling integers are "equalities" (whatever the hell it means), or "shows" or "reads" just because they are of typeclasses 'Eq', 'Show' and 'Read'.
If (2) didn't really made sence for you because you did not read the book think about it this way: there are interface-like entity in Haskell called "typeclass". They are named after functionality (verb-ish) they represent. Hence 'Functor' is an "interface" which is about "this type can be mapped with functor" and not "this type IS a functor".
And if this sounds complicated it's because it kind of is, espetially for newbies in FP, and to figure out what exactly author meant it took me some serious thinking. Even more, trying read and replace the terminology in the sentences to the correct one on the fly.
This is not how you write a book about coplex topics. Official documentation would've done better at sequentially explaining concepts of language, and it most likely would not have this kind of screw-ups with terminology and facts.
Don't. This book will get you as far away from Haskell as possible, never wanting to come back to it because it's confusing and strange. It's not. This book is.
May 23, 2019
Ask me about Monads.
I'm transitioning to a Haskell project at work and decided to pick up this book in order to ramp up. I was in a Haskell course at university which did not get a lot further than higher order functions. Imagine my surprise when it turns out that's only when things start to get really interesting!
Many people associate Haskell with the arcane subject of "Monads". "So, do you understand Monads now?" is the first question many would-be Haskell programmers get when they talk to their not-so-functional friends about their journey learning Haskell. (I got this one quite a few times.)
As it turns out, explaining Monads is one of the things I think the book does really well. It does not try to jump into this matter too quickly at the expense of confusing many readers. Rather, the way to Monads is paved nicely through Functors, Applicative Functors and Monoids, such that by the time the reader arrives at Monads, they already have a sense of what's coming.
To keep this review short, let me summarizes some of the pros and cons in my experience:
What I liked:
- The relaxed and entertaining style of writing - entirely subjective.
- Fast pace of the book due to many examples, typically in increasing order of complexity.
- Building up to Monads through Functors, Applicative Functors and Monads. Makes one understand and appreciate the foundations more.
- An entire chapter devoted to exposing the user to many different Monads to really drill down the abstraction.
What could be better:
- Exercises. The book does not have any exercises, which means that at the end of the ride your knowledge could be surprisingly superficial if you do not complement your study with the necessary practical application.
- Real world examples. Reading this book will allow you to read and extend existing Haskell code. It will not necessarily set you up for writing a new production system from scratch, or for writing very idiomatic code. That requires a more thorough understanding of the standard libraries and what modern Haskell code looks like.
I'm transitioning to a Haskell project at work and decided to pick up this book in order to ramp up. I was in a Haskell course at university which did not get a lot further than higher order functions. Imagine my surprise when it turns out that's only when things start to get really interesting!
Many people associate Haskell with the arcane subject of "Monads". "So, do you understand Monads now?" is the first question many would-be Haskell programmers get when they talk to their not-so-functional friends about their journey learning Haskell. (I got this one quite a few times.)
As it turns out, explaining Monads is one of the things I think the book does really well. It does not try to jump into this matter too quickly at the expense of confusing many readers. Rather, the way to Monads is paved nicely through Functors, Applicative Functors and Monoids, such that by the time the reader arrives at Monads, they already have a sense of what's coming.
To keep this review short, let me summarizes some of the pros and cons in my experience:
What I liked:
- The relaxed and entertaining style of writing - entirely subjective.
- Fast pace of the book due to many examples, typically in increasing order of complexity.
- Building up to Monads through Functors, Applicative Functors and Monads. Makes one understand and appreciate the foundations more.
- An entire chapter devoted to exposing the user to many different Monads to really drill down the abstraction.
What could be better:
- Exercises. The book does not have any exercises, which means that at the end of the ride your knowledge could be surprisingly superficial if you do not complement your study with the necessary practical application.
- Real world examples. Reading this book will allow you to read and extend existing Haskell code. It will not necessarily set you up for writing a new production system from scratch, or for writing very idiomatic code. That requires a more thorough understanding of the standard libraries and what modern Haskell code looks like.
September 10, 2012
A very nice gentle introduction to the basics, but doesn't go into enough depth or provide enough examples when you start to get into the harder stuff. This is partly down to the learning curve of the language itself, but I feel like the style of the first few chapters just didn't apply as well to the later ones. Seems like a good starting point, I think I'll be trying 'Real World Haskell' after this.
I already have some experience with functional programming, so I can't say how well it might introduce those concepts to someone only used to an imperative style.
Haskell itself is very enlightening. I recommend every programmer to give it a go.
I already have some experience with functional programming, so I can't say how well it might introduce those concepts to someone only used to an imperative style.
Haskell itself is very enlightening. I recommend every programmer to give it a go.
June 10, 2017
I've read this book multiple times. It's a great introduction to Haskell, and pure functional programming in general. On top of everything, it's fun!
I really recommend it to any programmer. Learning Haskell is a powerful tool to expand your toolset and ways of thinking, and this book is a very good guide through the roughest parts of the process.
I really recommend it to any programmer. Learning Haskell is a powerful tool to expand your toolset and ways of thinking, and this book is a very good guide through the roughest parts of the process.
November 28, 2017
It is one of the best books I have ever read about a programming language.
October 20, 2014
Reviewing this again in the present, while it does help ease users into Haskell, it is not a great choice.
Some code samples use homophobic slurs or fat-shaming.
My recommendation: turn to Real World Haskell, or any of the many freely available sources for learning about Haskell.
Some code samples use homophobic slurs or fat-shaming.
My recommendation: turn to Real World Haskell, or any of the many freely available sources for learning about Haskell.
September 30, 2019
Best intro Haskell book... ever.
December 16, 2018
Now a Haskell wizard what's up
December 27, 2020
Good introduction to Haskell.
There comes a time in a programmer's life when, after hearing a lot about this "pure" language that's supposed to solve all the problems in other languages, one eventually gets their hands dirty and starts learning Haskell.
In this review I'll be writing both about the book itself and my experience with the language.
A. About Haskell:
1. The good
I think Haskell changed the way I see values forever. The concept of a monad is really cool. It's a value, wrapped in some context. You just have to focus on the value, and the context gets dragged along the way automatically....well, rather you need to think how you'll drag the context automatically along the way, but it's not that hard to do, and then you are free from NullPointerException kinds of things.
This is a really powerful paradigm, and maybe design patterns on top of more design patterns do that for you, but in this book at least (and maybe the language and its community), there's a large amount of effort to solve this NullPointerException problem. To be more specific, as not all readers will know what I'm talking about, in Haskell you can isolate the part where you check whether some function succesfully returned a value, from the part that actually implements your business logic. Magic? Yes!
UPDATE: I was about to complain about haskell's type system, and then I realized I was wrong. I will leave here both the rant and the followup.
Original rant: The type system can help but really I haven't seen it. In a sense, Java is very strongly typed as well. Sure maybe there are differences, but really when you want to add 2 integers together and add the wrong ones (or you actually were supposed to subtract them), there's no type system that can help you then. Sure, maybe I'm a complete ignorant, but after reading this book and writing a few hundred lines of code, I haven't seen significant advantages to Haskell's type system. Ok, it's more generic than Java's, but you still have to write code to make stuff happen, and your generic code can still ve wrong. What I'd have loved for haskell to have is a way to "clone" simple data types, so that their usual operations still work (+, -, concatenation, etc.) BUT so you can't mix the different types togethet (for instance so you can't add the height of a person with their bank account balance). If there's a way to do that that I don't know, I'd be grateful if someone shows it to me.
EDIT: I was completely wrong on the above comment on the type system. Type classes were introduced to solve this exact problem. You can actually even do 3 + 4 and have that be interpreted as `(MyType 3) + (MyType 4)` -> so you can actually prevent more classes of error than in Java, shightly easier too!
All kinds of lazy! Haskell is "lazy" in all kinds of ways. There's the example of the infinit lists [1..] (yup, from 1 up to infinity). Easy to imagine how that's done, as a lot of languages support the concept of iterator/enumerable/etc. In haskell however, even data properties are not determined unless used. To implement doubly linked lists however, one does this:
```
data Node =
Node {
d :: Int, --data
n :: Node, --next
p :: Node -- previous
} | Empty
-- this is needed when printing a node. We only print the next node, not the previous. If we printed both thr next and previous, a list with more that 2 nodes would expand into an infinite string when printed.
instance Show Node where
show Empty = "Empty"
show node = "Node {d=" ++ show (d node) ++ " n=" ++ show (n node) ++ "}"
-- create the list, take the first non-empty elem, get the next elem, go back to the previous elem, get its data, print it
main = print $ d . p . n $ createDLL [1,2,3]
createDLL :: [Int] -> Node
createDLL [] = Empty
createDLL xs =
let n0 = Empty
in new n0 xs
where
new parent [] = Empty
new parent (v:vs) =
let n1 = Node{
d=v,
p=parent,
-- HERE, MAGIC!
n=new n1 vs
}
in n1
```
Notice how the n attribute of a Node is set by calling a function with a reference to the yet unconstructed node - at least that's how you'd read that in non-lazy languages. In Haskell, it's simply that the `n` attribute is not created until it's needed, a while after the node and other attribute it has were created. So the node is created partially initialized, but the user never sees the incomplete initialization. This feature helps to compensate for the lack of mutability. With mutability, we'd
a. Create partially incomplete objects (missing the parent, for example)
b. Complete the initialization of these objects (setting their parent) a little later
....whereas in Haskell we
a. Create partially incomplete objects
b. Complete their initialization ON INSPECTION ONLY!!!
...so kind of the same thing really, but in a very different way.
2. The bad
Research - this language really is not designed to first and foremost be used by engineers to write code that solves problems. It's mostly there for functional programming researchers to implement research papers. That is at least a feeling I got after going through the documentation. A lot of features have only syntactic documentation (function signatures), and no examples what-so-ever. They mention the research paper that inspired the feature though, among the first things in the documentation. While that's fine and all, I think people approaching this language should have their expectations set properly.
IDEs don't help much. I haven't really tried playing with IDEs much, mostly because I was reading the book on my vacation. As such, I began writing code on repl.it/languages/Haskell -> but for now it has the disadvantage that is keeps refreshing and losing progress. Then I tried an app which did the job of allowing me to press "run" and showing me the errors ok. I'd love to get to use Visual Studio Code some more, but since I don't use VS Code myself, the learning curve would be steep. Wouldn't climb it unless I had to use haskell professionally. In any case, the one plugin I tried (whose name I forgot) was already not supporting the most current version of GHC. There's one more plugin I haven't tried, but that's the last hope.
Maps and sets implemented with trees. So instead of the awesome O(1) complexity, you get O(log(n)). It's not terrible, really, but worth mentioning.
3. The ugly
Docs.
Jokingly I like to put it like this
Q: "Daddy, daddy, what does 'condom' mean?"
A: "Contraception mechanism".
If you don't already know Haskell, it's really hard to find out what something is/does.
"Pure". I know it is just supposed to mean "side-effect-free", but it tickles me in the wrong way that a word with a rough meaning as "very good" is applied to a language, as it puts all the rest in a bad light. Also, it's not really pure, because in order to do anything useful, you need side effects. At best, Haskell could be said to separate easier side-effect-free functions from those that have side effects. Dunno, maybe it's just me, but "pure" pisses me off. It's just marketing. Like if someone used the words "free" or "smart" or "sacred" to brand a programming language. It's disrespectful to lots of other smart people.
B. About the book:
1. The good
It is a good start really.
2. The bad
Jokes. They're fun and all, but they get kind of boring after a while. Also when you're trying to figure out something hard, it's annoying to continue to see jokes. It's like when you're trying to study for an exam that's really hard, and someone's playing the music really loudly next to you. Loud music can be fun, but not necessarily at all times - same with the jokes.
Some examples don't work.
Writer monad - didn't work for me. Well, I had to implement it by hand and it was ok, but couldn't copy-paste the code and have it work. And you can't give credits to the author for me having learned something not because but in spite of the book! :p
Almost no env setup.
Lots of typos.
3. The ugly
Bashing on imperative languages. The author does that a lot and it's not funny. Not funny especially because he writes about implementing an algorithm in both imperative languages and Haskell, and makes fun of how in other languages you need to write so much more code....but when he describes the algorithm, the haskell description is longer. Fail :p
Conclusion: Really good book, I recommend it! Sure it's not perfect, but don't let that discourage you, you get a lot of value if you use this book and try to go along with the simple execises in it.
FYI, another book "Real World Haskell" is also free online, and has content that this one doesn't! (I'll pay for this one soon though, as soon as I figure out how not to get a physical copy of it)
There comes a time in a programmer's life when, after hearing a lot about this "pure" language that's supposed to solve all the problems in other languages, one eventually gets their hands dirty and starts learning Haskell.
In this review I'll be writing both about the book itself and my experience with the language.
A. About Haskell:
1. The good
I think Haskell changed the way I see values forever. The concept of a monad is really cool. It's a value, wrapped in some context. You just have to focus on the value, and the context gets dragged along the way automatically....well, rather you need to think how you'll drag the context automatically along the way, but it's not that hard to do, and then you are free from NullPointerException kinds of things.
This is a really powerful paradigm, and maybe design patterns on top of more design patterns do that for you, but in this book at least (and maybe the language and its community), there's a large amount of effort to solve this NullPointerException problem. To be more specific, as not all readers will know what I'm talking about, in Haskell you can isolate the part where you check whether some function succesfully returned a value, from the part that actually implements your business logic. Magic? Yes!
UPDATE: I was about to complain about haskell's type system, and then I realized I was wrong. I will leave here both the rant and the followup.
Original rant: The type system can help but really I haven't seen it. In a sense, Java is very strongly typed as well. Sure maybe there are differences, but really when you want to add 2 integers together and add the wrong ones (or you actually were supposed to subtract them), there's no type system that can help you then. Sure, maybe I'm a complete ignorant, but after reading this book and writing a few hundred lines of code, I haven't seen significant advantages to Haskell's type system. Ok, it's more generic than Java's, but you still have to write code to make stuff happen, and your generic code can still ve wrong. What I'd have loved for haskell to have is a way to "clone" simple data types, so that their usual operations still work (+, -, concatenation, etc.) BUT so you can't mix the different types togethet (for instance so you can't add the height of a person with their bank account balance). If there's a way to do that that I don't know, I'd be grateful if someone shows it to me.
EDIT: I was completely wrong on the above comment on the type system. Type classes were introduced to solve this exact problem. You can actually even do 3 + 4 and have that be interpreted as `(MyType 3) + (MyType 4)` -> so you can actually prevent more classes of error than in Java, shightly easier too!
All kinds of lazy! Haskell is "lazy" in all kinds of ways. There's the example of the infinit lists [1..] (yup, from 1 up to infinity). Easy to imagine how that's done, as a lot of languages support the concept of iterator/enumerable/etc. In haskell however, even data properties are not determined unless used. To implement doubly linked lists however, one does this:
```
data Node =
Node {
d :: Int, --data
n :: Node, --next
p :: Node -- previous
} | Empty
-- this is needed when printing a node. We only print the next node, not the previous. If we printed both thr next and previous, a list with more that 2 nodes would expand into an infinite string when printed.
instance Show Node where
show Empty = "Empty"
show node = "Node {d=" ++ show (d node) ++ " n=" ++ show (n node) ++ "}"
-- create the list, take the first non-empty elem, get the next elem, go back to the previous elem, get its data, print it
main = print $ d . p . n $ createDLL [1,2,3]
createDLL :: [Int] -> Node
createDLL [] = Empty
createDLL xs =
let n0 = Empty
in new n0 xs
where
new parent [] = Empty
new parent (v:vs) =
let n1 = Node{
d=v,
p=parent,
-- HERE, MAGIC!
n=new n1 vs
}
in n1
```
Notice how the n attribute of a Node is set by calling a function with a reference to the yet unconstructed node - at least that's how you'd read that in non-lazy languages. In Haskell, it's simply that the `n` attribute is not created until it's needed, a while after the node and other attribute it has were created. So the node is created partially initialized, but the user never sees the incomplete initialization. This feature helps to compensate for the lack of mutability. With mutability, we'd
a. Create partially incomplete objects (missing the parent, for example)
b. Complete the initialization of these objects (setting their parent) a little later
....whereas in Haskell we
a. Create partially incomplete objects
b. Complete their initialization ON INSPECTION ONLY!!!
...so kind of the same thing really, but in a very different way.
2. The bad
Research - this language really is not designed to first and foremost be used by engineers to write code that solves problems. It's mostly there for functional programming researchers to implement research papers. That is at least a feeling I got after going through the documentation. A lot of features have only syntactic documentation (function signatures), and no examples what-so-ever. They mention the research paper that inspired the feature though, among the first things in the documentation. While that's fine and all, I think people approaching this language should have their expectations set properly.
IDEs don't help much. I haven't really tried playing with IDEs much, mostly because I was reading the book on my vacation. As such, I began writing code on repl.it/languages/Haskell -> but for now it has the disadvantage that is keeps refreshing and losing progress. Then I tried an app which did the job of allowing me to press "run" and showing me the errors ok. I'd love to get to use Visual Studio Code some more, but since I don't use VS Code myself, the learning curve would be steep. Wouldn't climb it unless I had to use haskell professionally. In any case, the one plugin I tried (whose name I forgot) was already not supporting the most current version of GHC. There's one more plugin I haven't tried, but that's the last hope.
Maps and sets implemented with trees. So instead of the awesome O(1) complexity, you get O(log(n)). It's not terrible, really, but worth mentioning.
3. The ugly
Docs.
Jokingly I like to put it like this
Q: "Daddy, daddy, what does 'condom' mean?"
A: "Contraception mechanism".
If you don't already know Haskell, it's really hard to find out what something is/does.
"Pure". I know it is just supposed to mean "side-effect-free", but it tickles me in the wrong way that a word with a rough meaning as "very good" is applied to a language, as it puts all the rest in a bad light. Also, it's not really pure, because in order to do anything useful, you need side effects. At best, Haskell could be said to separate easier side-effect-free functions from those that have side effects. Dunno, maybe it's just me, but "pure" pisses me off. It's just marketing. Like if someone used the words "free" or "smart" or "sacred" to brand a programming language. It's disrespectful to lots of other smart people.
B. About the book:
1. The good
It is a good start really.
2. The bad
Jokes. They're fun and all, but they get kind of boring after a while. Also when you're trying to figure out something hard, it's annoying to continue to see jokes. It's like when you're trying to study for an exam that's really hard, and someone's playing the music really loudly next to you. Loud music can be fun, but not necessarily at all times - same with the jokes.
Some examples don't work.
Writer monad - didn't work for me. Well, I had to implement it by hand and it was ok, but couldn't copy-paste the code and have it work. And you can't give credits to the author for me having learned something not because but in spite of the book! :p
Almost no env setup.
Lots of typos.
3. The ugly
Bashing on imperative languages. The author does that a lot and it's not funny. Not funny especially because he writes about implementing an algorithm in both imperative languages and Haskell, and makes fun of how in other languages you need to write so much more code....but when he describes the algorithm, the haskell description is longer. Fail :p
Conclusion: Really good book, I recommend it! Sure it's not perfect, but don't let that discourage you, you get a lot of value if you use this book and try to go along with the simple execises in it.
FYI, another book "Real World Haskell" is also free online, and has content that this one doesn't! (I'll pay for this one soon though, as soon as I figure out how not to get a physical copy of it)
October 3, 2018
This unassuming book is a smart introduction to Haskell, a programming language that is notoriously hard to learn, since it's so different from mainstream languages. At the time when it was published, the landscape for Haskell texts, especially for beginners, was relatively sparse. The only other introductory book directed towards practical daily work was Practical Haskell, a text with its own problems (see my review of it). This book filled, and is still filling, the gap for texts that give one a taste of the language, without getting too deep into the hairy bits of the language. The problem is, Haskell has a lot of hairy bits; more about this later.
The first few chapters cover the basics of what sets Haskell apart from most other languages: list processing, functional programming,the type system. The book does a particularly good job of explaning laziness, a feature of Haskell really rare among other languages. Functional programming is mostly explained with the example of functions that are already in the code base, such as takeWith or filter. In addition to this, many toy examples are employed, which is kind of annoying, but one has the feeling that the main aim of the book is not to get the developer to do, say, systems programming with Haskell, but get acquainted with its fundamental ideas.
After the easy bits with sum types and walking trees and such come the hairy bits of Haskell. The first is, you guessed it, IO. IO notoriously uses monads, one of the central abstractions of Haskell that is a pain to understand. In the Haskell type hierarchy, monads come rather late, but IO is very important for programming, so there is no point in putting it at the end of the book. For this reason, the author chooses to introduce the IO monad without making a big fuss of monads. Instead, the simple operations are explained in a "this is how you do it, don't care about the rest" manner. This attitude is common to many other Haskell texts, but it's still a bit weird.
The rest of the book deals with the most fundamental abstractions of Haskell, or rather of functional programming as embodied in Haskell: functor, applicative functors, monoids and monads. The instances of the most important types (lists, functions, tuples) for these typeclasses are explained in detail. The examples are sometimes too toy-like, but the level is appropriate for such an introduction to introduction book. The last chapter is a study of how simple procedures such as traversing and modifying lists is done in functional programming where side effects are not allowed. While reading it, I had quite a few "that's how you do it!" moments.
If you would like to have an idea of what Haskell is about, this is probably the best book you can get.
The first few chapters cover the basics of what sets Haskell apart from most other languages: list processing, functional programming,the type system. The book does a particularly good job of explaning laziness, a feature of Haskell really rare among other languages. Functional programming is mostly explained with the example of functions that are already in the code base, such as takeWith or filter. In addition to this, many toy examples are employed, which is kind of annoying, but one has the feeling that the main aim of the book is not to get the developer to do, say, systems programming with Haskell, but get acquainted with its fundamental ideas.
After the easy bits with sum types and walking trees and such come the hairy bits of Haskell. The first is, you guessed it, IO. IO notoriously uses monads, one of the central abstractions of Haskell that is a pain to understand. In the Haskell type hierarchy, monads come rather late, but IO is very important for programming, so there is no point in putting it at the end of the book. For this reason, the author chooses to introduce the IO monad without making a big fuss of monads. Instead, the simple operations are explained in a "this is how you do it, don't care about the rest" manner. This attitude is common to many other Haskell texts, but it's still a bit weird.
The rest of the book deals with the most fundamental abstractions of Haskell, or rather of functional programming as embodied in Haskell: functor, applicative functors, monoids and monads. The instances of the most important types (lists, functions, tuples) for these typeclasses are explained in detail. The examples are sometimes too toy-like, but the level is appropriate for such an introduction to introduction book. The last chapter is a study of how simple procedures such as traversing and modifying lists is done in functional programming where side effects are not allowed. While reading it, I had quite a few "that's how you do it!" moments.
If you would like to have an idea of what Haskell is about, this is probably the best book you can get.
May 11, 2022
It started fine, but at the end it was super messy: I know Haskell is not an easy language to understand, but by the end of the book, everything was a bunch of words that didn't make much sense. Even something as simple as changing the font for the examples (so the reader is able to visually separate the code from the description) would have improve the readability of the book.
The examples were kind of oversimplistic, which is good to provide some learning, but later on, they don't help understanding what are the advantages of Haskell in more real scenarios.
I always thought there was an ecological reason why pure functional programming languages, despite all their advantages, never go mainstream. I don't think I have a full understanding of Haskell after this book, but it still validates my hypothesis, in the sense that is not a super useful language when it comes to create real world programs.
The examples were kind of oversimplistic, which is good to provide some learning, but later on, they don't help understanding what are the advantages of Haskell in more real scenarios.
I always thought there was an ecological reason why pure functional programming languages, despite all their advantages, never go mainstream. I don't think I have a full understanding of Haskell after this book, but it still validates my hypothesis, in the sense that is not a super useful language when it comes to create real world programs.
January 12, 2023
Not a huge fan of the overly childish humor in this.
Then the code example using fat shaming for half a chapter was the end for me.
Then the code example using fat shaming for half a chapter was the end for me.
March 5, 2016
Once upon a sickleave dreary, while I pondered, weak and weary, Over many a quaint and curious volume of forgotten lore, I ended up reading about Haskell. Basically I was really, really bored and started flipping through the book since it's freely available at http://learnyouahaskell.com/
Having previous programming experience from various non-functional (heh) languages I had to unlearn old habits to wrap my brain around some of the concepts in Haskell. Fortunately for me, LYaH 's approach was gentle and each chapter built on the previous one to form a cohesive structure that made it comfortable to ease into the language. Haskell is known for it's somewhat academic background which shows e.g. in function composition
Having previous programming experience from various non-functional (heh) languages I had to unlearn old habits to wrap my brain around some of the concepts in Haskell. Fortunately for me, LYaH 's approach was gentle and each chapter built on the previous one to form a cohesive structure that made it comfortable to ease into the language. Haskell is known for it's somewhat academic background which shows e.g. in function composition
f . g x = f (g x)which actually looks like the real thing (and that's awesome). The book made some comments, but didn't dwell on the mathematics background, which might be a relief for some people. The colouring was vibrant and pictures were refreshingly non-traditional for a programming book. All in all a nice, light introduction to functional programming and Haskell. Recommended for people new to both subjects, but not necessarily to the more seasoned functional veterans (no, javascript doesn't count).
May 31, 2017
If you want to learn Haskell, then the first 10 chapters aren't bad. (To be precise, that's up to and including "functionally solving problems".) There aren't any exercises though. I don't see how anyone can learn something without being forced to confront it. After the 10th chapter, the book goes completely off the rails. Topics covered in the first part (the good part) are at least somewhat motivated. The remaining topics aren't motivated at all. The result is that I felt stupid and confused and lost. Even worse, I felt *guilty* for putting the book down. It wasn't until I read this blog post by Betsy Haibel that I realized it doesn't have to be this way.
Some of what the author deems informal might have been fine as recently as a decade ago. Has the tech industry has grown up in terms of including people who aren't skinny straight white nerds? I want to believe, but that optimism comes from extreme ignorance and male privilege.
In any case, there are better books out there. I would not recommend anyone spend any of their time on this book outside of the aforementioned first 10 chapters.
Some of what the author deems informal might have been fine as recently as a decade ago. Has the tech industry has grown up in terms of including people who aren't skinny straight white nerds? I want to believe, but that optimism comes from extreme ignorance and male privilege.
In any case, there are better books out there. I would not recommend anyone spend any of their time on this book outside of the aforementioned first 10 chapters.
June 7, 2016
This book was a fun, fascinating, and challenging tutorial for the Haskell programming language. It starts out deceptively simple, introducing basic Haskell syntax. It feels elegant, concise, and powerful. Then, much like functional languages themselves are designed, this book builds upon its simpler concepts to build more complex concepts. It sneaks up pretty fast. By the time you're halfway through, you're swimming in a sea of relatively new concepts, all working together to build programs. If you didn't thoroughly understand the concepts introduced in earlier chapters, you'll feel pretty lost. This book does occasionally stop to demonstrate with some examples, or to refresh your memory, but mostly it's just full speed ahead. I recommend that you often refer back to earlier chapters.
Haskell is an interesting language. It really challenged my programming skills, and got me to think in new ways. It was definitely worth learning at least the basics, but I feel skeptical that complete Haskell programs are half as elegant as this book makes them seem at first.
Haskell is an interesting language. It really challenged my programming skills, and got me to think in new ways. It was definitely worth learning at least the basics, but I feel skeptical that complete Haskell programs are half as elegant as this book makes them seem at first.
December 17, 2020
I liked this book and I feel it is a good source of information about Haskell and functional programming. But after reading 90% of the book I feel I need to reread the last half in the future. Maybe it was because of my background, but I think that the difference in complexity between the first and last half of the book is so huge that perhaps the author could have used a different approach. For example, warning about it or at least providing a better overview of the relationships between the chapters to prepare the audience. Sometimes it was hard to guess what was the order of importance of each subject.
In spite of that, I will reread it and I hope I will have a much better feeling about this book. Maybe I am part of the problem =)
In spite of that, I will reread it and I hope I will have a much better feeling about this book. Maybe I am part of the problem =)
June 12, 2013
Fantastic introduction to the programming language Haskell. Took a technical, abstract, and difficult language and made it both fun and accessible. I supplemented occasionally with various articles online (most recently on http://chris-taylor.github.io/blog/20..., but also on functors/applicatives/monads). Pretty much nothing to complain about. I'm going to let the topics simmer in my subconscious mind for six months or a year, and then I think I'll re-read.
December 28, 2011
A nice and quite approachable book about Haskell. I liked it and recommend it to my students (along with the website, from which the book was originally created), but I still feel that if I didn't know most of the concepts before reading the book, I could use more examples (and more examples why a certain feature is needed or useful). But the point probably is that the book is aimed at people, who have experience with programming, but not necessarily with the functional style.
May 27, 2012
The only Haskell book/tutorial I've seen that doesn't get completely stuck in either a bunch of pedantic bullshit or lofty theoretical handwaving. LYAH strikes a nice balance of the two so it feels like you're actually making progress as you go through the book.
I agree with the other reviewers that adding some exercises would complete what is otherwise the perfect introductory book to Haskell.
I agree with the other reviewers that adding some exercises would complete what is otherwise the perfect introductory book to Haskell.
July 29, 2016
It's a great intro to the language, even though I felt a bit lost at times due to a few omissions that I can only assume were made for the sake of brevity. I was able to cover the holes by following up with Real World Haskell, which is a good idea anyway, since it is a complex language and repetition helps with learning it.
Some commitment required.
Some commitment required.
October 24, 2011
It does a pretty good job of explaining a lot of the concepts in Haskell in a simple way. Where it gets more complicated it's due to the complexities (or unfamiliarities) of Haskell itself. The humor wore out its welcome after chapter 2 or so, but it's not so obnoxious as to make the book unreadable.
Displaying 1 - 30 of 194 reviews