Ruby Impressions

[Quinn Dunkan]

On Mon, 14 Jan 2002 13:14:11 -0500, Michael Chermside <mcherm at destiny.com>
wrote:
>Here's what I have learned so far:
>
>   1. Ruby allows fairly easy modification of some basic language
>      features (like initialization).
>
>   2. Various tricks allow you to do pretty much the same thing in
>      Python.
>
>   3. Most Python programmers don't use such tricks (except for the
>      really simple/idiomatic ones like "__dict__.update(args)").
>
>   4. The Python folks defend this saying "it's easier to read" (because
>      you stick to standard idioms, even if they're a bit longer). The
>      folks on the other side say "but the idiom's verbosity may conceal
>      the fact that it's conceptually a single, simple operation".

I tried ruby a while back and really wanted to like it, but what turned me off
was the profusion of syntax.

{|x| ...} vs. do ... end vs. proc.new, all have various levels of preceedence
and it seemed subtle and arbitrary to me.  Then there are two seperate
exception mechanisms: throw/catch and raise/ensure.  They have some subtle
difference.  And there's various rules for what you can capitalize (if I
remember correctly, Constants) and various scope-signifying symbols (local,
@attribute, $global), and some return 'nil' on an uninitialized reference, and
some throw a NameError (no wait, sorry, they *raise* a NameError, *throwing*
it is a different operation).  Then you have about a jillion ways, all subtly
different, to include code from one place to another, from inheritance, to
'include' to 'require' to... umm... a whole wad of class methods, and then a
bunch more methods for including methods in modules, which are sort of, but
not really much like, classes.  I suppose it's all because methods are not
first-class objects, so you can't simply say 'foo.bar = baz.faz' to make an
alias for a method.  And little weirdities like 'nil != false'... I'm afraid I
never figured out why I needed both, and never really trusted predicates to
always return 'false' and not 'nil' (scheme's practice (which I also don't
quite understand) is not really a preceedent since '() is true and ruby's nil
doesn't have anything to do with lists).

Then there are relatively trivial things like '&&' vs. 'and' which have
different preceedence.  Oh yes, and the various bits of ambiguity introduced
by the fact that you can leave the ()s off when calling a method.  And the
fact that when I tried it, 'irb' was quite buggy and would randomly produce
strange results or completely self destruct, and the documentation was mostly
in Japanese (I'm sure both these are fixed by now).

Of course, ruby has some superficially really nice things, like no type/class
split, simple extending, real gc, etc.  Python is getting some of those too,
but later in life.

I guess I'm not what Wall calls "postmodern" enough, I still like design too
much.  Ruby didn't seem very designed, but more perlishly "let's throw in some
cool stuff".  So maybe that's why it appeals to all those postmodern perl
folks :)