Glenn Vanderburg

: Blog

infosyndicate
8 of 34 articles »
MagLev
Thu, 05 Jun 2008 (21:11) #
Chad Fowler nails it with his summary of MagLev.

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.

Code generation, synthesis, whatever
Fri, 07 Sep 2007 (03:23) #
I’m so glad Avi Bryant jumped into this discussion. (I was hoping he would.)

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.

Ajaxian on Tamarin
Thu, 08 Feb 2007 (16:53) #
My friends at Ajaxian invited me along as a podcast guest again, and I’m so pleased with the result. Audible Ajax, Episode 20 focuses on Project Tamarin, the high-performance JavaScript VM donated by Adobe to the Mozilla project.

This episode is a bit of a change for the Ajaxians; rather than being an interview with one person or team, it’s a more formally produced analysis piece, with comments from several JavaScript and Ajax experts, only some of whom are really associated with the project. I lead off with a discussion about why current implementations of JavaScript are rather slow, but then Brendan Eich and Kevin Lynch (from Mozilla.org and Adobe, respectively) talk about the project, along with Alex Russell and representatives from the IE team and Zimbra.

Ben and Dion are planning to use a similar format for upcoming episodes, and I’m thrilled—I think it works really well, providing a continuity and depth of analysis that you just don’t get from a single interview. Bravo, guys!

Ruby and Strongtalk (or, What He Said)
Wed, 13 Sep 2006 (13:39) #
Because I was pressed for time yesterday, I ended my blog on Ruby VMs with a little teaser about other possibilities: "And there is still room for serious creativity there. I’ll write more about that soon." About two hours later, Avi Bryant posted essentially the same thing I was going to say.

Avi has blogged before about the idea of implementing Ruby on an existing, fast Smalltalk VM (the object models of the two languages are very, very close; the biggest hurdle would be Ruby’s richer method argument handling).

But, as Avi points out, the open-source availability of Strongtalk, including the VM implementation, is a big development. Although it’s now ten-year-old technology, Strongtalk nevertheless represents the state of the art in dynamic language implementation. Strongtalks basic principles of operation have been widely known for years (although apparently not by Joel), but actual implementations of those ideas have all been in proprietary products. (The Hotspot source is available, but not as widely as a true open-source products.) For OSS developers who want to learn, the closest they could get to a cutting-edge dynamic language implementation has been Self. But although the techniques in Strongtalk originated in Self, the Strongtalk team took them a lot farther.

Sun’s HotSpot VM for Java already incorporates these techniques, so JRuby is already on track to take advantage of them. I don’t know that much about the CLR, but it wouldn’t surprise me to learn that it uses similar ideas, which bodes well for IronPython and an eventual Ruby implementation for the CLR. But there’s still a performance limitation imposed by the mismatch between object models, and the unavoidable mapping layer that implements one atop the other.

Mr. Malsky, I predict that in three years, Ruby will have performance rivaling Strongtalk’s — whether by someone adapting Strongtalk itself to run Ruby, or by mining it for techniques that can be rolled into YARV or some other VM project.

(Well, maybe three years is a bit optimistic. But I can hope.)

Ruby VMs
Tue, 12 Sep 2006 (17:16) #
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.)

Can't Wait!
Sun, 30 Apr 2006 (01:38) #
No Thanks, I'll Stick With Ruby
Sun, 02 Apr 2006 (04:27) #

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.
The Whole Equation
Thu, 05 Jan 2006 (16:23) #
Reginald Braithwaite-Lee really nailed it with a great post that ties together a bunch of my favorite topics into a nice, coherent bundle:
  • language power and expressiveness
  • why you sometimes don’t "get it" until you try something
  • the different strengths of Rails and Seaside
  • metaprogramming

I particularly like the way he debunks the "you can build new idioms in any language" argument: different languages have different idioms for building new idioms, and that makes a difference.

The first time I delivered my "Metaprogramming Ruby" talk at OSCON this year, I was privileged to have two of the masters of Ruby metaprogramming in the audience: Rich Kilmer and David Heinemeier Hansson. Rails is, of course, the poster child for the benefits of Ruby’s metaprogramming power at the moment. But Rich paved the way with several less well known projects that showed just how much metaprogramming power Ruby has.

Anyway, during the talk I presented two approaches to doing metaprogramming, and since Rich and David were there I put them on the spot and asked them to confirm my suspicions — and I was right. The two of them approach the task in different ways.

Rich typically starts with a domain he understands fairly well, and designs domain-specific constructs to support that domain. Then he implements those constructs using Ruby. That’s the approach he used during the week of OSCON to build the prototype of a Rails interface for his ActionStep framework.

I think that’s how most people think metaprogramming is done, and it sounds really intimidating and difficult — especially when you’re not used to thinking about domain-specific languages, or you don’t understand your domain very well yet, or if you’re not familiar with the techniques of metaprogramming.

But there’s another approach, and it may surprise people that DHH used this different approach to design and build Rails. He admitted that when he started building Rails he didn’t have a deep understanding of what a web framework should look like, and he wasn’t an experienced Ruby developer. But he started with a strong desire to build good, clean code, and a devotion to the DRY principle as one way of keeping his code and design clean. And then he "explored" his way toward Rails’ metaprogramming sweetness. During programming, when he found himself writing duplicate code, or code that felt ugly or unnecessarily complex, he would look for ways to eliminate the duplication or make the code simpler and more expressive. Sometimes that was possible in ways that would seem perfectly natural to a Java programmer. But in other cases he had to go farther, augmenting the Ruby language itself through metaprogramming. In less dynamic languages, some of that duplication or ugliness would’ve remained, simply because there would be no effective way to eliminate it. (Don’t believe me? Look at the source to java.util.Arrays.sort.) But in Ruby your refactoring toolkit is bigger, and most of Ruby’s metaprogramming idioms are quite easy to use once you learn them.

That’s how I like to explain metaprogramming: as an additional set of tools that dynamic languages provide to help you eliminate bad-smelling code. Those rich idioms give you a lot of power for keeping your systems clean and simple.