Scala SIP-18 and the Aftermath of Dissent

This post is about the recent semi-meltdown about Odersky's Scala Improvement Process nomination SIP-18. In a nutshell, Odersky claims a special language feature import would prove a beneficial means to establish the piece of mind that some of Scala's more advanced and "contentious" language features are not present in a given code-base. Suffice it say, this issue has a polarizing collection of pro's and cons.

The Pro's shortlist:

• If I know certain language features (Higher-Kinded Types e.g.) are bad for performance and will (in general) freak the Scala newbies on our team out, then unless our timid newbies see @import Higher-Kinds they can rest assured this is a Monad Free Safety-Zone.
• Odersky, in essence, argues that language constructs such as Existential Types are necessary for making sense of Java's Wildcard types, but application developer abuse of this feature can lead to brittle application code with compile-time type errors revealing themselves through some cryptic error messages.  SIP-18 could thus establish a  policy that could obviate a befuddling code-base evolution.
• Requiring an explicit import of categorical language features could seemingly produce a beneficial pedagogical side-effect.  Imagine this: after reading the few texts about Structural Types and still being clueless after the first few passes, a blossoming young Scala programmer throws his/her hands up and vows to return to the matter at a later date.  2 months pass, that day has not come, but the confidence is growing and our hero[ine] decides to copy/paste something from a blog that seems to address a current problem.  Without @import StructuralTypes at the top of their source, the compiler resolutely states you can't do "type T = {def receiveUpdate():Unit }" without explicitly enabling support for Structural Types.

Now the cons:

• Boilerplate, boilerplate, and more boilerplate.  This would add boilerplate everywhere (imagine what it would do to an innocent little Stack Overflow post.  Follow the link to SIP-18 discussion thread and search for "Rex Kerr" or "boilerplate").
• A language feature like this could actually cause inertia for the would-be Scala convert/adopter by creating a sense of an additional layer of complexity in a language already tagged as a paradigm mindbending, academically stuffy programming language.

After reading through the lively banter, I agree this should be a style-checker's feature and not some force that imposes itself into your daily interaction (over and over and over) with the language.  I mean, Martin Odersky is someone I kind of worship, so there obviously is some merit to this proposal, but in this case I respectfully disagree and really hope this doesn't make its way into my Scala-crafting horizon ever!  I was always a little concerned about how the language would evolve after 2.9.1 given what feels like it's father's abandoning affair with the monetarily alluring TypeSafe venture.  I didn't however, think it would lead to this much drama this quickly.

And Now Scala? A JVM hacker's trip down memory lane ...

Many many moons ago, I was a self-proclaimed Java programming enthusiast who once uttered statements along the lines of "I speak Java almost as well as I speak English". Ironically enough, this was around the same time that my days of being a traditional "Software Engineer" had reached critical mass. I devoted myself to going back to school to learn how to convince the computer to think just like like me, so I could be free to think about really challenging problems and not have to do all this unfortunate typing you have to do in Java. There were others during that period who shared a similar distaste for boilerplate, but instead of choosing to study AI in grad school, they (by the Grace of God) instead went on to invent new languages for the JVM!

While finishing up grad school (at an apparently dissatisfying pace), my wife actually found a real job at the University of Georgia and voluntold me to apply. It was for a position in Bioinformatics, a field notoriously littered with the greasiest of perl hackers. Yet there stormed I, with Eclipse by my side, ready to change hearts and minds by javacc'ing my way through one insane text manipulation-based "pipeline" after a another. I was chivalrously determined not to be denied until that nightmarish perl was left with nothing to do but fade off into the sunset. If I were Bruce Wayne, Robin would have turned to me and said "Holy unsustainable meta-models and templates Batman! You're writing more code to auto-generate non-reusable code than if you just wrote plain-old Java in the first place".

But give me some credit though, because at just about that time I somehow caught wind of this new language called Groovy. It was literally a dynamic (self-proclaimed) boilerplate buster of a language that still let me pretend I was writing Java while I got my head around these new things they called "Closures"! A marriage made in heaven, and I never looked back on my way to securing a wonderfully exciting position at Monsanto.

So a funny thing happened on my way to taking over the Java world with Groovy ...

I found myself involved in a project requiring me to write software that was more "enterprise oriented" in nature. Let me just tell you, writing a non-trivial distributed system in Groovy can do funny things to a man. I don't know if you can truly have an appreciation for type-safety until you try to write most of all core components for a healthy-sized distributed, custom-class loading system from the ground up, and you experience the repetitious joy of what it is like to start all but the last of a series of "external processes" only find that just after firing up the final component, you get that all too familiar late-night knock at your door from your new BFF (the dreaded runtime exception). I mean, the dynamic type system can't possibly conclude that you haven't jacked up a meta-class somewhere such that at runtime, something could provide some context for those unsightly blemishes IntelliJ would incessantly warn me about. I eventually entertained so many complaints from IntelliJ that I started soothing it with Shakespeare ... "IntelliJ, methinks thou doth protest too much!"

But as my exhausted days with Groovy were coming to a sad but amicable end, I was really really starting to enjoy the functional influence pervasive in Groovy, especially in this nifty concurrency API known as GPars (The astute reader will pick up on my overwhelming devotion to Groovy, such that I tried to compensate for its like of Just-in-time compilation by overclocking it with currency). Fortunately, our application was JVM friendly, and the guy who masterminded it had been drinking some serious Scala Kool-aid for quite some time, so his examples and my blossoming over-confidence with the functional approach was enough to reel me in.

So here I am; now a crusader so passionate about Scala that I am inspired to blog about its role in reshaping my beliefs about the fundamental process of crafting computational solutions. Scala has obviously been around for a little while, so I am certainly not the first to start a blog with it as a prominent feature.

Rest assured, this will not be a reinvention of the super-awesome technical Scala Blogs such as Jesse Eichar's Daily scala. Instead, I intend to offer a self-aware mix of motivating code snippets surrounded by a qualitative narrative focusing on the way these game-changing players (Scala, NoSQL, and the distributed system renaissance) are continuously impacting the essential way we express solutions to the challenges of our day.

Behold!

This is my first blog for the Reified Monads blogsite.  So let me briefly tease you with what you might expect from it.  As a Scala and problem solving enthusiast, my intent is to help demystify aspects of how you might really want to appropriately insert functional techniques in your code as well as how to reconcile those with the tradional OO capabilites Scala affords as well.  I am by no means an expert, so I imagine this being a blog-site with an evolving level of sophistication.

I don't view the fact that my fluency in Scala is a stratosphere or two away from Martin Odersky's (or the slightly less immortal Daniel Spiewak for that matter) as a bad thing.  My intent is to paint a humble picture of what real mortals encounter in their everyday practice of developing software for solving problems with NoSQL stores and Scala as their primary weapons.