I enjoyed listening to the new edition of the Ruby on Rails podcast, consisting primarily of an interview with Avi Bryant, the creator of Seaside. I was delighted (but not at all surprised) to hear him give a lot of credit to Rails, and when asked about how to choose between Rails and Seaside, he gave an answer quite similar to my own.

It’s a nice interview; fight through the poor sound quality and give it a listen.

(This is a little overdue, but it's been a crazy couple of weeks.)

I enjoyed reading Avi Bryant's blog a few weeks ago about Mind Camp. He was delighted about getting a great compliment for Seaside from one of the Rails faithful: "I defy anyone to come up here and use any other framework to duplicate what we're doing in Rails as quickly. Except Avi."

That is certainly a great plug for Seaside, and well deserved. But Avi's delight itself pays a great compliment to Rails; "Could anyone ask for a better plug?" asks Avi, and indeed praise from the Rails camp for another web framework is high praise.

Thinking of that reminded me of a few weeks prior, when I attended the Smalltalk BOF at OOPSLA. A Smalltalk newbie was there, and asked if Smalltalk had anything like Rails. There were snickers, and a few snide-ish responses of "better than Rails."

I kept my mouth shut at the time, because it's rude to show up to someone else's party and upbraid them. But I think the question of whether Seaside or Rails is "better" is very much open for debate, and heavily dependent on your particular situation. (Disclaimer: I'm doing Rails work right now, but I'm a vocal fan of Seaside and have been introducing people to it in talks at NFJS symposiums for the past 14 months or so.)

Which brings me to the other incident Avi's blog reminded me of. In early October, Daniel Steinberg sent me a note asking for "the 30-second reason someone would use Seaside and someone would use Rails." Here's what I wrote in response:

Seaside is much more advanced but not so mature. It contains core features that are well beyond what Rails can do, and those features attack some of the most difficult aspects of web development. Rails, on the other hand, has many, many more features that attack most of the many, many tedious and mundane aspects of web development [and some of the surrounding issues like packaging and deployment, database access, and testing], and it's well documented, widely understood, and well supported.

So unless you are really comfortable with Smalltalk and/or are doing some very ambitious things with stateful web applications and complex control flow, choose Rails.

That's overly simplistic, of course, but that's what you get in 30 seconds. :-)

Oversimplified as it is, I think it's a good summary. Seaside was starting to get some buzz at one point, and then Rails came along and (it seems to me) stole most of it, and I think there's a reason for that. The reason isn't that Rails is better -- it is better in some ways, but Seaside is better in other ways. I think it's just that Rails' strengths address problems that are particularly frustrating to developers right now.

But there's a funny thing about pain: when your worst pain goes away, it doesn't take long to start being annoyed by the next worst. So it won't be all that long before Seaside's particular strengths start to look really attractive to developers who've grown accustomed to Rails' niceties. And then it'll be time for Seaside (or possibly some other continuation-based web framework inspired by it) to get the buzz again.

There are things Rails can learn from Seaside, certainly, but there are also thing Seaside can learn from Rails, and that learning will probably happen in both directions. As Avi pointed out in another blog this week, Smalltalk and Ruby are much more similar than they are different, so I see the two frameworks complementing (and, as above, complimenting) each other for some time to come.

Matz, Jim, and Why are all posting their OSCON presentation materials, which reminds me: here are the slides from my Metaprogramming Ruby talk.

(Oh, and I’ll add to Jim’s request for recordings or podcasts of Why’s performance. I’m particularly interested in a recording of "Setup and Install.rb" from Wednesday night’s FOSCON show.)

I'm back from OSCON 2005, and it was definitely a watershed event for Ruby. It was so great to be there, and to be a part of it. Ruby had a major presence every day of the conference.

Monday, both tutorials -- Dave Thomas' intro to Ruby, and David Heinemeier Hansson's intro to Rails -- were in the large tutorial room, and were packed. At Tuesday evening's extravaganza, David won the best hacker award, and Ruby got several nods in Damian Conway's unbelievably entertaining talk. Wednesday morning during the keynote, Tim O'Reilly discussed Ruby's small but growing share of the programming language book market, and speculated that Ruby might be "the Perl of Web 2.0."

David led off an eventful Thursday with a keynote on "The Secrets of Rails." All of Thursday's Ruby talks were standing-room only, and for three of them people were turned away because there was no place for them. Why's multimedia extravaganza was moved to a larger and more suitable room (thanks to Nat Torkington and the O'Reilly conference staff) and turned into the most memorable event of any conference I've ever seen.

Finally, Danny O'Brien's Friday "To Evil" keynote topped it all off, hilariously citing Ruby as a notable exception to Gandhi's famous quotation. Why? Because it went directly from "they ignore you" to "you win" in about three weeks.

Jokes aside, this week alone shows that Ruby has arrived.

Ted Neward has rediscovered Lisp and noticed the similarity between many of Lisp's strengths and some of the stuff he's been hearing about Ruby. And he's right. Yes, Ted ... Ruby's a great candidate for building DSLs.

I've been particularly interested in this, watching the Ruby community over the past two or three years learn to use the language in this way. I first encountered this style of Ruby programming almost four years ago, with Mathieu Bouchard's Ruby X11 library, which starts by defining a DSL for specifying X protocol packet formats. Since then, other Ruby developers have come to understand the power of this technique, and are learning how best to use it.

If you use Rails, for example, you see immediately how Ruby has been augmented from within to be a DSL for specifying relational mapping, web application component relationships, validation criteria, URL-to-page mapping, and several other things. I'm preparing a talk explaining how to do such things in Ruby. But one of the most important things to know is that it wasn't done in a vacuum ... it was done in the context of building a real application, Basecamp. That's the way frameworks, including DSL-based frameworks, should be built. In the the introduction to Paul Graham's other book, he writes:

You don't just write your program down toward the language, you also build the language up toward your program. Language and program evolve together. Like the border between two warring states, the boundary between language and program is drawn and redrawn, until eventually it comes to rest along the mountains and rivers, the natural frontiers of your problem. In the end your program will look as if the language had been designed for it. And when language and program fit one another well, you end up with code which is clear, small, and efficient.

That quote doesn't make much sense to Java or C# programmers, because in those languages the ability of libraries to extend the language itself is limited. But in Lisp, Smalltalk, or Ruby, library design really is language design.

As I prepare my talk, I'll try to blog more about using Ruby for DSLs -- how to do it, why Ruby is a good language for that style of programming, and what its limitations are.

(Oh, and Ted ... the night before you bought your book, I also bought a geeky book while on a date with my wife. You and I are scarily alike, my friend.)

The Ruby programming language is popping up everywhere this week. This is yet another in a series of indicators that something's brewing in the programming language space.

First, on Monday, Mike Loukides blogged about almost trying to learn Ruby. It's fun to see that he's at least planning to learn Ruby. At JavaOne a couple of years ago, Mike told me that O'Reilly really wasn't seeing much interest in Ruby. I replied that Ruby was still at the stage where the "thought leaders" were discovering it. By Tim O'Reilly's own heuristic, where the alpha geeks are going, others soon follow, and I predicted that Ruby would soon become more popular. I know that O'Reilly's seeing at least one indicator of increased Ruby interest, and maybe that's one reason Mike's planning to learn Ruby. This time, though, he decided he could get things done much faster using the tried-and-true Java way, and left his copy of PickAxe on the shelf.

Even though he decided not to actually try Ruby, he's questioning whether it's really useful. That's not an auspicious start for Ruby this week, I guess. But back to Mike later.

Today, there are a couple of other things. (And if you average Monday and Wednesday, you get Tuesday, see?) First, Howard Lewis Ship (author of the best Java web framework) showed up on ruby-talk and also posted a very favorable blog about his first Ruby program. I was elated to see this. Howard's expressed skepticism about dynamic languages to me at an NFJS conference, and was obliquely dismissive of Ruby in an earlier blog. But he's tried it, and was really impressed. I like the way he describes his first Ruby program: My trembling first journey into Ruby is [...] sloppy, doesn't report errors well, and took me too long to write (almost as long as it would have in Java!) His first program in a new language, and his criterion for "took too long to write" is that it took nearly as long as it would've taken in Java. Sounds like Howard caught a glimpse of how productive Ruby can be once you know it well.

And I have to say that Howard's first program is very nice! There are some things in it that an experienced Ruby developer would do differently, but it's definitely not "a Java program written in Ruby." Clearly Howard tried to learn not just the syntactic details of Ruby, but "the Ruby way." That's how we should all approach learning a new language.

So back to Mike Loukides. Maybe Ruby just isn't right for Mike. I'm on record saying that, in the debate between static and dynamic typing, perhaps there's not "one true way." But I'm convinced that for most tasks, dynamic languages are the way to go. (And I was a Java bigot for quite a while!) It's instructive to draw some lessons from the contrast between Mike's and Howard's experiences (and I'll throw in a few general thoughts, too):

• Anytime you have learned one programming language really well, you've reached a kind of "local maximum." To learn something different, even if it's ultimately more powerful, means stepping down from your current peak of familiarity and expertise and flailing around like a newbie on ice skates for a while. You won't see the benefits instantly. Howard describes his "trembling first journey," and that's how we can expect to feel the first time we try to write in a new programming language.
• Until your project is big enough that the gains start to outweigh the cost of the learning curve, the new language is bound to seem like a net loss. Howard's 292-line Ruby program is about the smallest project where you could expect the effort to pay off. (After all, it took almost as long as writing it in Java! :-) Mike's 25-line Java program is definitely too small.
• There are tradeoffs in languages, and Mike's right: not declaring your variables means that you don't have quite as much help debugging misspelled variable names. But the payoff comes in other ways, and not all of them have to do with writing the production code. Ruby does make writing the code easier, I think -- but it also makes it easier to write tests, and the code is easier to change.
• Not all "scripting languages" are alike. Mike implicitly criticizes the terseness of Perl (and also the "cryptic esthetic" of Perl culture, I suspect) when he lauds Java's readability. But Perl is different from Java in many ways, and Ruby only shares some of those characteristics with Perl. The Ruby language and the Ruby community place a big emphasis on readable code.

My intent isn't to bash Mike Loukides; he's a great guy, and he definitely has a point: the overriding criterion is getting the job done, and for his recent purposes learning a whole new language was probably overkill. (And besides, it would be the height of foolishness to bite one of the hands that invited me to Foo Camp.) But I do hope he'll make time to give Ruby a try, and give it a chance to prove itself on something reasonably sizable.

(Oh, and the other thing about Ruby that happened today? I noticed that, on the very cool website 43 Things, "Learn Ruby" is number four on the list of most popular things people would like to do. I wouldn't read too much into that; I learned about 43 Things through the Ruby community, and I suspect that high placement is an artifact of the way word of the site has spread. But it was still a pleasure to see.)

Via Tom Pierce I found Bill Clementson's list of Lisp quotations. (If you're reading my website, you're probably aware that I'm fond of collecting quotations myself.)

I particularly enjoyed this one:

Will write code that writes code that writes code that writes code for money.

That's as good an answer as any to the classic Lisp troll question: "What's with all the parentheses?"

If you’re interested in software development—even if you’re a non-programmer who wonders if you might ever be able to learn this stuff, or if you’re interested in effective ways of teaching programming—you should watch this video of the Self system in action. (I recommend watching one of the big ones, even though they’re very large files, so you can see what’s going on on the screen.)

This video was made in 1995. It’s a video produced by a software research lab, and that shows in the production values. But you can see in the video the genesis of a lot of today’s software technology. The Squeak user interface system is borrowed from Self. (But we all work in web applications, you say? Avi Bryant is trying out the same ideas in that context.) Self is the original Naked Objects system. The prototype-based OO system that’s at the root of JavaScript (and was central to NewtonScript) originated in Self. Ruby singleton classes were influenced by prototypes. And the implementation technology is equally impressive. Remember that the demo you see is written entirely in Self, and is running on Sun computers from 1995. The techniques pioneered in Self became the basis for Sun’s HotSpot Java VM—one of the names in the credits is Lars Bak, who went on to become HotSpot’s architect.

The Self project at Sun is, unfortunately, long dormant. The web page is still there, and if you’ve got a Mac and are still running Jaguar you can run it. There are still a few problems on Panther, unfortunately. (For that matter, if you have a Sparc machine running Solaris you can also try it out.)

But whether it’s directly useful today or not, it’s still fascinating history, and it’s sobering that although Self has influenced other technologies, those more successful systems are in many ways pale shadows of the original. It’s yet another vivid demonstration that much of the future of computing can be found in the past.