in which the events of and surrounding cabooseconf are recapitulated

Over the weekend I spent some time with thousands of geeks in Portland as RailsConf was held at the Oregon Convention Center. While I always enjoy these kinds of events immensely, I usually have just as much fun with the socializing aspect as I do with the actual conference material. So this year I decided just to head over to CabooseConf and only attend the "hallway track" at the main event.

As usual, Portland was the ideal host city for the conference. It's beautifully green in a way that makes it simply refreshing to walk through. The convenience of getting around would have been better for me personally if I had thought to book a hotel closer to the Max line, but no US city that I've been to does visitor-friendly better than Portland. It came as a major disappointment to hear that it might head to the wastelands of Nevada next year—yuck.

CabooseConf was a really low-key string of hackfests put on by the folks at ENTP. Even if it didn't seem too lively at first glance, the room kept humming with a quiet energy of hackers working on big ideas. Getting that many bright people together is bound to spark all the right kinds of conversations.

I greatly enjoyed finally getting to meet JD, the other main Bus Scheme contributor and welcoming the enthusiastic Jack Danger Canty to the team. I had hoped to start adding support for macros to Bus Scheme, but the work I started in that direction revealed some weaknesses deep in the implementation. The code has much more internal consistency now (we changed a huge amount of code over from using Arrays to internally represent code to using Lists) and is pretty solid. Jack has actually deployed the first Bus Scheme web app in the wild as his home page, which is a noteworthy milestone. I've begun support for macros but am still a ways away from getting that totally ready. Scheme macros are fairly different from Common Lisp or Elisp's version, so it's taken some learning.

If you've read anything about RailsConf this year, you've doubtless heard a lot of people excited about MagLev, a new upcoming Ruby implementation. Since I didn't go to any of the talks I didn't see the demo, but I've read enough to be skeptical. I know for a fact that the world of Smalltalk has a lot of amazing technology around it that would really benefit Rubyists. But the way people go on about MagLev like it's going to solve everyone's problems with its 60x performance boost is really short-sighted. The obvious bit is that they haven't given anyone any reason to think they've got a system that supports Ruby's object model and execution semantics on anything other than a very superficial level. It's easy to optimize microbenchmarks to get 60x speed boosts like MagLev claims if you don't allow for the dynamicity of Ruby, and MagLev has so far made no claims towards being able to run (let alone pass) any of the Ruby specs.

But this is really just a side-effect of the real problem: There is absolutely no transparency into the development cycle of MagLev. We're seeing a group of engineers who are grounded in a 1980's mindset of "let's demo this technology we're working on to a bunch of potential customers" rather than entering into the Ruby community and approaching us as a group of hackers. We don't value slick demos and impressive statistics; we value code and code alone. We have learned the mistakes of single-vendor reliance, some of us by observation and some of us by painful experience. Even Sun learned that people won't put up with it. No—even Microsoft isn't daring to suggest that you use a Ruby implementation that ties you into their proprietary software stack.

The really crazy thing about the whole issue is that it reveals an idea that somehow it's difficult to make money with a really excellent piece of free software. It blows my mind that people still think this in AD 2008. People will trip over themselves to get a good place in line to throw buckets of cash at you if you can provide them with an open-source software stack that comes anywhere near the 8x-60x speedup that MagLev has implied is possible. It grows even more obvious when you think about the fact that the other big win with MagLev is the OODB, something that very few Rubyists have any idea how to deal with. And Gemstone has the expertise needed to port our Rails applications from this hacky object-relational mapping model to their vastly more elegant and scalable paradigm. It would be hard for them not to make money in a situation where MagLev came under a reasonable Free license.

« older | 2008-06-04T09:32:42Z | newer »