Learn You a Haskell is now in print
learnyouahaskell.com
learnyouahaskell.com
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).
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 :<.
There's a second book, started before LPTHW and LRTHW, called Learn You The Ruby, by me. But I haven't finished it :(
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?
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.
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.
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."
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.
Guess I should buy the print version of the book to support the author....
Thank you Miran for a great haskell book, I'm really looking forward to getting my hands on a print copy.
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.
Thanks Miran!
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.
Background: libguestfs Haskell bindings need a lot of love, and the FFI deeply confuses me.
http://book.realworldhaskell.org/read/interfacing-with-c-the...
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.
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.
[1] http://git.annexia.org/?p=libguestfs.git;a=tree;f=generator;...
(Despite it being a free ebook I vastly prefer print, another problem I'm trying to figure out and solve...)
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.
It won't be my only haskell book, but I'm glad it was my first!
Here's an article that helped me understand them: http://www.grabmueller.de/martin/www/pub/Transformers.en.htm...
I have read it online about a year ago, but I still ordered my copy from Amazon.
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.
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)