From: Brian Candler <b.candler@...>
Date: 2010-02-07T05:44:28+09:00
Subject: Re: Why Ruby?

Ruby is my language of choice for many applications because of the 
following:

(1) the lack of boilerplate. It encourages you to partition your problem 
into small digestible bits because you only need to type

  class Foo
    ...
  end

to get a class - virtually zero effort. Compare the line noise required 
in Perl to do the same thing.

(2) the supremely sane data model - *all* values are references to 
objects. (In Perl you have Scalars, Arrays, and References to Arrays, 
the latter being held in a scalar variable, and a load of special case 
nonsense like filehandles and typeglobs. C++ is worse; you have 
integers, pointers to integers and references to integers).

(3) pure personal preference, e.g. I don't like python's run-off-a-cliff 
indentation syntax. I had to use it in Occam years ago, and I didn't 
like it then either.

(4) the ruby 1.8 C intepreter ("MRI") is portable and runs on lots of 
things, even tiny embedded systems with 4MB of flash (e.g. OpenWrt)

(5) it's easy to work in different programming styles. Functional 
languages made a lot more sense once I was familiar with things like 
blocks and enumerables in ruby.

(6) it's not Java.

The downsides for me are a lot of accumulated warts and special cases in 
the language, generally aimed at "doing the right thing" but sometimes 
catching you out. Examples: auto-splat, lambda-vs-proc-vs-block, 
different behaviour of ^ and $ in regular expressions. I also detest 
ruby 1.9's String handling which means I'm staying on 1.8; I know I'll 
ultimately have to move to a different language entirely.

The documentation is variable from poor to bad. The language is not 
formally defined, neither its syntax nor semantics, and sometimes you 
just have to treat it like a black box and experiment to find out how 
things actually behave.

Sometimes it can be hard to find your way around other people's code, 
because ruby doesn't enforce that class Foo::Bar is defined in file 
foo/bar.rb (or that it's even defined in source code at all; it might be 
defined dynamically at run time). You're reliant on the good sense of 
the person who wrote the code to organise it sensibly, and you can write 
bad code in Ruby just as in any other language.

Finally, in some spheres there are simply better tools for the job. If 
you want to handle ten thousand concurrent client connections then 
erlang is probably a better fit (yeah, there are event-driven libraries 
in Ruby which with effort can achieve the same, but this is an area 
where erlang excels). Ditto if you want to build systems with huge 
uptime and zero-downtime live code upgrades. But try deciphering an 
erlang backtrace and you'll wish you were back with ruby.

HTH,

Brian.
-- 
Posted via http://www.ruby-forum.com/.