Feb
2008
I’ve been seeing a surprising trend in the articles that have come through my feed reader recently: evaluating JRuby, Groovy and Scala for use as primary languages in new, on-JVM projects. This seems to be the new and trendy thing to write about. I suppose it’s not really surprising that each of these languages is receiving such attention, they all deserve it. What is surprising is that they are all put on the same playing field. Of the three, only Ruby and Groovy are actual peers in terms of capability and design. Syntactic differences aside, both languages do roughly the same things in fairly similar ways. Scala on the other hand isn’t even in the same league.
This is about the point that most comparison rants conclude by saying “Scala is statically typed therefore it is completely different. QED.” We can actually go a bit deeper though. Scala’s entire philosophy and reason for existence is divergent from dynamic, so-called “scripting” languages like Ruby or Groovy. Scala is designed to be a mid-level, general purpose language. By “general purpose” I mean something suitable for writing large applications, enterprise class stuff, etc. Not suitable for writing operating systems or for creating quickie scripts. In short, Scala is a peer for Java more than it is a peer for Ruby.
What I think is interesting is that Scala has a number of features which make it appear to be a dynamic language (such as implicit conversions, flexible syntax, type inference, etc). These features give Scala the “feel” of a dynamic scripting language like Ruby without really sacrificing the strengths of the compiler and static typing. It seems that this illusion is so effective as to actually have fooled most people into lumping Scala in with the dynamic crowd. While this is good in the sense that Scala is getting more attention this way, it also leads to a rising misconception of what Scala is and what it’s good for.
Ironically, many of the use-cases being presented in these language comparisons are best solved by a mid-level language like Java or Scala, rather than high-level languages such as Ruby, Python or Groovy. This actually seems to be leading to even more trouble in the world of language choice as the problem domain itself becomes blurry. Many developers these days are trying to apply Ruby to large desktop application development, or (just as bad) apply Java to simple CRUD and RAD applications. It’s the old adage: if all you have is a hammer, every problem looks like a nail. Developers are starting to select languages based on “what’s hot” rather than what offers the most effective solution.
The rampant number of Ruby-Groovy-Scala comparisons is not the problem, but rather a symptom of a greater problem: language overload. Even confining our search to the JVM, we can find so many wonderful languages of every size, shape and type-system. All of these languages have their creators pushing their product as the solution to life, the universe and everything. With so much noise pervading the language arena, it’s easy to see why many developers get confused when performing that crucial selection of tools.
Unfortunately, there doesn’t seem to be a “nice and easy” solution to the problem of language selection noise. Every language will always have its proponents, people who try to sell the language as the cure for life. Getting them to just shut up and realize the imperfection of their product is just about as likely as convincing the masses not to listen to them. So it seems that for the foreseeable future, we will continue to see rants, comparisons and rationales taking languages X, Y and Z out of context and attempting to come to a sane conclusion.
Comments
I’ll note that I’m more skeptical of implicit conversion than dynamic typing for large-scale projects. Implicit conversions add magic where you would not expect it, as opposed to dynamic typing. I’ve seen this bite for C++.
I’m not sure where the description of Scala as a “mid-level” language comes from. It has a different set of advanced features from Ruby, but definitely not fewer or less interesting ones (I don’t know Groovy enough to comment on that, but its feature set has never struck me as that interesting).
On the one hand, Ruby’s open classes and things like method_missing offer a lot of flexibility for adding behaviour to a class, but on the other Scala’s implicits offer a lot of power for abstracting over behaviour external to a class that is equally hard to do in Ruby.
Basically you don’t seem to be actually taking your own point. You’re saying “Don’t compare Ruby and Scala, they’re different languages!” and then you use loaded (and not terribly meaningful) terms which do just that.
> Unfortunately, there doesn’t seem to be a “nice and easy”
> solution to the problem of language selection noise.
Depends on your definition of “easy”.
Given that good (above average) developers can learn new languages (and associated style/idiom) quickly; then the nice answer is to have a sufficiently rich toolbox and be prepared to stand up for it.
Even things like operator overloading in C++ can at times be a right solution, just not very often. This does not invalidate the tool.
It is all about choosing the best, in preference to the often chosen least worst of a poor set, tool for the job in hand.
@Eivind
I agree that implicit conversions can be terrible to try and debug sometimes, but that’s only when they’re over-used. C++ conversions would bite mainly because they’re implicitly implicit. For example, if you define a constructor class Person which takes a std::string, then suddenly you have an implicit conversion from string to Person. Scala makes you be a bit more declarative about your conversions, forcing you to add the *implicit* method modifier. It’s still a feature that needs to be used judiciously, but it’s much more controlled than in C++, therefore more predictable.
@David
Eh, maybe I just didn’t right the article well enough. I don’t see what you mean when you say that I’m “comparing Ruby and Scala.” I was *attempting* to present some of the reasons why you shouldn’t write such comparisons.
> I’m not sure where the description of Scala as a “mid-level”
> language comes from. It has a different set of advanced features
> from Ruby, but definitely not fewer or less interesting ones…
The key word here is “different”. Certainly Scala and Ruby can do roughly the same things (I can think of a few techniques possible in Ruby but not in Scala), it’s just a question of ease. How *well* can they be applied to certain problems? That’s the real issue. I would argue that the problem domains for Scala and Ruby are almost entirely disjoint, making most “real world” comparisons of the two meaningless.
@Richard
Bravo! That’s precisely what I was trying to say: it’s all a matter of choosing the best tool for the problem.
> The key word here is “different”. Certainly Scala and Ruby can do roughly the same things (I
> can think of a few techniques possible in Ruby but not in Scala), it’s just a question of ease.
Sure. And vice versa.
> How *well* can they be applied to certain problems? That’s the real issue. I would argue that the
> problem domains for Scala and Ruby are almost entirely disjoint,
> making most “real world” comparisons of the two meaningless.
Not really. There are a pretty wide range of general purpose programming tasks either would be adequately suited for.
And I am specifically objecting to and asking you to quantify your description of Scala as “mid level” as opposed to the “high level” Ruby and Groovy, which you still don’t seem to have done.
> Bravo! That’s precisely what I was trying to say: it’s all a matter of choosing the best tool for the problem.
Absolutely.
Scala, Groovy and (J)Ruby each have their own sets of unique features (and limitations) – some of which are obvious, some are subtle. Choosing which is “right” for you can be difficult. Often, there is no “right” (or even obvious) choice – you just have to go with the best trade-off for the situation at hand.
It does take time and effort to make an informed choice. Sometimes we invest the time and effort. Sometimes we don’t. Sometimes we agree (with others) about our choices. Sometimes we don’t.
Having these choices is a feature of our rich and competitive language ecosystem. I don’t consider it a “language overload” problem. I like having a range of languages to choose from (even if the choice can be difficult).
Or could it be said that C++ and Scala both have the same level of implicit conversion, but that C++ uses convention over configuration?
> And I am specifically objecting to and asking you to
> quantify your description of Scala as “mid level” as
> opposed to the “high level” Ruby and Groovy, which
> you still don’t seem to have done.
Point taken. Expect a post to be forthcoming on this subject…
@Tom
Yes, I suppose you could say that. However, I tend to think that C++’s implicit conversions is an example of misapplication of “convention over configuration”. Sometimes you don’t want things to “just work”, because often it will “just work wrongly”.
Yeah the typical Java problem of framework overload seems to be replaced or supplemented by language overload. We are in for a greeeat time where we no longer have the time to solve actual problems, we’ll be too busy researching, comparing and selecting technologies.
>For example, if you define a constructor class Person which takes a std::string, then suddenly >you have an implicit conversion from string to Person. Scala makes you be a bit more >declarative about your conversions, forcing you to add the *implicit* method modifier.
If you declare the constructor as explicit (e.g. explicit Person( const std::string& ) ), the conversion is no longer implicit.
@Casper
lol Very nice indeed.
@Steve
Ah, I didn’t know about the explicit modifier. That should make my life a bit easier the next time I’m unfortunate enough to have to write C++ classes.
I completely agree. But I don’t see language overload as a problem (initially there will be some confusion), but as an opportunity. Even for large systems, Scala might not the only solution. It could be a combination of Scala,Ruby etc (Of course you can replace actual names with any language).
What strikes me is that there is .NET with several, probably more languages to choose from than for the JVM. Why doesn’t anyone complain about language choice overload on this platform?
Because JVM developers are much louder, more annoying and more numerous than CLR devs.
@KoW
The difference is that .NET had the benefit of looking at Java and have made certain compromises (no class loader, no interpretation etc.) while at the same time being very pragmatic about it, i.e. added language level constructs such that developers do not necessarily need a CS degree to use it.
It was also designed from the ground up for interoperability and multiple languages so while JNI is a pain in the *beep* it is quite natural on .NET to issue a pinvoke if you need something from the platform or another layer sitting next to you.
And of course, C# already has reified generics, closures, type inference, continuations, switch on strings, properties, events and all the other stuff we now whine about in Java.
Post a Comment