It's astonishing to me that a computer science student wrote such a good book. It's funny, witty, the drawings are great, and the author explains quite complicated concepts of functional programming very clearly. I've already read this book a year ago online, yet I'm still gonna buy it just to support the author.
I went through a decent portion of it online a while back myself, and I ended up grabbing it during O'Reilly's funding drive for Japan both for that effort and to support the author.
Of the Haskell tutorials/books I've read it made me feel like I was getting more out of it (main other one I read was RWH, which isn't bad but felt... dry? and was a tough push).
Wasn't there some virtual pushing and shoving over whether this was just a gross rip-off of a python book? Or am I confusing it with another? (Nitpicks welcome for once, so long as you can provide a link to the thing I was thinking of :D )
it's kind of inspired by Why's ruby guide, because that's also a sort of funny-ish programming book with pictures, but i think our style is different enough.
You might be thinking of Zed Shaw's "Learn Python the Hard Way", which started a spat between him and Mark Pilgrim over the best way to teach Python. It was also ripped off to make a Ruby version later, which Zed got pretty annoyed at (FWIW, the Ruby version basically replaced the Python examples with Ruby, while not changing the explanations - which were very much tied to Python).
However, none of that has anything to do with Learn You a Haskell, which looks excellent and will probably mean I don't make my savings goal next week :<.
No Starch has really been knocking out of the park lately with Land of Lisp, Eloquent Javascript, The Linux Programming Interface, and now Learn You a Haskell. They are also one of the few publishers who's typesetting doesn't make me want to claw my eyes out.
I can now confidently recommend a book to Haskell-aspiring friends that is easy to read and incredibly fun at the same time. It will be on my bookshelf next to Land of Lisp.
With respect to the interaction between programming and maths, I remember reading a while back about some computer science course where they found that a relatively simple maths test administered early on strongly predicted success at the end of the course, and it was mainly around algebra and variable assignments.
I wonder if the 'procedural' languages are more strongly slanted towards the algebra style of maths, whereas 'functional' languages are more strongly slanted towards the formula style (or whatever we would call that maths where you talk about f of n, and g(f(n)) rather than the x squared plus 4x plus c style - not sure of nomenclature, many moons ago I took a course on 'Discrete' mathematics but couldn't adequately define what makes it different from other sorts of maths)
My grossly inadequate labels aside, the point I'm getting at is that maybe depending on the type of maths they do, different mathematicians might be drawn towards different kinds of programming languages (or find them more or less 'natural'). What do you think?
> With respect to the interaction between programming and maths, I remember reading a while back about some computer science course where they found that a relatively simple maths test administered early on strongly predicted success at the end of the course, and it was mainly around algebra and variable assignments.
The original study is Testing Programming Aptitude, by Saeed Dehnadi in 2006.
"The initial study suggests that success in the first stage of an introductory programming course is predictable, by not consistency in the use of the mental models which students apply to a basic programming problem before they have had any contact with programming notation ..."
In subsequent studies (Bornat, Dehnadi, Simon: Mental Models, Consistency and Programming Aptitude) the relationship did not hold and Dehnadi and others have refuted the original hypothesis:
"Two years ago we appeared to have discovered an exciting and enigmatic new predictor of success in a first programming course. We now report that after six experiments, involving more than 500 students at six institutions in three countries, the predictive e ffect of our test has failed to live up to that early promise."
Thanks! I wonder if the failure to generalise the results in subsequent studies is due to different teaching material and methods at the different universities?
One of their hypotheses is that the test doesn't work because students can start a test with mental model A, get halfway through and realise it should actually be mental model B, but don't bother to go back to previous answers because the test is not used for assessment purposes.
Thus an otherwise excellent student could appear "inconsistent" in the predictive test, reducing its usefulness.
The second paper is good reading and its authors are admirable models of scientific honesty.
As someone who studied maths before programming, I think the only real predictor is whether you are comfortable with discrete mathematics.
I don't find most mathematics I learned (undergrad + stats/EE at graduate level and above) very useful for programming. There are commonalities of course, in the sense that people who do mathematics understand the notion of abstraction, etc... But what most "real" programming is about boils down to things where mathematics can actually be harmful at first: everything related to the difference between science and engineering. For example, I still have to fight my will to understand most aspects of a problem before solving it. Not that programming should be done without thinking, but you need a much more iterative approach in programming to be successful. The whole notion of prototyping does not really match anything in mathematics, I think.
What makes functional programming interesting nowadays is more linked to those engineering issues. Unless you do very theoretical stuff, functional programming has little to do with maths, and more to do with the typical practial matters of programming.
I think mathematicians are simply better at internalizing "this symbol stands for that concept" than other people, and this ability makes them good at both imperative and functional programming.
Great guide! Since the author himself seems to be reading these comments, I finally have a chance to say just how hysterically funny the bit about analyzing the Avril Lavigne song line by line was. I laughed so hard when I got to that part.
Guess I should buy the print version of the book to support the author....
Just bought this from No Starch Press for delivery to the UK. Amazon UK has it for £35.49, so cheaper to get it shipped over - madness! (I'll take my chances on the import taxes...)
Thank you Miran for a great haskell book, I'm really looking forward to getting my hands on a print copy.
LYAH is fun and accessible. A great introduction to the advanced concepts in Haskell and the power of functional programming.
It made me better at javascript and python. It rekindled my interest in math and algebras. It makes me want to do battle with complexity in nuanced, clever ways.
Some very light criticism of this book: sometimes the author makes things a little too easy by spelling out stuff that I’d rather have to work out myself. It’s easy to fall into the temptation of just reading and reading without really trying out what you’ve learnt because everything always seems so easy to understand but you don’t really internalize it properly until you’ve actually used it a lot.
So these days I prefer other texts but I turn to LYAH when I’m really confused.
All that said it is a great work, as many have said, and a great boon to Haskell and the functional programming world.
I've been writing some ffi myself code lately. The real world haskell chapter on ffi has been helpful. They use a bit of hsc2hs on top of plain ffi. I've also been using c2hs which does a lot of the work for you (a bit higher level) and have found Edward Z Yang's guide helpful for that.
It walks you through making some basic PCRE bindings, which is a big enough example that they manage to touch on the important issues. It's a pretty good introduction, I would say, especially in the part that covers interfacing C strings with ByteStrings.
I read this when I was doing the original porting and TBH it's very lightweight.
Also (to reply to GP) c2hs is no use because we already have a very detailed and specific description of the interface, and a generator that does all the other bindings[1]. We want to know precisely how to translate our description into Haskell, we don't want to go through another layer.
Aside from the reading material others have suggested, I strongly recommend the #haskell channel on Freenode. The people there are extremely helpful and friendly.
I'm curious how the author liked working with NoStarch. I know one of PragProg's big selling points is that they're much easier to deal with and provide much higher royalties than traditional tech publishers; I wonder if NoStarch has taken a similar approach.
I can't speak to how easy PragProgs is to work with, but it seems their 'much higher royalties' are just creative bookkeeping. Where other publishers base royalties on a book's gross, PragProgs uses net. They're somewhere between traditional and vanity publishing in that regard.
Kudos to the author on this book. I think it is great that Haskell will have such a "fun" book to teach the concepts of programming in Haskell. That should lower the learning barrier a bit. More so since everything is layed out in easy to understand terms.
I don't have a DX, just an iPad, Xoom and 1st gen Kindle. But from those experiences, it's not the form factor that bothers me - it's the natural continuous access of the ebook format. I can't read PDFs onscreen for much the same reasons.
When I read technical books, I scribble; I dog-ear; I add in postits everywhere; on textbooks, I even highlight and deface quite happily. And this helps me fix in my mind where reference information is: it's the green post-it in the corner. It's the page with the drawing of a dog in the top left. (I seem to have a very visual memory for recall.)
I just cannot, no matter how hard I try, reproduce that experience on an e-reader. Yes, the features are mostly there, and search is a very nice bonus - it also works quite nicely for continuous following of tutorials - but the general way I consume these books just doesn't translate.
The slow pages turns are a killer. Especially with PDFs. "As shown in Figure N" for any value of N not on the current page was what basically killed the usefulness of the device for me.
for now!! but in the future who knows. people might want chapters that focus around making real useful stuff with the knowledge, so that's a possibility
I would love a chapter on Monan Transformers. Its one concept I can't seem to wrap my brain around and a LYAH style chapter seems like the perfect thing to help me understand it.
yeah i thought of writing a chapter about monad transformers, but it didn't really fit in. if i do a second round of chapters monad transformers will definitely be there. otherwise, just come on into #haskell and ask about stuff and you'll quickly be elucidated!
The same book is available for $25.56 on Amazon (vs $44.95 on No Starch and O'Reilly). How can Amazon afford such a huge discount on a new book? And how does O'Reilly survive with such competition?
I've got a (small-compared-to-Amazon) online bookstore, and publisher's discounts to retailers like me generally range from 30-50%. I imagine that Amazon, with their volumes, gets more favorable terms. Supposing they get a 50% discount from the publisher in this case-- I imagine they are getting more, but bear with me-- that means that they are making $3 on the book, net postage (since they charge the customer a separate fee to cover the postage and handling). $3/sale is not a lot, but multiplied by X million, it adds up.
O'Reilly survives because as a publisher, they are making money on every book sold, whether you buy it directly from them or through a retailer. Their direct retail sales are just a sideline.
This book should be eligible for Amazon's free super saver delivery.
I've sold some books in the past, mostly for fun and to learn about online retail. I'd love to have a chat with you about your experience. Can I email you somewhere? Or if you don't mind, could you please drop me a line? (see profile)
it's a mystery! but i'd recommend buying it directly from No Starch because you get the free ebook and swag, plus more money goes directly into my mouth this way
No Starch seems pretty aggressive on that recruiting front. I can't speak for them and of course I can't guarantee anything, but if anybody has an idea for a good, publishable technical book and the chops to write it, the threshold for pitching it to them seems to actually be negative, in that they will actually go around and proactively contact people.
As an O'Reilly member I seem to have a standing 2-for-1 book deal, so I just batch up my orders. I really like their ongoing updates and early releases and the DRM-free formats are a big plus.
huh. I was just looking through No Starch Press's catalog last week after someone here mentioned the Manga Guide to Databases, and I saw this, but didn't realize it was only online before.
