Firstly, the good. Erik’s lectures were well-paced and entertaining, and for the most part communicated concepts fairly well. I won’t say he’s the most polished presenter, but his knowledge, enthusiasm and sense of whimsy (a plate of bananas was used as a prop at one point) combined to make the content quite watchable.
The lab format was quite good also. Typically there was a downloadable Haskell file with some unimplemented functions, then the lab questions took you through what each of the functions should do. Once done, you would paste some test code into GHCi that called the function, and then paste the result into the lab quiz. Because this is Haskell, generally once it compiled with no type errors, you got the right answer.
As an aside, it would be nice if you could paste your code into the quiz directly and have some QuickCheck magic running in the background – this can’t be done on the very general-purpose EdX platform, but hopefully that’s how we’ll learn code in the future.
The content was fairly well graduated also – I have some exposure to Haskell and FP, and didn’t have too many problems early on, but started to get a lot more challenged as the course progressed. Once we hit the M word some of the exercises became quite difficult (but mostly in a good way).
Now, the bad. This was ostensibly a 6 week course, but the lectures & exercises dropped two at a time. It might just be the psychological impact of splitting it up in this way, but I often found I’d only get one module done in a week, and I started to fall further and further behind. There was plenty of time to finish all the assessments after the fact, but I wouldn’t have been so down on myself if the content had have been spaced out a little more.
The course was intended to be language agnostic, but in practice it was very much a Haskell course. Certainly the FP concepts covered in the lectures were generic and widely applicable, and Erik did a good job of demoing functional style in other languages, but the assessments were nearly all Haskell-specific, and I can’t imagine anyone would have made it through without doing Haskell.
And now, the homework. There were a number of problems with this. Here’s a typical question, for context:
Answering this question format generally involved laboriously typing the possible answers (they’re images, so they can’t be copy & pasted) into GHCi, and running each one to see if it worked – it felt like a fairly mind-numbing chore, had a high chance of transcription errors, and didn’t really aid understanding at all. For the simpler examples, like this one, it was sometimes more reliable to try to reason about the code in your head than chance typing it incorrectly. Occasionally I found I would correct the intentional errors in the functions subconsciously while typing! This really only affected the scores, but it definitely detracted from the enjoyment of the course.
I can understand the value of including a few ‘choose all the correct implementations’ questions early on while people are getting to grips with different features of the language, but for the most part I wanted to see what the idiomatic Haskell code should look like (i.e. I’m fairly confident some of those solutions to
any wouldn’t be written by any self-respecting Haskell developer).
In some cases, the question was very abstract and it wasn’t really clear what the code was actually meant to do. These questions were really crying out for examples of inputs, or how the function is intended to be used – one example that I struggled with:
Consider expressions built up from non-negative numbers, greater or equal to zero using a subtraction operator that associates to the left.
A possible grammar for such expressions would look as follows:
However, this grammar is left-recursive and hence directly transliterating this grammar into parser combinators would result in a program that does not terminate because of the left-recursion. In the lectures of week 7 we showed how to factor recursive grammars using iteration.
Choose an iterative implementation of left-asociative expressions that does not suffer from non-termination.
Lastly, there were a number of instances where entirely new concepts were introduced in the homework that hadn’t been mentioned at all in the lectures (e.g. redexes). I think some of these were covered in the book, but it had been mentioned earlier in the course that the book wasn’t really necessary, so I hadn’t been keeping up to date.
To sum up, I definitely know more Haskell now than when I started, so I’d have to call that a win. The course itself shows some promise, and I’d like to see the homework issues improved. I think the excessive genericness and one-size-fits-all of the EdX platform detracts from it a bit, but not terminally so. If you want to dip your toes into FP, don’t mind using Haskell to do it, and think you can cope with somewhat laborious homework tasks, you’ll definitely get value out of this.