lesscode.org

This chart showing the number of requests for different languages on O’Reilly’s Code Zoo is interesting:

Yesterday we added two new languages to CodeZoo: Python and Ruby. You can see from the language requests graph, above, the languages for which we got more than a few requests (I’ve left off Cobol and the others that only were requested a couple of times). From this, the choice of Python is completely obvious — it was the winner in the request race, beating out C++ and many other languages that might be considered “larger” by other metrics. In addition to the clear demand for it, Python is a natural fit for O’Reilly, since we publish a great deal of treeware and online material about Python, and cover Python extensively at our conferences (especially at the Open Source Convention taking place this week).

Ruby, however, is tied for fifth on the list, and in raw component counts on our site, it is the smallest of the languages we support. As we’ve discussed on Radar over the past few months, we see Ruby as an emerging force in the open source world, driven by interest in Ruby on Rails, and by the excellent books on Ruby written by the Pragmatic Programmers…

I was actually really surprised at how strongly dynamic languages showed up on this chart. I’m eye-balling it as there aren’t any numbers but Python, PHP, Ruby, and Perl seem to have taken down almost 50% of the requests with C{,#,++} taking down a large majority of the rest. Is this a fair sampling of the general development population? Developers with a web/UNIXy background seem to be over-represented at O’Reilly so its probably a bit skewed, no? Still, the amount of acceptance dynamic languages are gaining is pretty staggering at this point.

I’d like to advise everyone attending OSCON with an interest in dynamic languages to not miss Sam Ruby’s pie-thon Update:

OSCON 2004 was the home of the pie-thon challenge, which pitted Parrot against CPython on a test of speed using a bechmark that Guido van Rossum designed. This presentation provides an update–not only on performance, but also on language compatibility, as well as an outlook on the potentials for inter-language interop that can be acheived by a common language runtime for dynamic languages.

I was lucky enough to chat with Sam about this a bit and the little I got out of him was intriguing. The blurb doesn’t go into a lot of detail but one of things he’ll be talking about is compatibility between dynamic languages at the runtime level. Here’s a sneak peek:

<rubys>    There is a big difference between Python and
           Perl. Ruby might be someplace in between.
<rtomayko> that's interesting. I've been seeing reports of 
           the same thing from the CLR and JVM crowds
<rubys>    my favorite example: what does 
           """ print  '1' + '2'; """ do?
<rtomayko> ahh
<rtomayko> and so the strong/weak thing is down at that level?
<rubys>    it is not just that.  "+" is a function in Perl.  It 
           accepts two arguments which have types.  It coerces them 
           to numeric values, and adds them.
<rtomayko> python = '12', perl = 3, ruby = '12' (i think)
<rubys>    "+" is a synonym for "__add__" in Python.  It merely is 
           the name of a method.  What it does is up to the first 
           argument.
<rtomayko> right, I see. and so all of these languages will have 
           to shift a bit.
<rubys>    shifting all the language a bit is what .net did.  And 
           you end up with "Visual Fred" (look it up)

Visual Fred was the name proposed for Visual Basic.NET by MVPs who quickly realized that VB.NET had nothing to do with VB due to the syntactic and semantic changes forced on the language by the common runtime.