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.
No comments:
Post a Comment