Skip to content
Print

Language Choice Overload

20
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

  1. 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++.

    Eivind Eklund Wednesday, February 20, 2008 at 4:25 am
  2. 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.

    David R. MacIver Wednesday, February 20, 2008 at 4:39 am
  3. > 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.

    Richard Wednesday, February 20, 2008 at 8:25 am
  4. @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.

    Daniel Spiewak Wednesday, February 20, 2008 at 8:28 am
  5. @Richard

    Bravo! That’s precisely what I was trying to say: it’s all a matter of choosing the best tool for the problem.

    Daniel Spiewak Wednesday, February 20, 2008 at 8:29 am
  6. > 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.

    David R. MacIver Wednesday, February 20, 2008 at 10:20 am
  7. > 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).

    Jon Mann Wednesday, February 20, 2008 at 10:45 am
  8. Or could it be said that C++ and Scala both have the same level of implicit conversion, but that C++ uses convention over configuration?

    Tom Wednesday, February 20, 2008 at 11:09 am
  9. > 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…

    Daniel Spiewak Wednesday, February 20, 2008 at 11:13 am
  10. @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”.

    Daniel Spiewak Wednesday, February 20, 2008 at 11:15 am
  11. 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.

    Casper Bang Wednesday, February 20, 2008 at 6:24 pm
  12. >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.

    Steve Lucord Wednesday, February 20, 2008 at 7:57 pm
  13. @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.

    Daniel Spiewak Wednesday, February 20, 2008 at 9:34 pm
  14. 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).

    bodhi Wednesday, February 20, 2008 at 11:05 pm
  15. 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?

    KoW Wednesday, February 20, 2008 at 11:18 pm
  16. Because JVM developers are much louder, more annoying and more numerous than CLR devs. :-)

    Daniel Spiewak Thursday, February 21, 2008 at 8:28 am
  17. @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.

    Casper Bang Thursday, February 21, 2008 at 9:16 am

Post a Comment

Comments are automatically formatted. Markup are either stripped or will cause large blocks of text to be eaten, depending on the phase of the moon. Code snippets should be wrapped in <pre>...</pre> tags. Indentation within pre tags will be preserved, and most instances of "<" and ">" will work without a problem.

Please note that first-time commenters are moderated, so don't panic if your comment doesn't appear immediately.

*
*