Lately, I've spent some after-hours time exploring Scala, a candidate "next-generation Java" that combines functional and object-oriented features.
It's intriguing. I have that slowly growing sense of excitement I've felt when discovering some of the other standout tools in my repertoire: Eclipse, Emacs, Ruby, Spring, and Hibernate, for instance. It has an elegant combination of features that relieves a wide range of programming annoyances.
Scala offers direct-to-bytecode compilation and seamless two-way interop with Java without the performance issues introduced by Groovy metaclasses. It can achieve the reduction in boilerplate code I've seen with Ruby syntax and mixins and type extensions, without sacrificing the static typing that eases maintenance and integration in large systems. And it offers functional behaviors without diverging from a reasonably Java-ish look and feel, which makes it an easier pitch to organizations using Java.
So in the name of lending another voice to the cause, I will offer an occasional article on my experiences with the language. Rather than spend time attempting to teach it from scratch, I'll simply assume high fluency with Java and relate Scala to Java as best I can. (I am sure my efforts will prove amusing to Scala gurus, hence the theme "Falling Up the Stairs." :-)
I will also aim for examples that resonate with most Java application developers, because frankly, Scala can be daunting. Some of the material offered by the admittedly excellent Programming in Scala and by online tutorials is more familiar to computer language experts; I've talked to a few workaday programmers who felt put off by this and as a result questioned the relevance to "real-world problems."
Finally, I hope to help dispel the myth that adding languages to an environment always adds complexity. This view is generally held by management, which for the most part still equates languages with platforms. In that mindset, a new language is supposed to mean costly tools and training, long ramp-up times, sparse and poorly documented libaries, no leverage of established applications, and new development silos out of which teams can no longer share code or skills.
Thanks largely to wide use of virtual machines, this is no longer true. Rather than build from scratch, more language designers are now choosing to build on the Java and .NET platforms, whose SDKs also offer a vast established feature set and allow new code to coexist with more traditional languages like Java and C#.
In the VM world, learning a new language is not much different from learning, say, Spring or Hibernate. You inhale a six-hundred-page manual, get comfortable with some new concepts and syntax and libraries, and then set about improving maintainability and time to market, with the rest of your work environment intact. Idiomatic fluency of course takes time, but that's true of any technology with a rich feature set.
The point is that the language is just a tool; it's not a different world where everything is foreign and strange. You can pick and choose the parts of an application that can most benefit from the alternate language, and apply it to only those.
Ultimately this will lead to a style of programming where it will be as natural to pick the right language for a task as to pick the right libraries. And as several well-regarded programmers have already commented on this topic, I won't sermonize further.
On to Scala.
(Disclaimer: The above opinions are mine alone and do not necessarily represent the views of current or former employers.)
8 years ago
