The curious case of beauty in Ruby (or Rails vs Merb part 2)

December 27th, 2008

I’m sure you’ve all heard the Rails 3 announcement. When I first found out my initial reaction was “fuck me“. But shortly after I was filled with a feeling of dread and general unease. And I didn’t know why ….

Firstly, a bit of history.

I first tried programming on a Commodore Vic 20, and then after that a C64. C64 BASIC was very simple – if you wanted to do anything beyond PRINT statements you needed to POKE values into registers and control the hardware directly. Great for learning how things actually worked. And, to be fair, I was shit at it.

But I do remember reading an article on a system called “Smalltalk” and its “Object Oriented Programming”. Suddenly, programming made sense. It read a bit like English. You sent messages to the thing that knows how to answer your question. It was like talking to people. You ask Dave a football question. You ask George a music question. Cos Dave knows crap all about music and George knows nothing about football.

But, in those days, Smalltalk cost a fortune; there was no way a child like me could get hold of a Smalltalk environment. So instead, I got hold of Turbo Pascal 6 With Objects (thanks Dad). It was not Smalltalk but it read a bit like English and it had objects. I played about with Turbo Pascal, went to university (where I didn’t do computing but did do some C++) and then got a job doing Delphi (Turbo Pascal for the 90s). This object-oriented stuff really worked for me; I put a lot of effort into writing classes that had really simple public interfaces and with code that read like English. And Pascal (the language underlying Delphi) was great for that. Then I discovered Java, which meant I could write Delphi-like code but with having to deal with memory management. I also discovered PHP, Python and Ruby. None of which clicked with me; dynamic typing made me nervous (and PHP and Ruby seemed a bit ugly).

However, I needed an ORM for a Delphi project and I thought I should try to copy an open source project. Whilst searching I discovered Rails and thought “this is the one to copy”. But a day into my “copy ActiveRecord into Delphi” plan I thought “this is just like Smalltalk”. Why make an inferior copy when I can use something that’s not far off the Holy Grail. Writing an application on Rails had the same effect on me as my original discovery of Smalltalk – it read like English, it felt fantastic. So I gave up on Delphi and became a Rails programmer.

What I liked about Rails was its emphasis on happiness. When I wrote Rails code I felt like I was writing beautiful prose. I would go back and refactor it until it read correctly. This was not like pure Ruby, which was often ugly. No; Rails had this idea about beauty in code that really got me excited. It made me happy. It also made decisions for me – put your code here, test it like this, set up your database this way. But Rails had performance problems – so Merb was born. A ground-up rewrite of many of Rails’ ideas but with an emphasis on configurability and performance.

Maybe it’s the Engine Yard connection (I turned Engine Yard down for a job because it didn’t “feel right”) – and now I work for Brightbox, one of their competitors – but for some reason, every time I tried Merb I just couldn’t get into it. It was weird. Structurally and functionally it was the same as Rails – but it was Rails plus performance plus options. And I didn’t like it. I never got past the tutorials. Merb emphasises clear and understandable code and was tested with RSpec (which I love). Rails is hard to understand and uses Test::Unit (which is ugly). But I love Rails and I can’t get into Merb. I just couldn’t figure out why.

Until today.

Mr Hanson did a blog post on his first piece of Rails-Merb integration. And something stood out at me. As he was describing Merb’s provides/display functionality I noticed that I didn’t really “get it”. provides made sense, but how does that relate to display. Mr H addresses that directly:

There were a couple of drawbacks with the provides/display duo, though, that we could deal with at the same time. The first was the lack of symmetry in the method names. The words “provides” and “display” doesn’t reflect their close relationship and if you throw in the fact that they’re actually both related to rendering, it’s gets even more muddy.

And then he describes the Rails 3 version of the same functionality. Instead of provides/display it becomes respond_to/respond_with. In particular display @users becomes respond_with @users.

It’s only a tiny thing. Logically and functionally, they are exactly the same. But DHH’s version has an emphasis on the words that are used. How they couple together (display/provide versus respond_to/respond_with).

And there is the reason that I was uneasy about Rails 3. What if Rails lost this emphasis on the human factors – how the words mesh together – in the search of performance. Merb is written functionally, Rails is written emotionally – Merb is about performance, Rails is about feelings.

But DHH has made me feel much better about Rails 3 – he has shown that he will take Merb constructs and Railsify them, humanise them. Because, although code is executed by computers, it is written, and more importantly, read by people like me.

If you find this useful then please take a look at some of my other writing – or recommend me on Working with Rails. Cheers.

8 Responses to “The curious case of beauty in Ruby (or Rails vs Merb part 2)”

  1. Matt Aimonetti Says:

    Great post, as a Merb core team member, I have always been interested in knowing how people react to the code we write.

    Being now part of the Rails team, I’m excited to see that thanks to the merger, users like you will get the best of two worlds and are excited about it :)

    Thanks

    - Matt

  2. hallucinations Says:

    Great post!!!

  3. Yehuda Katz Says:

    I’d hardly say that Merb doesn’t focus on the “human element”. Instead, I’d say that DHH is a better API designer than I am. In Merb, we never eschewed new powerful features because we couldn’t get the API exactly right. With Rails 3, we get the opportunity to revisit the API we used for the features we introduced and work together with the Rails team to improve it.

    I anticipate great success.

  4. ActsAsFlinn Says:

    Great post. I feel like the reason Rails people have a tough time with Merb is that they expect it to be Rails. Merb isn’t Rails (yet: http://ismerbrails.com/) and since many of the conventions are similar people have a tough time with the details that are different. I’m generally happy about this turn of events but you could kind of see it coming with the addition of Rack in Rails. It wasn’t just the addition but full integration with Rack and a full on replacement of the duplicate functionality. In essence Merb and Rails (2.3) now share a lot of the fundamentals. It’s good to be a Ruby developer :D

  5. Brock Says:

    very interesting post. however, I was was just thinking today about how nasty the respond_to block is. “he[DHH] has shown that he will take Merb constructs and Railsify them, humanise them”. this is exactly what Im worried about.

  6. Rahoul Baruah Says:

    In many ways respond_to as it currently stands in Rails is a really bad example – it’s something I think is really clumsy.

    But humanising is necessary as far as I’m concerned. Rails stands out as being like Smalltalk in emphasising the role that people play in development; lose that and it becomes just another framework and you may as well switch to PHP (yeuch).

  7. Rahoul Baruah Says:

    By the way I am looking forwards to Rails 3 – my fears have been allayed.

  8. ismael Says:

    Spot on! I always struggled trying to understand why I didn’t feel as confortable with Merb as with Rails (even though I rationally understood that Merb’s implementation was way cleaner).

    The merger is definitely something to be excited about!