I was hired at Rally Health in November 2012 as a new technical development manager, a position described to me during my interview as “25% coding and 75% management.” As anyone who’s been a developer knows, 25% coding is a tricky number. It’s not low enough to approach “Zuck’s gonna code”, but nor is it high enough to really be able to achieve a zen state of development nirvana. Making things even trickier, Rally had recently finished moving from PHP to Scala, a language which I knew very little about, other than that it was riding the functional language wave.

Little did I realize that by six months in, I’d be viewing both Scala and its use inside the health technology space the same way I viewed peanut butter cups; as a beautiful fusion of two independently wonderful things.

You got your functions in my objects! You got your objects in my functions!

First, Scala. In one short sentence, it’s a functional object-oriented statically-typed extensible language which runs on the JVM. Buzzwords aside, it’s a pretty astonishing collection of linguistic attributes, some of which I’ll touch on. Most impressive to me is the melding of a functional programming language with an object-oriented one. As paradigms go, these two tend to be rather at odds with each other, especially to the adherents of both. Not that it hasn’t been tried before, but the depth of Scala’s use of both is unique – it embraces the best aspects of both functional programming as well as traditional object-oriented design and merges them beautifully.

The hybrid approach is a more natural way of thinking. Objects have always been described in introductory lectures in CS101 in terms of real-world analogues of, well, objects; “Car” (a class) is a subtype of “Vehicle” (an abstract class), “my crappy silver Toyota Corolla” (an object) is an instantiation, and all that. Functions, on the other hand, are usually described by a process and a result – I give grain to a miller and get back flour, I give flour to a baker and get back bread. Given a bit of thought, one can model both of these with the opposite method, but it’s not nearly as viscerally satisfying, or, for the poor CS101 student, as easily understood. Scala bridges the gap and allows programmers to think both ways, although admittedly that’s likely to make purists grouchy. For me, however, it makes it easier to consider the problem at hand with all the tools I have available, especially when it allows certain concepts to be both simpler to understand as well as orders of magnitude faster to develop.

I’ll stop there because I don’t want to steal the thunder of future posts on this blog, which will no doubt cover the benefits of actors, existential typing, traits vs. inheritance, and more. If you absolutely need that information right now, there’s a vibrant Scala community happy to help (even if it’s still comparatively small so far). I want to get back to another reason that I’ve come to love Scala. Less obvious than the fusion of objects and functional programming is the fusion of brevity and readability, which granted me the ability to succeed at what I had assumed was going to be a hopeless task – being a productive developer during what little time I had to code.

Type inference is the first step to achieving brevity without horrible runtime errors, and Scala really nails it. You’ll be able to write a nice, clean-looking line like:

var kidsAges = Map("Johnny" -> 5, "Julian" -> 3, "Jessica" -> 10)

In Java, this would be an ugly multi-line beast involving boilerplate code and too many angle brackets. In Ruby, it would look much the same, but without the protection of a typed map which could cause a lot of trouble if you ended up adding (“Billy” -> “two”) later on. Obviously, you’d catch it in this simplistic example, but if you’ve used Ruby for a long time you’ve quite possibly run into this at least once – Scala heads you off at the pass.

The only other productivity booster I’m going to touch on, mostly because it’d be almost criminal to write a Scala blog post and not mention it, is Scala’s pattern matching, which takes the much-maligned case statement and makes it usable, readable, and awesome:

val result = x match {
    case 1 => "one"
    case 2 if false => "never gonna happen"
    case 2 => "two"
    case _ => "many"

Because of these two attributes (and yes, many more), and the functional language tendency towards short and sweet functions rather than monsters, I’m able to write useful code in the 30-minute chunks of time I tend to have, instead of being hopelessly and semipermanently derailed by the inevitable and constant interruptions that occur during the other 75% of my time.

Lastly, I just want to mention one last benefit to Rally’s adoption of Scala, albeit one that won’t apply to some of you reading this post – and that is a concept important to Rally for other reasons: neuroplasticity. Rally Engage, our first product, is all about using technology to increase health engagement and help achieve positive health outcomes. Engage helps recommend actionable and achievable diet and exercise goals to users, and while studies have shown the link between diet, exercise, and keeping your brain young, just as important is learning and trying new things (a common thread of many goals and topics inside the product). Just like Scala helps find new routes around what can be intractable problems, the act of learning it keeps my brain doing the same thing.

So for that, a tip of the hat to Scala and Rally, for helping to keep me healthy. As Oscar Wilde said about extensible programming languages, “To expect the unexpected shows a thoroughly modern intellect.”