I second that, it's been the best course I've taken up on coursera so far (with Dan Boneh's crypto). The lectures are great, but the best for me was the high quality provided course notes. I read those in my morning and evening commutes and I didn't even have to watch the videos!
The exercises were well crafted, guiding you part by part to build your program, and challenging enough that you learned something valuable. It definitely made me interested in exploring more the three languages presented - ML, Racket and Ruby.
I'm currently taking the second Scala course and I have to say it's a bit of a disappointment so far. Martin Odersky's part was good, but I didn't really like Erik Meijer's teaching style (I understood Futures and Promises better after reading a few articles about these). I haven't caught up with Roland Kuhn's part yet.
However I've been incredibly frustrated with the exercises. They are tedious, but for the wrong reasons: you have to make a lot of guesses on what are exactly the semantics of what you're supposed to implement, sifting through the forum and the FAQ for relevant information. After you've submitted, you now have to wait for a long time (between 20 and 100 minutes) for the automatic grader to tell you whether your guess about what exactly you had to implement was right or wrong.
It's still an interesting course, and it's worth just for the sake of getting your hands into some Scala code, but there's that caveat.
> They are tedious, but for the wrong reasons: you have to make a lot of guesses on what are exactly the semantics of what you're supposed to implement, sifting through the forum and the FAQ for relevant information.
I look at their exercises more from a "I'll do it until I feel I have learned the core concepts" rather than "I'll do it until the grader gives me 100%".
If you're not taking the course for credit, your goal should be learning, not grades. That's what it's all about for me, and learning reactive/functional/Scala programming has little to do with debugging a black box of a grading system.
(Totally agree for those people who paid to receive credit, it must be very frustrating at times)
If the lectures do not do a good job of teaching the material and the assignments do not actually do a good job of testing your understanding of the material, what is the point of the course? I think epsylon is accurately presenting the prevailing opinion of the course. It's not very good and is a time sink for all the wrong reasons.
If the grader is marking you off on a certain aspect of the assignment, how do you know you have actually learned the core concepts? How do you know you aren't missing something important? The problem with "doing it until I feel I have learned the core concepts" is that I don't know what I don't know (unknown unknowns). That's part of why a structured course is supposed to be valuable, because it doesn't let me skip important concepts.
This course can be salvaged the second time around, but it is going to require a bit of polishing.
Happy to see you have such a positive attitude about hard learning. It pained me to see noobs being depressed and self-deprecative on the irc channel. I understand their feelings, I felt the same before it was all blurry, the irony is that I couldn't explain them how I got to understanding, it was just maturation, which they didn't wanna hear about.
I had taken Odersky's first scala course in FP, which probably helped prevent initial shock, but I still had to put in the hours to get through all the assignments. That said, it didn't like banging my head against some complex theory or algo problem.
Seeing the absolute beginners stuggle is painful, but at least they are making an attempt.
Btw, the craziest coursera forms I ever saw were in the non-tech fields. In Into to Finance it was so bad; at least our sort don't type posts in all caps ;)
Throughout, On Lisp emphasizes programming in a functional style. Chapter 3, "Functional Programming" provides a clear presentation of functional programming. More importantly, it shows where and how mutation is used when doing so.
Well, for me Lisp is a mostly-functional language. In Scheme its quite simple - just avoid set-car! set-cdr! and other destructive primitives when possible, while in CL you should be more careful and disciplined due to lack of agreed upon naming conventions for destructive operations and possible implicit usage of setf in macros. Anyway, even CL could be called mostly-functional.
A lot of the stuff there is to know about functional programming is still only contained in academic papers, and indeed many of these listed books are texts in programming languages that cite a great deal of the important literature. There is much about programming languages and functional programming that one might read interspersed with these books. Other than following references in the backs of many of these books, the Haskell wiki is a good place for starting to dig into literature on functional programming, as many articles link to important and interesting papers.
On that note it's a bit strange not to see a few books on semantics, such as Transitions and Trees or Semantics Engineering with PLT Redex, listed among books like TAPL and Barendregt's Lambda Calculus. Especially now that DSL design is something many programmers are dabbling in, it makes sense to gain some background on operational semantics. I'd recommend either of these books to anyone working on DSLs, especially in a functional language.
Finally, it might be worth adding Homotopy Type Theory to your list, especially since the list already contains several good books about Coq as well as works about type theory and type systems.
Why Homotopy Type Theory? It is cutting edge research and it doesn't seem clear to me that it is going to have an impact on functional programming (of the non-mathematical research type) any time soon. Am I mistaken?
It seems to have quickly "infected" literature on dependent types at large---not to the point of having replaced the normal terminology, but instead as forming a sort of common framework for examining those fields.
Which is definitely a point on the side of "has no impact".
But on the other hand, I think studying dependent types is a fantastic way to get some perspective as an intermediate to advanced Haskell or OCaml programmer. Software Foundations and Certified Programming with Dependent Types are both great books to read.
HoTT won't be on that list for some time if ever, but once you've got a good mental model for dependent types it's illuminating to see them worked out "from scratch" as HoTT does.
So, the best I can say is that it can be influential in the way that you view types if you're someone who frequently programs and thinks in a nicely typed language like Haskell/OCaml and maybe Scala.
The book on Homotopy Type Theory is quite readable even though the developments are quite new. The purpose of the book is to get the material into the hands of as many as it may be useful to as soon as possible.
I would argue that the book is at least as useful as Categories for the Working Mathematician or Barendregt's Lambda Calculus are likely to be for your typical software engineer interested in functional programming. To be clear, someone interested only in learning how to program in functional languages is probably not going to get very much from either of those books, which are respectively an extremely technical mathematical text on topics in category theory, and a heavily logic-oriented, mathematical presentation of the lambda calculus and derivatives thereof. Not much of the material in either book would be directly applicable to the practice of software engineering using functional languages, but someone with a deeper interest would find them useful and interesting, and I think the same holds for the HoTT book. At the very least, as the other commenter alluded to, a novice reader would probably be able to glean a nice understanding of Martin-Löf dependent type theory from the first chapter.
The classics section is missing one of my favourites, Recursive Programming Techniques by Wm Burge. A beautiful book that was ultra cutting-edge at the time (1975) but still a very effective exploration of the elegance of FP, techniques and patterns that are useful today, ideas with the potential to provide satori moments for anyone learning the paradigm, issues arising from laziness etc etc. You can read it today and treat the language used as a notation, like a dynamically-typed Haskell IIRC. The best £1.54 you'll ever spend! -- http://www.amazon.co.uk/Recursive-Programming-Techniques-sys...
To the author: The section on 'Caml and Objective Caml' should be renamed to 'OCaml' as that's the official name of language in recent years.
Also, the ordering of books is best done in reverse chronological order. Improvements are made in different compiler versions so it would cause frustration for a new reader if they come across a disconnect. I suspect the same is true for other languages listed. The most recent books are 'OCaml from the very beginning'  (released earlier this year) and 'Real World OCaml'  (released a few weeks ago). You can find these and other OCaml books listed at: http://ocaml.org/learn/books.html
You build a basic old-school text adventure in Prolog which is more accessible than the traditionally boring introductions with family databases (imo). It's from amzi but should work with most Prologs, iirc I ran through it with GNU-Prolog (I'd recommend SWI though, it's the best open source implementation out there imo).
Uses some metaprogramming that is usually not covered in introductory material (and often considered "use with care") i.e. dynamically updating code with assert/retract
I have only browsed "Warren's Abstract Machine: A Tutorial Reconstruction" but it's on my to read list. Interesting for anyone that enjoys VM-design and the like.
The Pearls of Functional Algorithm Design is like the On Lisp of Haskell. It's a stunning, challenging intermediate FP programming book that focuses on how equational reasoning allows you to "automatically" move from unoptimized, unelegant, fragile code to optimal, beautiful code correctly.
I remember a wonderful website about functional programming in python, not about the classic map/fold/list, but about solving numerical problems in a functional manner (somehow monadic in structure, without saying it). I could never find it again, maybe someone knows it.
If anyone wants to read SICP and would like a buddy to read it with, let me know! I am working on an iPad app for people to study together and we are trying SICP as one of our first courses. I am reading it for my first time. It is an enlightening book! email@example.com
Functional programming is the best, a classic approach for a smooth simple development. And this review was simply amazing.
I saw this website a few days back, http://studytonight.com which is really nice, if we talk about simple lessons.
I saw some really great videos there about concept of programming and data structures.
>"I'm seeing books in there that are awful choices."
At the very least, you could mention which and why.
There's a hell of a lot more value in...
"The ZINC experiment: an economical implementation of the ML language is a technical report, written by Xavier Leroy (author of OCaml) in 1990th, and it contains pretty detailed description of ML-like language implementation. This report could be very interesting for all who wants to know about internals of Caml & OCaml languages."
...x 132 from someone who may or may or may not have actually read what's linked than a simple "awful" without any context or qualification.
I mean, you could have just dropped a link to your own site and added something of value, instead of creating a nonsense tangent of accusation:
I've stated my opinion, I mentioned that I did it myself, placing affiliate tags on book links (in the comment you're replying to), no I didn't want to draw attention to my own blog because it would have been off-topic and yes, I gave explanations in this same thread.
What you're doing is a direct ad-hominem btw. I don't need qualifications to infer that it's impossible for somebody to read 132 books on some of the hardest topics in CS. We also have different definitions for what "value" is.
Can you please call out which books are bad though? That's some very useful information. I know I've read books that were garbage that are very highly recommended. (Code Complete as a "guide to the craft of programming", for example is extremely poor when compared to The Pragmatic Programmer). And even if I disagree with your judgements in some cases, it's good for calibration.
Seriously, you've read 132 technical books, for 10 different languages, going back to 2009?
(2) I'm seeing books that have been OK-ish when they appeared and thus recommended by people, either because of lack of other choices, but also because the advice contained was the status quo, but right now are pretty bad choices. "Programming Scala", by Alex Payne, for example is an awful reference to put on any list of books for Scala. It contains bad practices, plus lots of references to obsolete parts of the standard library, not to mention its general flow is just awful. If you would have read it, you would have known. "Programming Scala" the one published by the Pragmatic Programmers, is another awful choice. Actually, all books on Scala published before 2010 are awful choices.
(3) What the hell does a book on Scalatra has to do with Functional Programming? Is it because the association with Scala or something?
(4) It's bad advice to tell people to buy books from Amazon. The E-Books are DRM-enabled Kindle versions, sometimes badly formated and you don't get the PDF. Many of those books have the same price if you buy straight from their publishers and you get both a DRM-free Kindle version and the PDF.
Lets do the math - this isn't fiction we're talking about, it takes at least 2 weeks to read a technical book and this is assuming you can read at least 1 or several chapters per day, or maybe skipping chapters, which can't happen for many of those books, as some of them are pretty challenging and you have to think about what you're reading, you have to try out samples, you have to do extra reading to clarify stuff and so on.
But lets be generous and say that 2 weeks is the average for reading a technical book. And there are on average 52 weeks in a year.
132 * 2 / 52 = 5.08
So that's 5 years worth of book reading, assuming that (a) you're reading each and every single day, without exceptions, without breaks and (b) that you aren't reading anything else. Why the heck won't you admit that you haven't read some of them and simply pasted links based on Amazon's recommendations or something?
Also, the section on recommendations is shallow. It references books for getting started, after which it gives advice to continue with the books above. And I'm not seeing negative remarks on the referenced books at all. Everybody has opinions on whether a book was good or not. What kind of review doesn't do that?
"Functional Programming in Scala" is an awesome book on functional programming btw. You should put that as a recommended book.
It doesn't take two weeks to read a technical book that covers material you already know. I have no opinion on the site's reviews, but it's completely possible to read hundreds of very technical books, as long as the material overlaps.
This is a list of amazon referral links to books related to functional programming, with a ~2-sentence blurb about each that could be written in 10 minutes with the help of google. It's a nice way for him to make some referral money but otherwise it's nothing special. The guy probably hasn't opened half of the books here.
please, generate it yourself (without looking into this list) and track how much time you need to do this...
I've compiled this list long time ago as an article for Russian FP journal, and it takes relatively much time to track new books, obtain them (paying myself or get through Safari Online), read or at least briefly go through it, and write a short review...
P.S. regarding the referral money - don't think that it generates a ton of money - it's barely enough to buy one inexpensive book per year...