What I don’t like in Ruby

by Giacomo Graziosi     ruby  

Posted on Apr 7, 2008

I’m beginning to learn the well hyped Ruby language, in many ways it looks useful, elegant and pleasant, still it has something that, at least at a first glance, looks odd to me. I will use this post to take track of those odd things that I will meet when studying the language.

So, here we go:

1) Ends, take a look on this snippet:

if !r.nil? then
  rr = r.right
  if !rr.nil? then
    if ((r.color == RedBlackTree::RED)and(rr.color == RedBlackTree::RED)) then
      x = rot_left()
      copy(x) unless x.nil?
      @color = RedBlackTree::BLACK
      l = @left
      l.color = RedBlackTree::RED unless l.nil?

and here comes the Python equivalent:

]if (right != None):
    rr = right.__right
    if (rr != None):
        if ((right.__color == RedBlackTree.red)and(rr.__color == RedBlackTree.red)):
            x = self.__rotLeft()
            if (x != None):
            self.__color = RedBlackTree.black
            left = self.__left
            if (left != None):
                left.__color = RedBlackTree.red

The Python way looks just the best way in my opinion. What’s the reason for the ends when you’ll indent the code anyway (and if you don’t then you deserve nothing else than suffering and pain)? Even the { C/C++/Java approach } appears way better or at least less intrusive.

2) “Fuzzy” expressions terminators. Try to compile and execute the following C++ code:

#include <iostream>
using namespace std;

class Foo {
    void bar() {
        int x = 3;
        int y = 2;
        cout << x
        cout << endl;

int main() {
    Foo *f = new Foo;
    return 0;

What do you expect it to print? Right, it will correctly print 5. Now Ruby’s turn:

class Foo
  def bar
    x,y = 3,2
    puts x

f = Foo.new()

Now what output do you expect? The answer is 3. This is because Ruby doesn’t use semicolons as C, C++, Java, PHP and many other languages do to terminate statements. It is still the better way to go, semicolons are redundants useless things almost everytime, still you have to pay attention: note that the above Ruby code isn’t wrong so the interpreter will not warn you, it will just print 3 instead of 5 and the method bar will return the value2 (remember that in Ruby the last expression in a method or function is the actual return value of it so if you replace f.bar with puts f.bar it will print the “missing” 2).

3) No method overloading. The following code is self-explanatory:

class Foo
    def bar(a, b)
        puts b

    def bar(a)
        puts a

gh = Foo.new()
gh.bar("hello", "world")

if you try to execute it then you will get something like this:

asd.rb:12:in `bar’: wrong number of arguments (2 for 1) (ArgumentError) from asd.rb:12

4) GIL (global interpreter lock). To me it’s nothing else than an alternative reading for “fake threading”. If you are on a multicore/multicpu system try to execute this snippet while monitoring the cpu activity, it will start 8 threads and compute fibonacci(40) on each thread:

class Fibonacci
    def fib(i)
        if (i <= 2)
            return 1
            return fib(i - 1) + fib(i - 2)

threads = []
8.times { |i| threads[i] = Thread.new {Fibonacci.new().fib(30) } }
threads.each {|t| t.join}

If you come from C/C++ or Java you may expect this code to use up to 8 cores/cpus on your system at the same time… wrong! It will execute the code using only one core/cpu at once because the GIL prevents the threads from taking control of the interpreter at the same time. Cool, isn’t it?

5) Method invocation hooking. The following is the best way I found to intercept whenever a method is called:

class Foo
  def bar1(gh1)
    puts "bar1 #{gh1}"

class Foo
  def bar1_hook(*args)
    puts "bar1 hooked!"

  alias_method(:bar1_asd, :bar1)
  alias_method(:bar1, :bar1_hook)

a = Foo.new
So bar1 is the method to be hooked: you have to monkey patch the Foo class defining the hooking method and hack it all together with alias_method. Doing this you are ripping the original class apart: if someone will edit thebar1 method after your hook he/she will actually be editing the bar1_hook method without even noticing it (well, he will notice the unexpected behaviour and maybe try to debug his/her own code… have fun :- ), I really hope to be wrong about this point…

comments powered by Disqus

Search this site