Log in

No account? Create an account
latest entries related journals calendar about the author My life in pictures more recent entries more recent entries
If you knew Ruby... - My Thoughts Today
An ill-used association of words and pictures
If you knew Ruby...
Well it seems my job interview on Tuesday was yet another complete waste of my time. It should have been patently obvious to the company concerned that they weren't going to hire me during the course of the phone interview on the previous Friday. My CV clearly demonstrates that I'm neither a web developer nor a J2EE obsessive, and that I've spent a lot of time figuring out how all the server-side tasks that people are currently doing in Java could instead be done in Ruby. Their loss. Still, I guess I can't blame them for wanting to see what a full-time Ruby developer looks like in the wild - after all we're still a rare breed in this country.

It's just a pity that whilst everyone wants to meet us, no one knows what to do with us. Well that's not entirely true. If you've a passion for Rails you can currently make a killing in web development, and there are a number of firms now doing very nicely out of that kind of work. Very nicely indeed. It's also growing in popularity amongst system administrators and QA testers, areas that have always been open to light-weight languages with little learning-curve. But suggest that Ruby is a good fit for other problems and you run into this persistent brickwall of disbelief: it's too slow; it lacks major corporate backing; no one uses it for serious development; it's Rails isn't it?

  • Well firstly it's not particularly slow. Ruby running on my Core 2 Hackintosh is orders of magnitude faster and more responsive than VB on a 100MHz Pentium, and as I've mentioned before I've used the latter as a target for significant performance-critical applications. My confidence that Ruby could do the same tasks is very high and several of the projects I'm involved with have similar performance requirements. Sure it's slow at number crunching, but so are most languages compared to raw assembler.

  • The lack of corporate backing is common to most open-source languages, but in this case it's no longer true. JRuby puts a Ruby interpreter on the JVM and is backed by Sun Microsystems whilst Microsoft announced IronRuby this week as part of their Silverlight rich-media web client vision. The two heavyweights of Enterprise software are driving hard to include dynamic features in future versions of their respective platforms and Ruby has played an important part in inspiring this change in outlook.

  • I love the notion that just because no one else appears to be using a new tool, that's a good reason to ignore it. One of the defining differences between excellence and mediocrity is the willingness to use new tools and techniques before they enter the mainstream, so if your primary argument for not using Ruby is that it's not yet mainstream you've just defined your project as mediocre. By the time you're ready for it, your competitors will be onto even newer tools. Paul Graham has written some excellent essays on this subject, go read them and get an education.

  • Rails. It's all anyone ever wants to talk about. You'd think it was the key to world peace from some of the sycophantic outpourings you read on the blogosphere. It's good, but it's not that good! Of course a lot of this chatter is a recognition that the existing web development paradigms are borked and that Rails offers something fresh, but it also shows a more general truth: dynamic tools make for productive developers, productive developers generally produce more elegant and efficient applications, elegant and efficient applications make end-users happy. Ruby is a very dynamic tool and that means it's great for productivity and developer and end-user happiness - everyone wins! But this boost in productivity isn't limited to just web applications, you can use it anywhere.

So now we've dismissed the usual complaints, let's look at the core assumption that people are currently making:

Ruby = Rails = Web Development

If I have to do web development then Rails is definitely a step up from any of the non-Ruby frameworks I've used. However as I demonstrated at RailsConf Europe last year, rolling your own web framework in Ruby is a trivial task, and that's the point I'm trying to get across: a good dynamic language can make many tasks trivial that in static languages seem daunting.

Why does this matter? Because solving a problem well generally first requires solving the problem badly, and that means planning for multiple iterations if you want to hide the awful truth of how bad your first solution is from competitors and end-users alike. But multiple iterations with a static language are a huge risk thanks to their long development cycles and the substantially larger codebases they generate. Sure the corporate FUD-machine wants you to believe that static languages make for better products by identifying bugs earlier in the code design process, and they pump out all those lovely glossy brochures describing Enterprise debugging tools and benchmarks showing ten-fold performance on carefully chosen critical-path code, but FUD is all it is. With dynamic languages we're not in Kansas anymore, and the underlying assumptions of the static typing world no longer apply...

So next time someone tells you that they use Java or C++ for the heavy-lifting server-side ask yourself just what that heavy-lifting involves and whether the majority of it wouldn't be better handled with a dynamic language like Ruby. Even if there are numerically intensive sections that are best handled by some tightly-optimised code these can be implemented as low-level extension libraries, but for the rest you can bet that code-complexity and development time will be greatly reduced by making the switch and that no one will notice the performance difference.

Tags: , ,
the music in my head: Mrs. God - Helloween - Battle Metal 3

4 opinions or participate
headius From: headius Date: May 5th, 2007 06:52 pm (UTC) (permanent link)

Only days too early?

Too bad your interviews didn't come a week or two later...there's a number of very positive JRuby-related announcements coming out soon that you could have pointed to. Watch the headlines the next two weeks and you'll see what I mean.

FYI, if you're interested in playing with JRuby, feel free to join the mailing lists or stop by #jruby on FreeNode. We're a friendly lot and things are looking great for JRuby's future right now.

And if you're near SF, there's a free "CommunityOne" mini-conference before JavaOne on Monday, which features a few Ruby/JRuby and Rails-related talks.
feyeleanor From: feyeleanor Date: May 5th, 2007 11:18 pm (UTC) (permanent link)

Re: Only days too early?

I lurk on the JRuby mailing lists, just to keep an eye on what you guys are up to. Like a lot of people I'm really excited by the potential of Ruby on the JVM :)
nickmurdoch From: nickmurdoch Date: May 5th, 2007 11:08 pm (UTC) (permanent link)
Mmm, dynamic languages! I haven't tried writing Ruby myself, but from what I've seen of it, it looks just as joyous as using Python (with the exception of 'end' keywords). I'm lucky enough to have found a job where I can use it, too! Ruby-on-Rails is pretty buzzwordy at the moment; even our boss knows what it is, whereas Turbogears (and Django) don't seem to have found their way into exec's imaginations yet. I think that's why Ruby is being associated with Rails so much; it's a new language and the first most people hear of it is from the Rails project.

I much prefer the rapid development path, too. Write something, see what works, what doesn't, and you don't have the attachment to old code the way you would do if you'd spend days lovingly crafting it to fit into a static language. It doesn't matter if you have to rewrite something because doing so is comparatively very easy.

Anyway, I'm preaching to the converted, I know; I just thought I'd add some support :)
feyeleanor From: feyeleanor Date: May 6th, 2007 12:56 am (UTC) (permanent link)
Thanks. If we all shout loud enough then eventually the message will get through.

I think once a programmer's tasted rapid development with good tools they're spoilt for any other way of working, and for those of us who started coding in the 80s with home micros even bad tools feel better used that way ;p
4 opinions or participate