December 31, 2013

Reactive Programming

Tags: , , ,

Following on from Functional Programming in Scala on Coursera is the more advanced Scala course Reactive Programming. Reactive programming is a style of writing concurrent event-based asynchronous programs and appears to fit nicely into Scala’s functional programming model. It is claimed this paradigm is essential for large scale high performance systems – and my working experience backs this (although my experience is not with any systems that describe themselves as “reactive”, instead they were just bespoke or 3rd party asynchronous event-driven libraries).

Over 7 weeks the course is taught by 3 lecturers: Martin Odersky (Scala’s creator); Erik Meijer; and, Roland Kuhn, lead developer on the Akka reactive library. starting with some more advanced Scala techniques including the introduction of monads, the course quickly moves onto handling asynchronous computation with futures, promises and observables. The last three weeks introduce Actors for concurrency. Each week there is around an hour or two of video lectures and all but the last week included a programming assignment (taking a few hours to complete). Production quality is high.

This course demonstrated both the best and worst parts of online courses. The well presented material is very interesting and probably very useful for me professionally. I have downloaded all the lectures so they can be periodically reviewed and spent some time ensuring I learnt the concepts. So far, so good – I am happy to have participated. However, the assignments were another story. Firstly, the assignments were badly specified. For all but the last week (I guess the organisers had learnt by then), I had to reread the assignment many times before even starting. I would usually also have to read the FAQ (why does an assignment have a separate FAQ!) and check the forums (full of people similarly confused) for discussions on the gaps in the specification. The whole thing seemed a little haphazard.

The assignments were also dumbed down. After the first week there were a number of complaints the assignments were too hard. Hence the due date for all assignments was extended by a week and a student could submit an unlimited number of attempts using the best result (instead of the original maximum of 5 attempts). As a result students no longer needed to write tests for their code – they could rely on the automatic grader to test for them (doing so before would likely use too many submissions before finishing).

I did the course to learn advanced Scala, not to obtain credentials. On this measure it succeeds. However, MOOC credentials will always be near worthless if students know that with a little moaning they can have the course made substantially easier. I imagine the lecturers’ motivation must be to get as many students through the course as possible. From my experience, the most popular and most highly completed courses are the easiest. The only two “difficult” courses I have started (this one and Introduction to Astronomy), were made considerably easier after a single week. Dropping coursework to the lowest common denominator may be great for passing huge numbers of students, but it won’t do the reputation of these online courses any good.

comments powered by Disqus