The Philosopher’s Song  

By Bill de hÓra under Languages on 22. December 2005

I’m not a programming language designer, but I know what love is.

Bruce Eckel:

I think we’ve mostly been hearing from people who have come from Perl and found Ruby to be a ‘better Perl, with objects that work,’ or people who are finally convinced that dynamic languages have merit, and so mix the enthusiasm of the first time dynamic language user (quite a rush, as I remember from my 2-month experience with Perl many years ago) with their experience of Ruby. So far, I’ve heard from the hyper-enthusiasts about Ruby being cool, or that it has begin-end blocks and they don’t like indentation to delineate scope. That kind of thing: ‘I like this, I don’t like that,’ which is fine but not compelling.

David Heinemeier Hansson:

I’m losing track of the ill-conceived comparisons, but I do know what’s astoundingly clear: Bruce Eckel doesn’t like Ruby, he doesn’t like the attention its getting, and he doesn’t like people such as Bruce Tate fueling that attention. No beef, that’s cool. But why not just say it like that? You could even have presented yourself as the polar opposite to the so-called hyper-enthusiasts: A hyper-detractor! The label comes complete with a cape, an evil smirk, and long tirades about how the other side is no match for your master plan.

Another issue is a perennial side-show in the world-wide computer programming circus: the spectacle of nerds arguing over programming tools. The data model can’t represent the information that the users need, the application doesn’t do what what the users need it to do, and instead of writing code, the “engineers” are arguing about Java versus Lisp versus Perl versus Tcl. If you want to know why computer programmers get paid less than medical doctors, consider the situation of two trauma surgeons arriving at an accident scene. The patient is bleeding profusely. If surgeons were like programmers, they’d leave the patient to bleed out in order to have a really satisfying argument over the merits of two different kinds of tourniquet.

Programmers would rather squabble about minituae - it seems this transcends community or language choice. Yet a Python programmer can become functional in Ruby in short order, and vice versa. That’s an important message for anyone that worries about how a software system is going to be supported a few years out - it suggests that with respect to the job market, the languages are interchangeable. They are platform neutral, both run on the JVM or interoperate with .NET. That’s an important message for anyone who requires back-end systems integration. They complement mainstream enterprise development by providing a disciplined approach to scripting when scripting is what’s required. That’s an important message for anyone who ever got saddled with a now-critical, yet spaghetti-like webapp that grew out of a quick scripting hack. They are highly suited for those who need to write software but do not have a systems programming or pure CS background. That’s an important message for anyone who just wants to get something down without going to market for engineers. They’re productive, and while we can’t tell you what productivity is, we know it when we see it. What’s my point? That there are plenty of interesting messages to be sending out, as opposed to the one that suggests programmers will always, every time, without fail, quibble. Is it really that inconceivable that the growing interest in particular frameworks (Rails) and languages (PHP) by enterprise types floats all dynamic boats?

Ruby’s a great language. Ditto Python. About the best anyone can do in terms of differentiating the core languages is mumble something about elegance, or how good closures[1] are. Yet for about 98.6% of what you do as a working stiff, the core language differences are irrelevant[2]. You might get hung up on whitespace or the end keyword, but that’s a bit like getting hung up on driving on the “wrong side of the road” when you go on holidays. You’ll get used to it, unless you intent to expend a lot of energy refusing to get used to it.

Still, from all the blog noise this gem of quote is worth pulling out:

But Ruby has only emerged in the last 5 years or so, and only gotten the catalyst in the last 2. Right now, I’m looking for a dynamic language that I can sell into conservative accounts, because I can be more productive with them for certain problems. I actually like Python, Lisp and Smalltalk, though of the three, I’ve only used Smalltalk in anger, and only on very limited apps. Iwould be happy with any of the 3 as an alternative. Smalltalk’s the most pure, Python the most approachable, and Lisp the most powerful. It’s jsut that as a consultant at conservative Java accounts, I need to also consider market penetration. Java has already popped. In Ruby, I see a possible catalyst in Rails. In Smalltalk and Python, I don’t. But since Beyond Java, I’ve used Rails, Spring and Plone on various applications, and been peased with each.

That’s from Bruce Tate, commenting on Bruce Eckel’s entry. That kind of realism coming from a developer is refreshing.

  1. Anyone who really feels Ruby closures are a critical technical factor should be wondering why they’re not develping in Smalltalk or CLisp.
  2. Python is further along in terms of library support. Libraries do matter, but in terms of core langauge design, they are a contingent diffentiator.

9 Responses to “The Philosopher’s Song”

  1. Anonymous:

    “* Anyone that really feels Ruby closures are a critical technical factor should be wondering why they’re not develping in Smalltalk or CLisp.”

    You almost made it! You were arguing against language quibbles, and it was good, and then you had to resort to the very thing you were arguing against in a footnote.

    comment at 22. December 2005

  2. Bill de hOra:

    “You almost made it!”

    LOL! You got me. But there is valid point here - closures seem to be a common technical argument pro Ruby compared to Python/Java/C#. All other things being equal if closures count for that much, then s’talk and CLisp get to be at the races.

    comment at 23. December 2005

  3. Zilch Zero:

    So why is it that a loudmouthed boy from Denmark, who managed to come up with an ORM (you go, dude!), has the balls to deride Mr Eckel, who — among other things — sat on the C++ language committee for the better part of 8 years?

    Appears the hype Tim O’Reilly is bathing DHH in — for his (O’Reilly’s) benefit to be sure — has finally gone to the boy-wonders head beyond the point of annoyance.

    Ed. — Portions of this message have been marked flame-bait.

    comment at 25. December 2005

  4. James Britt:

    “Two minority language communities going at it over book sales, is mildly embarrassing …”

    PLEASE, I beg of you, please do not advance the idea that these dopey squabbles are occurring on behalf of the Ruby or Python communities. Many Rubyists are quite embarrassed by these sorts of petty tirades. The narrow-minded views of many Railers should not be conflated with any general opinions of Ruby hackers.

    I suspect the same is true for most Pythonistas.

    comment at 26. December 2005

  5. James Britt:

    “All other things being equal if closures count for that much, then s’talk and CLisp get to be at the races.”

    Sort of. All other things are not equal, though. Syntax matters, as does a free, robust, cross-platform implementation with a decent set of equally robust, cross-platform libraries.

    I’d love to be able to develop Web apps on Windows and simply drop them into place on my Linux server, while sharing code with folks using Macs, and know that code revisions are safely tracked through SVN or darcs.

    comment at 26. December 2005

  6. Robert Sayre:

    Closures do matter and JavaScript wins :)

    comment at 03. January 2006

  7. Christopher Dunn:

    It is important to recognize the variety of use cases when discussing the appropriateness of a language. There are more than just “enterprise systems programming” and “large-scale applications development”. The best uses for dynamic languages are the most oft-neglected by serious programmers:

    1) Proto-typing
    2) User-interfacing


    Ruby and Python are both wonderful for rapid proto-typing. Python may have an edge in library availability and in its similarity to C++/C# (if one of those happens to be the eventual target). For C#, maybe Boo is best. If only portions of the script will be translated into a statically-typed language, then Ruby stands out as it eschews reference-counting (though Boost-Python works well to hide the complexity).


    Tcl is the typical choice, a horrendous one because it so severely limits both productivity and maintainability. But Ruby, Perl, Scheme, and many others are much too difficult for a non-programmer. This is where Python shines. The things that hard-core programmers dislike about Python are precisely the things that make it so valuable for non-programmers. It’s a language which encourages maintainable code no matter who writes it. Python makes important things like documentation, modularity, OOP, and testing so trivial that a part-time programmer might be induced to try them.

    The blog author correctly points out in the footnote that where Ruby is most vociferously advocated, there are many reasonable alternatives, including Smalltalk, Common Lisp, Scheme, Ocaml/F#, Eiffel, Haskell, Dylan, etc. That completely misses the great value of dynamic languages: intuitiveness.

    comment at 28. January 2006

  8. Roger Lancefield:

    (A belated) thanks for a great ‘lunch time’ read Bill. Common-sense and a voice of reason never go out of style!

    comment at 31. July 2006

  9. Path of the Digital Katana » Be the Ronin with your languages:

    […] The lesscode blog isn’t too active any more, but it has much sage advice, and a good post from last year that’s been referred to many times. “The Philosopher’s Song” is a ranging muse on the efficacy of languages, and the rage of Ruby vs. Python and the sameness of now to history. […]

    pingback at 21. August 2006