In the Spotlight - Glenn Vanderburg

Like Chad, I think MagLev’s initial performance numbers will hold up. It’s possible that as it matures it will get slower, but it could get a lot slower than it is now and still easily be the fastest Ruby VM around.

And I agree with Chad that it might even get faster. I’ve also spent some time investigating how to make Ruby run on a Smalltalk VM, and it’s a really close fit. During the presentation at RailsConf, either Avi or the Gemstone guys revealed that they had modified their Smalltalk VM by adding two new bytecodes aimed at Ruby. I’ll go so far as to speculate: it’s likely that those two bytecodes deal with variadic methods and creation/lookup of dynamic instance variables. It sounds as though the core Ruby language is nearly complete on top of that base, so it’s easy to imagine that the early, hurried implementation of those two new bytecodes could be optimized further. And some of the Ruby features that have hurt JRuby’s performance will be no problem on a Smalltalk VM—ObjectSpace, for example, can work using the same facilities that Smalltalk’s development tools use today.

The persistence story is amazing. Avi and the team at Gemstone plan to implement an interface that is similar to ActiveRecord, but cleaner, since the object/relational impedance mismatch no longer applies.

Finally, there’s the question of licensing. I’ll be shocked if MagLev is open-source, but I think there’s room for a proprietary Ruby implementation. The team has committed to complying with RubySpec, which means I’m not very worried about compatibility. Most Ruby projects won’t need MagLev, but the ones that do will gladly pay for a top-notch, supercharged implementation with great scalability and persistence stories.

I’m definitely looking forward to hearing more about MagLev over the next few months.

The story so far (for the probably 99% of my readers who don’t read a lot of Smalltalk blogs): Avi and I had a discussion last year at OSCON about Ruby and Smalltalk, and Rails and Seaside. Avi was once a Ruby guy, but switched to Smalltalk (but he’s still friendly to the Ruby crowd). I’m currently a Ruby and Rails guy, but I’ve evangelized Seaside rather extensively.

During our discussion, we talked about the different tradeoffs that the two communities make.

I related that story to Neal Ford, which helped him to understand some things he’d been wondering about, which led to these blogs. In a vastly oversimplified nutshell: Ruby has some strengths that Smalltalk is missing, because it gives you a place to put all your stuff. (Please note that this does not imply that Smalltalk is fundamentally inferior to Ruby. I believe Smalltalk, in turn, has other strengths that Ruby is missing.)

James Robertson took issue with Neal’s blog, but gave no real evidence to back up his point. I was getting a bit frustrated with the "all heat and no light" nature of the discussion, until Avi saved the day by explaining the Smalltalk way of doing things.

I have to say that I think to some degree Avi confirms Neal’s and my point: Ruby provides a ready-made place for stuff like "has_many", whereas in Smalltalk, to provide similar functionality while preserving the "statement of intent" (as we’ve been calling it) the tool has to build a place for that statement. Which is fine, but it seems to me that "to make the generated code round-trippable," as Avi says, adds extra complexity to building such tools.

Again, this is not to say that the Ruby way is necessarily superior. These different approaches reflect different tradeoffs. That’s the conclusion Avi and I reached during our chat last year, and we were both happy to agree to disagree. Smalltalkers tend to prefer generating the methods directly, because that way they can get the most value out of their terrific toolset. And Alan Knight (in his comment on James’ blog) definitely prefers generating the methods in-place, so that the full API will be visible to developers. We Rubyists, on the other hand, having generally crappy tools, are free to do things in a way that even rdoc doesn’t understand, and I for one like the fact that all those boilerplate methods aren’t physically cluttering up my source code. You pays your money and you takes your choice.

My interest in discussions like this is not to have a language war, and especially not between Smalltalk and Ruby. (There’s brother against brother for you.) The point is to learn from each other and, through learning about the other, to understand more clearly the strengths of both approaches.

It’s absolutely certain that the biggest factor in their early maturity as programmers is that they’re just very smart guys. I’m also sure they started programming at a younger age than I did.

But Alan and I think there’s a third factor: Ruby itself. Ruby helps to teach those good programming skills, and makes them easier to learn. I got the chance later to talk to Koz about it, and he enthusiastically agreed.

The first thing I said in my talk on Saturday was that Rails is like an instructional laboratory for how to build good software. I think that’s the thing I like most about Rails. A big part of that is Ruby itself. Ruby, its libraries, and its documentation are filled with examples of clean, well designed code, and Ruby makes it easier than most other languages to create clean code yourself. The community values and encourages it. Ruby teaches good programming by setting the goal, lowering the barrier, and providing a lot of assistance and encouragement.

I was thrilled last year when Chris Pine’s Learn to Program was published, and now _why has taken up the flag with his brilliant Hackety Hack. We should support efforts that are focused on using Ruby to teach children to program. I think it’s the best way available right now to grow a generation of great programmers.

Hot on the heels of that, Chad strumming on his ukelele while Rich Kilmer gamely tried to deadpan through his introduction of David Heinemeier Hansson.

From David’s RailsConf keynote: "What we want to manipulate … is people." (With a little careful editing, you can turn a harmless quote into just about anything!)

Seeing Uncle Bob speak. He’s a master, and I haven’t seen him speak for about three years. The talk was about clean code, and I already understood about 48 out of the 50 minutes of material he presented—but as a speaker, watching the way he presents and works the audience is always fantastic and educational. (James' photo captures the magic perfectly.)

After being online friends since sometime in 1999 (when we met on Ward's wiki), Alan Francis and I finally got to meet in person.

Another quotable moment from David (this time with no editing required) during Alan’s talk: "People don’t stop doing stupid things because you make fun of them once."

Being blocked out of Adam Keys' standing-room-only talk. (Not a highlight for me, but I was thrilled for Adam, and it was great to see so many people interested in such an important but underemphasized topic.)

The accordion and ukelele duet.

Avi Bryant's wondefully articulated challenge for Ruby over the next few years to work toward turtles all the way down.

Ze Frank. ‘Nuff said.

My audience cheering wildly. I always thought you had to deserve something like that, but apparently you can just ask! I’ll try that again sometime. (But even though I got the cheers by cheating, it was nice to know everyone was on my side. :-)

James Adam is a great speaker, and his talk on "The Dark Art of Developing Plugins" was loads of fun.

Jeff Barczewski and Deb Lewis demonstrating MasterView at the lightning talks session. Deb told me about MasterView last year at OSCON when she and Jeff had just begun working on it. MasterView is an alternative templating system for Rails that’s HTML-centric, designed to allow page designers to use HTML editors like Dreamweaver within a Rails project. I was a bit skeptical of MasterView, because I’m most comfortable when the programmers are in control of HTML generation. But Deb and Jeff get it; MasterView works just like a Rails templating engine should. Reopen the page in Dreamweaver, edit things, save, and when you click refresh in the browser the changes are there. Great stuff.

The personal page editor demonstrated by the guys from Revolution Health. Impressive!

French programmer Fernand Galiana's "Pardon my French!" after he got a bit frustrated during his demo of the Mole plugin.

Rich and Marcel finally believing I wasn’t a werewolf.

Charles Nutter and Tom Enebo giving some really boring demos of JRuby. Boring is great for JRuby. It’s supposed to be just Ruby, on a different platform, and with Java integration that just seems natural. And it is! That was the challenge for them, to make JRuby boring, and they’ve done a great job.

Erik Hatcher’s fantastic talk about Solr on Rails, with demos of very cool things he’s doing with full-text search at the University of Virginia.

All of James' photos. He keeps getting better.

Beginning with many attendees at the Pragmatic Studio’s introductory Guidebook tutorial (but continuing throughout the week), the Ruby community raised (at last count) $26,000 for some excellent causes. (Update: over $33,000!)

Finally, Dave Thomas’ closing keynote was the perfect finish. Thanks so much, Dave.

But of course, at all of the really good conferences the best things happen in the halls and over lunch and dinner. I had the pleasant privilege of chatting with loads of great people—some old friends, and some new. I’m already looking forward to next year.

Tim Bray, as he so often does, nails it.