Day: March 19, 2007

6 reasons why you should try Ruby

March 2007    Easy reading

I love Ruby. I first learned about it on the Internet several months ago and decided I wanted to give it a try. I was intrigued by the kind of buzz around it. I felt that the Ruby crowd was smaller than the PHP, C# or even python crowd, but those who liked Ruby seemed to like it A LOT. I went to the ruby website and decided to try the online tutorial. At this moment, I just knew this thing was for me. I didn’t know exactly why at the time, but I knew that this language would become my language, my little favorite. Ruby would become the language I would defend proudly in a geek crowd wearing my transformers pajama.
So here we go with another “top ten” kind of post that is so popular on the blogosphere these days : 6 reasons why you should try ruby

1) Enjoy the power of code blocks!

Code blocks are chunks of code that can be passed to any ruby function. They take the form of anonymous functions and can be used to achieve a lot of useful things. One of the main use of ruby code blocks is to achieve what we could call “intelligent loops”. Instead of managing the internals of the loop yourself, you delegate the work to some object method, passing it a code block that will have to be executed at every passages in the loop. The method will have to make use of the yield keyword in order to call the block that has been passed to it. I wrote an article about code blocks in case you would like to know in more depth what I think of them.

2) Writing conditionals never been that exciting

What is more boring than writing a traditional if-then-else condition? Well, a lot of things in fact. But writing a “if” is still boring… a little… I think. In Ruby, you can decide to put the conditional keyword either before or AFTER the tested expression. It may seems like useless, but I personally think it helps to improve the code clarity in some situations.
For example, instead of writing a statement like this :

if(won_fight)
  puts "Yay!"
end

You could also write :

puts "Yay!" if(won_fight)

I love it. But wait there is more! Everyone knows about the if keyword, but not everyone knows about the unless keyword. It’s pretty straightforward so I’ll just write an example and you’ll understand.

dance_like_an_idiot unless struck_by_lightning

I personally like this last use of the unless keyword. In this particular case, I really wanted to put the emphasis on the idiotic dance while not bothering too much about the insignificant exception that follows. It all depends of the situation. Sometimes, the thing to do deserves more attention and some other times it’s the condition that matters the most. It’s only a question of personal taste, but it’s a nice touch nonetheless.
Note that there are other keywords you can place before and after the tested expression, like until and while.

3) You know you are addicted to OOP

With Ruby, everything is wrapped into objects, not only complex structures but native types as well. For example, String is not a keyword, it is the name of a ruby class. String contains methods that manipulates the internal string value. So instead of writing something like Uppercase(“blablabla”), you will write “blablabla”.capitalize. Instead of writing round(a_number) you will write a_number.round(). In short, there are less global keywords and more encapsulated methods. If you love OOP, I don’t have to convince you, I’m sure you’re already turned on.

4) Adopt a dynamic language today

Dynamic typing is wonderful and really should be taken seriously. You waste a lot of time declaring and giving a type to each of your variables in your statically typed language. Why not let an interpreter decides what kind of variable x really is only when you start putting some kind of value in it? It’s silly to say that dynamically typed languages are less serious than statically ones. When a programmer decides to create a variable in ruby, python or PHP, he will use it the proper way. He won’t put a number in variable x and later try to retrieves a date from it. Also, declaring variables takes more place in your code as well as more time in your life… and it’s just boring. Call me a hippie if you want, but I prefer a language that slacks off on types a little rather than one who points a gun at my head forcing me to code a certain way and trying to control everything.

5) Be part of a more underground community

Ruby isn’t the most popular language and shouldn’t be. Sure, It’s popularity is growing a lot recently and that is a great thing, i don’t say otherwise… but too much popularity and Ruby would lose some of it’s appeal. It’s just a special feeling to be part of a community that is a bit smaller and more underground. Small communities = more devoted people.

6) Rails

I just couldn’t pass aside Ruby’s best friend. When Rails arrived and revolutionized the web community, Ruby finally started to get some of it’s well deserved credit. Developing a web application with Rails is extremely fun and fast… and I’m not saying fast in the bad sense of the word. With Rails, you code less and you code better. Thanks in part to the MVC architecture but also to the greatness of the language hiding behind the powerful framework. Ruby and Rails forms a devastating combination. Ruby and rails convinced me that programming could be fun again… something I didn’t have anymore when I was developing in .NET (Yaaaaaaaaawn!).
There are tons of other reasons to try ruby. Could you give me a few?

What's the fuzz about ducktyping?

March 2007    In depth

Even if you’re not new to ruby, the concept of ducktyping might evokes something vague and unclear to you. I personally had to re-read the dedicated section of my ruby book a couple of times before I finally grasped the concept.

What is ducktyping?

Ducktyping is the art of judging an object on what it can do rather than on what it is believed to be. What it means is that an object doesn’t live and die with a label pinned on it’s forehead. In ruby, an object can do anything it is able to do, isn’t it great? Yeah, it is.

It makes a lot of sense when you think about it. Suppose you have a method called be_scary that accepts one parameter representing a lion that will roar at the call of the roar! method. 

def be_scary(the_lion)
  the_lion.roar!
end

Even if the creator of this method seemed to have forget it, there are a lot of other living creatures on the earth that can express their might like that. No need to remind the programmer about that however, because we can use ducktyping to pass any scary stuff to our method. The thing that I will pass to the be_scary method do not need to share anything in common with a lion excepts for the fact that it can roar. Imagine for a second that scientists just discovered that rabbits could roar in some very specific conditions. No worries! You don’t have to touch a single line of your ruby program structure. Just pass the rabbit instance to the be_scary method and the interpreter will try to find it’s roar! method. Ruby doesn’t play a bouncer role like in many other languages. It doesn’t stand at the method gates while refusing the entrance to objects who are not exactly what the method is expecting to see. Instead, the ruby interpreter slacks off and let everyone enters into the method so they can try their luck with the roar! method.

Isn’t it the same thing than dynamic typing?

No, dynamic typing just makes reference to the way the type(or class) of an object is determined, that is, when you’ll start putting stuff in it. Ducktyping picks up from there and extends the capabilities. Generally, when ducktyping occurs, the interpreter knows the type of an object but still won’t exert authority on it by prohibiting it to enter some methods. We could say that a ducktyped language is always a dynamically typed language but not the other way around. A dynamically typed but not ducktyped language could still refuse objects based on their type at the doors of a method.

If you really want to catch exceptions before the ruby interpreter…

If you don’t feel comfortable with the fact that there is no bouncer at the doors of your method, you’ll be happy to know the existence of the respond_to? method. It kinds of fill the role of the typeof keyword in some other languages. However, instead of verifying if the object is a specific thing, you verify that it can do a specific thing.
See how we could have implemented our be_scary method.

def be_scary(something)
  if(something.respond_to?(:roar!))
    something.roar!
  else
    raise "That thing cannot roar..."
  end
end

Great… but if the only thing you are going to do is raise an exception (something ruby would have done by itself), this kind of practice may be a little overkill. It’s up to you to decide if the extra effort is worth it or not.

Ducktyping is not polymorphism

The beauty of ducktyping is that it doesn’t rely on inheritance or polymorphism at all. Every single objects are accepted in every single methods, period. The only thing that matters is the capability of an object to do whatever the method is trying to do. If the object can’t, the interpreter will gladly raise an exception in time (unless you use some respond_to technique that is).

Give ducktyping a real chance

Ducktyping can shake the conceptions you have about types and classes in programming languages. At first, I was not sure if I liked the idea, but now I think that it is a very logical and clever way to manage types. I came to the realization that programming languages didn’t need that many boundaries after all. I even wonder why no one thought about ducktyping before. Where’s the catch?