Why Ruby is so great and why I'll pass and wait for the next big thing..

[mouser]

Scott Hanselman writes good stuff on programming but his article today on what's so great about Ruby is good reading for people like me looking for an excuse to give Ruby a pass.  I consider these examples to be shiboleths and i find myself squarly in the camp of those who find the "Ruby Way" to be the wrong way.

A user named yesthatmcgurk left a comment on DotNetKicks where he/she said:

I must be a complete loser, because I can't see where Ruby is such hot shit. I'd love to read a story, "What you're not getting about Ruby and why its the tits."

Such a great comment that I had to get involved. One of the other commenters pointed to a post over on "Softies on Rails" that's really worth reading.

Note: Forgive the use of "the tits" in this context. "Slang Definition: A description of something you show great liking to, or greatly appreciate..." Usually not a work-friendly phrase, but perhaps pub-appropriate.

There's a simple snippet of Ruby code:

Code: Ruby [Select]

1. def shutter_clicked
2. if @camera.off? || @camera.memory_card_full?
3.   return
4. end
5.   capture_image
6. end

Ruby folks have their own aesthetic and sense of beauty. They would say that the Programmer's Intent is better expressed like this:

Code: Ruby [Select]

1. def shutter_clicked
2.   capture_image if @camera.on? && @camera.memory_available?
3. end

These two functions identically express the Programmer's Intent and the second one expresses it better, many believe.

Guess what, i don't think the second one is better, to me it's just one more example of the perl approach that the shorter the code the better the code.  I don't believe that.  I believe clarity is often best served by writing longer blocks (and good comments).  Whenever someone shows me these kinds of statements i always show them how easy it is to properly comment/debug the longer example and not the short one.
e.g.

Code: Ruby [Select]

1. def shutter_clicked
2. if @camera.off? || @camera.memory_card_full?
3.   // the camera either got turned off by mistake or is full
4.   // TODO: write error handling and detect which problem
5.   // for now let's just return without an error.
6.  return
7. end
8.  // ok, camera is ready so let's capture the image
9.   // TODO: make sure to reset camera state later
10.   capture_image
11. end

Here's another:

There are some fun one-liner comparisons though and some folks think that paying a:
Java: 

Code: Java [Select]

1. new Date(new Date().getTime() - 20 * 60 * 1000)

Ruby:

Code: Ruby [Select]

1. 20.minutes.ago

In this example, the elegance is a combination of how Ruby works, and a Rails library called ActiveSupport that is a Domain Specific Language that extends Ruby. There's a special satisfaction when you read a well-written novel and you go over a turn of phrase and think, "wow, what a great way to express that. That was a perfect way to describe ____," and there's no ambiguity.

This reminds me of everything that's wrong with (the often exceptional) boost libraries for C++, a love of abusing syntax and using "domain-specific" additions to the language.  Again the attraction seems to be to poetic tiny little segments of code.  If you are trying to write a 5-line haiku in code, fine.  But my experience is that when you start working on larger projects, you're better of knowing when you are calling a function or accessing a variable, and not introducing operator overloading and other fancy domain language extensions, etc.

Now of course this is just a minor part of Ruby, there are other things I don't like, and other things I do like, but Ruby, like most languages, seems to have developed a strong culture of style behind it that i don't fit into, so i'll keep looking.. Just my 2 cents.

[Gothi[c]]

Great post!

I'm afriad I'm in the same camp, and I agree 100%,...
I actually bit through the apple and spent a week exploring ruby and rails, by the end of it, the syntax was driving me crazy. I think they want code to look like plain English, but code doesn't look like plain English for a reason. Eventually, I told myself 'never again. Ruby isn't for me'.

[app103]

Great post!

I'm afriad I'm in the same camp, and I agree 100%,...
I actually bit through the apple and spent a week exploring ruby and rails, by the end of it, the syntax was driving me crazy. I think they want code to look like plain English, but code doesn't look like plain English for a reason. Eventually, I told myself 'never again. Ruby isn't for me'.

-Gothi[c] (May 24, 2007, 03:16 AM)

If that's what they want, why aren't they programming in Plain English?

[Eóin]

Hey mouser, I'm not too sure I'd agree with you on the first point. Given the two bits of quoted code I would say the second one is indeed better. That's not to suggest I disagree with you regarding code comments, but I believe that's a separate issue and an improvement which could be applied to either quoted bits of code.

Although I also think the first example is purposely contrived to be bad code i.e. the multiple exit points in this case are not at all necessary.

On the topic of domain-specific additions, well I can definitely agree that in many cases people can go overboard here. But I think the Boost libraries rarely if ever do so. In example code where 'using namepsace' directives are used too liberally it can be confusing, but in larger projects those directive are usually frowned upon anyway.

I'm eager to be shown otherwise though, would you have a sample or two?

[app103]

Coming from Delphi where I see things like this all the time:

Code: Delphi [Select]

1. begin
2.   Form1.Label1.Caption := 'Hello';
3.   Form1.Label1.Font.Color := clBlue;
4. end;

looking at something like this brings out an instinctive 'WTF?' followed by a near meltdown of my brain:

Code: Ruby [Select]

1. 20.minutes.ago

 

[Eóin]

Well I have to agree also that 20.minutes.ago is utterly ridiculous

[mwb1100]

This snippet

Code: Ruby [Select]

1. def shutter_clicked
2.   capture_image if @camera.on? && @camera.memory_available?
3. end

reminds me of the "COME FROM" construct that was proposed to replace the 'evil' GOTO statement many years ago (from http://www.fortran.com/come_from.html):

Example:

[Select]

        10 J=1
        11 COME FROM 20
        12 WRITE (6,40) J STOP
        13 COME FROM 10         
        20 J=J+2
        40 FORMAT (14)

Explanation:

In this example, J is set to 1 by statement 10. Statement 13 then causes control to be passed to statement 20, which sets J to 3. Statement 11 then causes control to be passed to statement 12, which writes the current value of J. The STOP statement then terminates the program.

The problem with using

Code: Ruby [Select]

1. 20.minutes.ago

is that even though it's obvious what the intent is, it's not obvious at all exactly what's going on so that I can be sure the contructs are being used correctly.

I would argue that the equivalent in .NET:
   

Code: C [Select]

1. DateTime.Now.AddMinutes( -20);

I nearly as readable as far as determining intent, but it has the huge advantage that in the same instant that you determine the intent of the statement you also know exactly what's going on so you also understand the operations producing the intended result.

[fro]

I would have written

Code: Ruby [Select]

1. Time.now - 20*60

even though

Code: Ruby [Select]

1. 20.minutes.ago

is available through some librabry.

[svv1999]

Code: Ruby [Select]

1. def shutter_clicked
2. if @camera.off? || @camera.memory_card_full?
3.   // the camera either got turned off by mistake or is full
4.   // TODO: write error handling and detect which problem
5.   // for now let's just return without an error.
6.  return
7. end
8.  // ok, camera is ready so let's capture the image
9.   // TODO: make sure to reset camera state later
10.   capture_image
11. end

-mouser (May 23, 2007, 07:53 PM)

From this code fragment I conclude:

• The coder created his code on the fly
• The coder created his code from some sample, therefore the intents he expresses in comments might be wrong
• The coder might not know the generic prereqisites of "problem"
• The coder might not know the difference between detecting a problem and exploring its causes
• The choosen language has no constructs to signal incompleteness of the code
• The coder is a friend of trivial redundant comments
• The choosen language has no constructs for ad hoc protocols
• The choosen language might not have constructs for protocols at all

If there is some interest to discuss these points I will give further reasoning.

[mitzevo]

I thought about giving RoR a go.. I don't really like the look of it.. And I don't want to learn another language..

Actually I'm quite happy with PHP and a framework or two.. There are a few RoR based frameworks for PHP, Akelos for example:

The Akelos Framework is a PHP4 and PHP5 port of Ruby on Rails Web Development Framework