No Thanks, I’ll Stick With Ruby

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? Nahget 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 = "{CGI::escape(question)}"
page = URI(query).read or fail "Couldn't get response."


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
  puts "No answer found."

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 wrongas 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.

Dear Elena

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.

More than loyalty

Kathy Sierra blogged recently about the Rails Guidebook, and along the way mentioned the loyalty that customers have toward the Pragmatic Bookshelf:

Let me put it this way, in an effort to support this young publishing company, loyal readers will often go to their site to buy directwhich means paying more for the books than they’d pay on Amazon.

I won’t argue with that; there is a lot of loyalty there. Dave and Andy are good friends of mine, and I certainly want to support their company by buying direct, and I encourage others to do so.

But it’s not just loyalty. I would buy direct from them for a very practical reason, and last night I realized that it goes beyond even thatI found myself wanting to buy a Pragmatic Bookshelf book that hasn’t been written yet (and that, so far as I know, they aren’t even planning) in preference to an existing best-of-class book. That’s right; I prefer the Pragmatic Bookshelf book on a topic to a classic from another publisher, even when the Pragmatic Bookshelf version doesn’t exist yet.


Because from the Pragmatic Programmers, I can buy a POPEa Plain Old PDF Ebook. Not tied to a special reader, or a single machine, so it’s trouble-free. And it’ll be on my laptop wherever I am, instead of sitting on a shelf at home somewhere.

Rails podcast

Geoffrey Grosenbach invited me to appear on the Ruby on Rails podcast, and the interview was posted yesterday. He heard me speak on Metaprogramming Ruby at FOSCON in August, and wasn’t interested at all … but eventually decided he should be interested in the topic, so we spent a little while talking about metaprogramming, why it’s an important topic for Ruby programmers to understand, and how to get started. I think it turned out really wellcheck it out!

OOPSLA Essay: Extreme Programming Annealed

(Brian Marick blogged a couple days ago about the OOPSLA 2006 essays track, and I remembered that I should’ve blogged about last year’s event a few months ago.)

Last year was the inaugural OOPSLA essays track. I was pleased to see it, because I enjoy the kind of papers that OOPSLA used to be famous for. The essays track (as well as the “Onward!” track that has been featured at OOPSLA the past few years) is intended to provide a forum for research that’s a little less “hard” and empirical than the typical modern OOPSLA farebut no less important.

When I saw the announcement of the essays track last year, I was thrilled, partly because I had done some unpublished work that seemed perfect for the new forum. I wrote up the essay, and was thrilled to have the opportunity to present it at the conference. Brian, the track chair, lined up Kent Beck to respond to my essay during the presentation, which made for a fun discussion.

As it happens, my essay, A Simple Model of Agile Software Processes, -or- Extreme Programming Annealed, was the only essay accepted last year, out of several submissions. I wasn’t privy to the details of the review process, of course, so I don’t know why the other submissions weren’t accepted.

But the track was very well received, and I certainly hope it continues and grows.

I certainly wouldn’t hold my essay up as an exemplar of an OOPSLA essay, but I do hope it might suggest the kind of form that the essays committee is looking for. I hope to see more (and better) examples in this year’s essays track.

subscribe via RSS or JSON Feed