Last year at FOSCON (and the next day at OSCON), _why showed the first animated installments of his "Least Surprised" cartoons, to the delight of all present. In one of them, Time.now.is_a? MagicTime, Malsky asked his audience to imagine what Ruby will be like in three years. The first suggestion? "Maybe we’ll have our own virtual machine by then." Malsky was appalled. "No, no! Come on, guys! Three years? Ruby will have ten virtual machines built inside every metaclass by then. Be creative!"

For several of us sitting in the back, "ten virtual machines built inside every metaclass" was one of the biggest laugh lines of the evening.

Of course, it’s still absurd — but maybe only by two or three orders of magnitude instead of four. I’m amazed at what’s happening in the world of Ruby and high-performance virtual machines. I’m personally aware of seven (!) projects to either build a Ruby VM or implement Ruby on an existing VM:

• Of course, there’s YARV.
• JRuby, which has been around for a long time as a Ruby interpreter, is starting to become a true bytecode compiler in the Jython style.
• There are no less than three projects to implement Ruby on the .Net CLR, building on the lessons of IronPython.
• The Cardinal project, to implement Ruby on Parrot, has been restarted by Kevin Tew. (And Parrot itself is making serious progress again, after some difficulties.)
• Finally, there’s a project underway to implement Ruby on Nicolas Cannasse’s Neko VM.

Naturally, there’ll be some winnowing of these options over time. But it seems clear that the Ruby community will end up with at least three solid VM options: YARV, JRuby and some variety of Ruby on the CLR. The core Ruby developers are strongly committed to YARV. The CLR version is too important not to do (and to my mind, last week’s announcement of IronPython 1.0, still as an open source project, makes a mature Ruby implementation on the CLR even more likely). And of course, Sun has now hired the two main JRuby developers, throwing at least some of their weight behind that project.

Come on, guys! Three years? Ruby will have three virtual machines that’ll run in every kind of IT environment by then. Be creative!

(And there is still room for serious creativity there. I’ll write more about that soon.)

I’ve been quiet here for a while. Mostly I’ve just been busy, but the reason I’ve been so busy is that the summer was one disaster after another.

OK, that’s not quite fair. There was a lot of good stuff this summer (including RailsConf and OSCON, which were both terrific), and sometimes I went for several days at a stretch without anything bad happening. But it did seem that every time I turned around, there was some new setback.

• I started the summer with a recurrence of a strange networking problem on my laptop that had plagued me earlier in the year. This time I finally found the cause: Salling Clicker, left running in a state where it was searching for my phone. Apparently Bluetooth and AirPort share enough of the networking stack that one can really interfere with the other. But I lost a couple days to messing around with this before I finally figured things out and got it fixed.
• In early July, my wife’s grandmother died. She was a wonderful lady, and very dear to me; of course, that week was difficult for the whole family.
• Two weeks later, I got hit hard by a strep infection. I nearly had to cancel my appearance at the Des Moines NFJS, but started feeling better just in time. (I would have hated canceling, because I’d already had to skip the Austin show due to the funeral.)
• But then again, maybe I should’ve canceled, because just as I stood up to give my first talk in Des Moines, my hard drive crashed. It was fun getting through five talks without a laptop! (Eitan Suez and a couple of the attendees lent me their laptops for three of the talks, which helped a lot.) Due to my travel schedule, my backups were a bit out of date, so I lost about 4 weeks of email.
• I just barely got the new drive installed, and the restore completed, before I had to take off for OSCON. And when I got back, my DSL service was out. It was out for 16 days! Needless to say, a change in ISP is in the works.
• Two weeks ago, I came down with strep again. Because I’d had strep so recently, this time they gave me a really powerful antibiotic, which makes sense, and I felt better pretty quickly. Unfortunately, they didn’t really warn me about that, so I didn’t take some necessary precautions, bringing us to:
• Now I have thrush. Yucko.

Oh well … I’ll stop complaining now, and I’ll start writing about more pleasant things soon. :-)

I was thrilled to learn today that my friend Eitan Suez has released his JMatter application development framework as open-source software.

I’ve been a huge fan of the idea of Naked Objects since I first saw Richard Pawson talk about the idea at OOPSLA in 2000. (He called the idea "expressive systems" then, but only the name has changed.) I introduced the idea to Dave Thomas at OOPSLA the following year, and he began spreading the word through a series of talks at NFJS symposiums.

Unfortunately, programmers who became interested in Naked Objects as an application-development strategy frequently turned away from it again after becoming frustrated with the poor quality and design of the default naked objects application framework. Eitan, however, took a better approach: he decided to write a better framework. And he wrote it in the context of a real application he was developing for his employer, which is always the best way to drive framework design: validating ideas in the crucible of real-world constraints. The resulting framework is JMatter, and it’s a great tool. If you’ve ever wanted to explore Naked Objects as a way of building cool, powerful business applications quickly — or if you’ve already tried Naked Objects but decided it wasn’t ready yet — you owe it to yourself to give it a try.

(Disclaimer: my enthusiasm for JMatter has nothing to do with the fact that my visage is prominently featured in one of Eitan’s sample application screenshots. Quite to the contrary, in fact. :-)

The NFJS 2006 Anthology is available for pre-order. The book is an excellent collection of articles by NFJS speakers, based in most cases on talks we’re giving during this year’s symposiums. Neal Ford did a great job as editor, and it’s being published (of course!) by the Pragmatic Bookshelf, which means you can get a paper copy, a PDF, or a combination.

My article is a bit unusual. Rather than expanding on one of my talks, I wrote instead about a common theme that characterizes many of my recent talks: old ideas or technologies that are showing their worth again in the modern software development climate, and the importance of knowing the history of our field. The article is called Buried Treasure, and I’m thrilled that it’s been selected as one of two articles that are available on the website as teasers for the book. I’ve love to hear your feedback!

Woohoo!

Ted Neward writes about Microsoft's Monad shell language, extolling its coolness ... which is fine, except that he goes wildly wrong by titling his post "Need Ruby? Nah -- get Monad instead".

Ted, my friend, thou doth protest too much, methinks. Pointing out cool technology is fine (and to some degree I agree that Monad is cool) but when you make a comparison like that, you have to back it up. And in this case, Monad falls woefully short, by your own criterion.

Here's my Ruby version of your Monad "get-answer" script:

#!/usr/bin/env ruby

require 'open-uri'
require 'cgi'

fail "Please ask a question." unless ARGV.size > 0
question = ARGV.join(" ")
query = "http://search.msn.com/encarta/results.aspx?q=#{CGI::escape(question)}"
page = URI(query).read or fail "Couldn't get response."

puts

if page =~ %r{<div id="results">(.+?)</div></div><h2>Results</h2>} 
  response = $1
  response.gsub! %r{<\s*a.*?>.+?</a>}, ""  # remove links
  response.gsub! %r{</(div|span)>}, "\n"  # insert newlines
  response.gsub! %r{<.*?>}, ""  # remove tags
  puts response.squeeze("\n").rstrip  # collapse adjacent newlines and trim whitespace
else
  puts "No answer found."
end

Sorry, Ted, but I think that's far better than the Monad version. And you do, too. Just a month ago, you wrote this:

While speaking at a conference in the .NET space [...] Rocky Lhotka once offered an interesting benchmark for language productivity, a variation on the kLOC metric, what I would suggest is the "CLOC" idea: how many lines of code required to express a concept. (Or, since we could argue over formatting and style until the cows come home, how many keystrokes rather than lines of code.)

Leaving aside the fact that this is a very old idea, I agree that this is a mostly valid measure of language power and productivity (although I prefer to measure it in syntactic tokens, as Paul Graham does). And Ruby is clearly the winner.
Ruby: 17 lines, 76 tokens
Monad: 37 lines, 217 tokens

Plus, my Ruby version will work on my Mac, your Windows machine (even pre-Vista), Linux machines, my OpenBSD server, and those nice Ultra machines that Tim Bray is so kindly directing to worthy projects. So Ruby is more powerful in another dimension as well. (True, you would have to install Ruby separately on some of those systems. I'm so glad Apple doesn't suffer from NIH syndrome as much as Microsoft does.)

Don't get me wrong -- as a Windows shell language, and especially one built into Windows and supported by Microsoft, Monad is very cool, and a vast improvement on anything they've ever produced in that space. But it looks like Microsoft still missed some lessons, even in that restricted space.

There was a time when many serious systems were built as shell scripts, and even batch files. But in these days of serious scripting languages like Perl, Python, and Ruby, I can only think of one reason to write a substantial bulk of code in a shell scripting language like Monad, and that's if you absolutely have to know that it will run without requiring a separate software installation. Shell languages have to walk this awkward line between terseness for convenient command-line use, and the constructs necessary for serious programming, and that makes them inherently awkward for the latter task. These days, shell languages are mostly useful for ad hoc on-the-command-line throwaway programs, and what I've seen of Monad tells me that it's a little too strict and verbose for that job.

I do think Monad might have one seriously great effect: it might teach Windows developers the importance of designing utility programs with an eye toward cooperating with other programs in a scripting environment. But I don't see it displacing Ruby, Python, or Perl anytime soon.

As for Ruby in particular, I think Edd Dumbill said it best:

... the subtle elegance of the Ruby idiom is a slowly appreciated and highly satisfying flavour.

My friend Dan Steinberg's daugher, Elena, died suddenly yesterday of bacterial meningitis. Many of Dan's friends are devastated today, and of course all of that is nothing beside what Elena's family are feeling.

Other friends had the idea of a lovely little graphic button we can use to pay tribute, express sympathy, and most of all remember a little girl who meant so much to those who loved her. Click on it to read Dan's brave, eloquent writing about her, and comments from friends.

And when you see that little graphic on sites around the web, treat it as a reminder to tell your own children that you love them.