“Principles of Reactive Programming” course review

I recently completed the “Principles of Reactive Programming” course on Coursera – I’m very interested in FRP (and libraries like ReactiveCocoa) as I find a lot of the most painful bugs in the iOS code I work on relate to using mutable flags/timestamps (or application state) to coordinate multiple event callbacks. I’m positive there’s a better way, and I suspect FRP is it. On paper, this course looks the goods – it follows on from Odersky’s highly-regarded “Functional Programming Principles in Scala” course, and includes material from three thought-leaders of the FRP world – Martin Odersky (Scala Futures & Promises), Erik Meijer (Rx), and Roland Kuhn (Akka/Actor Model). It’s a 7 week course, run using Scala as the assessment language and main vehicle for the concepts, with  a very cool automated code submission/grading system. Firstly, the good:

  • Setup of the environment was relatively painless. I used IntelliJ rather than Eclipse (because who would ever willingly install Eclipse?), and aside from the typical OS X JRE/JDK hoops, and a minor import problem in Week 3, it worked flawlessly.
  • The content was really top-notch – the video lectures were comprehensive, well-paced, and well-presented by people who knew their stuff.
  • The submission and grading worked quite well. Once you’d completed the coding assignment, you just run the sbt target submit and your code was compiled, packaged and submitted. On the server, an automated process ran unit tests against the submission, and posted a grade & output from the failed tests online within about 5 minutes.

Aspects that I found irritating/frustrating were:

  • I hadn’t used Scala before and spent a good 60% of my time trying to work out how to perform basic tasks. Obviously the recommendation is to do Odersky’s Scala course first, but the description claimed knowledge of general functional programming concepts would be sufficient (I believe this has now been changed).
  • The course structure, with three different presenters teaching three different programming models, felt a bit disjointed – it could easily be split into three separate courses. The different models weren’t really brought together for meaningful comparison.
  • There were a few quirks with the grading system – the downloaded projects did not always include all of the grading tests, and in some cases the local tests were pretty minimal and didn’t assist much in writing the correct code. This made development pretty slow unless you could reverse-engineer the failing test. I also came across a case where the tests broke code written in a certain way – this was perhaps unavoidable, but there were a bunch of confused people on the forums who were getting no response or clarification from TAs.

Ultimately though, I learnt a lot (which would be the main measure of success). I’d comfortably recommend the course to anyone who already knows Scala, but I’d love to see a CLR version of the course in C# or F# covering the TPL, Rx.NET and Akka.NET. In the iOS world there’s also a desperate need for good learning material covering ReactiveCocoa 3 and a few of the other Swift async libraries (PromiseKit etc).

QOTW: “Row Farmers & Stateful Sinners”

The second YOW talk Dave Thomas delivered back on the 30th September was entitled “Why Real Developers Embrace Functional Programming and NoSQL: Data Confessions of an Object’holic and Stateful Sinner”. Needless to say, it contained a fair bit of controversial content that Dave was fairly unapologetic about, including the bold pronouncement that ‘C# and Java will be legacy platforms in 5 years’.

The gist of the argument was:

  • Objects are not terribly good abstractions for most real-world problems.
  • Good object-oriented design is hard, and Morts are still the bread & butter coders out there producing software.
  • Objects are implemented inefficiently in almost all runtime environments — “A good JIT can generate fast code, but it will generate a lot of it”. They also don’t translate well to parallel execution environments.
  • Serialisation/storage is still a problem — sending objects over the wire, or persisting to disk requires complicated, framework-heavy mapping.
  • KLOCs kill!

Dave’s proposed solution is a wholesale movement towards Functional Programming.  This has been contemplated before (ie for the last forty years), but I think there’s more appetite in mainstream development communities today. Functional languages are available for both the Java & .NET runtimes (and have been for some time), but more importantly we’re seeing some FP paradigms pop up in imperative languages — eg Ruby, Python and even Linq in C#. I suspect the future will be much more heavily skewed towards multi-paradigm languages than Dave would prefer, but I can certainly see it happening.

So, count me in as a convert. I’m foolishly attempting to teach myself Haskell by following the excellent wikibook and building toy web apps with Happstack — expect to see some more posts on this subject soon as I muddle my way through.