Troika Tech

"Principles of Reactive Programming", a Review

After the positive experience learning some Scala and some functional patterns in Functional Programming Principles in Scala, I was excited to undertake the new course from Martin Odersky and co. The fact that it would pick up from where it left off and build on the Reactive brouhaha was icing in the cake; after all, the techniques and technologies approached in the lectures highlight some of what Scala does best.

Structure

It starts with mr. Odersky’s already familiar style, reviewing some of what was taught in the previous course and expanding on some topics. The dreaded Monads were dealt with, and while I can’t talk about the subject from a theoretical standpoint or offer a perfect explanation, I feel I grasp how they can be used to compose behavior and express functionality better.

The second part was the highlight, for me. Erik Meijer (from LINQ and Reactive Extensions fame on the .NET land) has an incredibly upbeat energy and great sense of humor, which carry you like a breeze through the amazing concepts he expresses. I loved thinking about Event streams and how to compose them using monadic combinators in the form of Observables (alongside Subscriptions, Schedulers, Promises and Futures). I think this affected me the most, for I could clearly see how to mix and match things to add behavior.

The third part was also very good. Roland Kuhn (Akka’s tech lead) has a soft-spoken style that relaxes you while he lays the groundwork over which you’ll learn about Actors, building distributed systems and dealing with failure in that model. He also shows piece by piece what Akka can do (which led me to explore more of Celluloid, a topic for a future post).

Exercises

Everything comes together with each week’s exercises. The first was a quick-and-simple one that explores property testing. I went through it quickly, but I still find it hard to apply that mode of thinking, and didn’t get much out of the technique later on. I know this is a personal limitation, as some people in the course forums mentioned using it to great effect.

After that, you get a wake-up call that this is gonna require some hard work right as you’re asked to build two simulations: one of circuits, with emphasis on building a demultiplexer, and one of an epidemy. The fact that this involves timing and sequencing makes you think about state and purely functional programs. Building something substantial (and fun to watch) gives you an appreciation of their usefulness.

Epidemy simulation

Erik Meijer’s had cool, practical examples: you build a node-style web server (with a Reactor loop) in the first week and a Wikipedia Swing client using reactive streams for GUI events and networking in the second. It makes you want to write everything in this style, because it becomes much easier to think about what happens when with whom.

The third section, on Akka, takes the prize in this area: first you redo the binary search tree exercise from the first course using Actors, which I found a great idea, as you’re confronted just with the new concepts. Then you are challenged into building a (simplified) distributed key-value store, including replication and joining of new nodes. Describing this exercise to colleagues made them want to take the course. I hope they do.

Scala

Being forced to use more Scala made my interest in it grow more and more. Alex Payne has said that it feels a bit like Ruby in its expressiveness, and I got that while building the exercises. I confess it is refreshing and enlightening to use types as a way of reasoning, and not as something that just soothes a compiler with a frail ego.

On the other hand, tooling was problematic. Being an Emacs user, I try to keep in it at all times, and surprisingly (coupled with ENSIME) the experience was not bad. Still I tried to take the opportunity to learn a little bit more about what is offered and how well it works, and the experience was not so great. Importing the provided Eclipse projects sometimes resulted in missing dependencies; importing the sbt project in IntelliJ IDEA resulted in error messages complaining about the TEST context, which some of the students claimed could be solved with nightly builds of its Scala and SBT plugins.

In ENSIME it mostly worked fine. Sometimes I needed to run the tests before generating the project in sbt, or to regenerate the project as I fleshed out the code. This was not that that awful, in the end: coming from a world of no static types, no code completion, poor navigation (seriously, guys, I’ve used dynamic languages for over 15 years, and grep/ack/ag is not a good replacement) and pretty crude automatic refactorings, it felt like I was thrown into a better world. I find myself missing it in my daily Ruby dealings.

ENSIME as I worked through the exercises

I realize the situation with Eclipse and IntelliJ may be specific to the course, as the canonical thing to use was sbt. However, being that sbt is the canonical build tool, period, it made the experience messy, and complaints in the forum suggest there’s still a lot to improve here. We developers are used these sorts of hurdles (and, let’s be frank, to learning workarounds), but this is the type of thing that turns off someone that is not yet invested in the tech.

What I learned about myself

Comparing my approach to my fellow students’, I found I could go through most things relatively easily, based on experience alone, but that eventually I had to exercise muscles in areas I consider mostly weak: self-reliance and grit. It was necessary to overcome my impulse to procrastinate when facing a roadblock, and also to not feel guilty about going to the forums, reading about other people’s struggles or using a test suite that some kind soul provided for everyone else.

To face things that are known but empirically unexplored made me question my ability, and demanded a hard look at my self-image. It took great care and some pain to keep motivated and think of the outcome. The sense of pride from having completed this without delaying a single exercise makes me believe I can accomplish more. Furthermore, getting a near-perfect score for the effort is very sweet.

I hope this helps me become a little more patient. My instinct is to go for quick intellectual gratification, for tight feedback loops, and that is not always possible (or even desirable). Standing on the shoulder of giants requires a climb; I must remember not be discouraged after the first stretch.

Conclusion

I recommend everyone to go through this course. It is challenging, rewarding and (for me) a good source of personal growth. Scala is very interesting, and worthy of your time, and Akka is incredible. I found the different teaching styles refreshing, a great way to keep the learner engaged. All in all, a delightful experience.