Re: Thoughts on Ruby

----- Original Message ----- 
From: "Enric Lafont" <[e-mail]>
To: "ruby-talk ML" <[e-mail]>
Sent: Saturday, November 02, 2002 7:57 PM
Subject: Thoughts on Ruby

> Hi all,

Hi Enric...

The list is quiet since many of the main posters 
are at the Ruby Conference in Seattle. :) I'll try
to answer what I can here.

I also suggest that you read the Ruby FAQ (which is
on rubycentral.com I think).

> I'm a Ruby newbie, and I'm reading now "the ruby way" and reading this 
> book some comments make me think.
> I've a strong  Smalltalk heritage,  so I'm somewhat biassed.

Thank you for reading it. I hope still more people will.

I don't know Smalltalk, though I've heard great things about it,
so I can't comment on that specifically.
 
> I would like to know...
> 
> Why does common operators like "=" , "and", " .." , "or"  etc ... can 
> not be overloaded or redefined ?, maybe the complexity of the Ruby 
> parser comes from the fact that everything is ALMOST an object or a 
> method. Why is not "=" a method ?

Here is one way to look at it. A variable is essentially a reference
to an object. A method is invoked on an object. An object never 
changes class (perhaps it can in Smalltalk?).

If I say:  x = "hello"
then what is the receiver for the method call "="? You can't say it's
x, because x is not an object.

On the other hand, the number 5 is an object. If I say:  5 = "hello"
does that mean that every reference to the number 4 is now a reference
to the string "hello"?

>  Same question for "and" and the rest 
> of operators that can not be redefined, Does the actual implementation 
> make life easier for the designer ? I say so because for me is more 
> natural when everything is an object (without exceptions, here Ruby 
> follows the rule pretty well) and a method is a method ever, not 
> sometimes. Some methods are keywords, and some other are not v.g. loop 
> vs. while. The every call is a method could simplify greatly the sintax 
> parser (look at the Smalltalk parser).

I can't speak for Matz, but I have NEVER seen him make a design decision
because it made life easier for the designer rather than the programmer.

I have seen him make compromises for clarity or efficiency, however. I
suspect that these fall into these categories somewhere.

As for simplifying the parser: I think you will agree it is better to 
have a readable, usable language than a simple parser.

Sometimes languages that are very powerful have difficult syntax (LISP,
Smalltalk, etc.). LISP is arguably the most powerful language in the
world, but people find it difficult to learn and use. Ruby is full of
compromises in its design.

> Why  primitives are hidden ? In smalltalk you can call a primitive every 
> time you want with a  <primitive: aNumber> , this way the implementation 
> of native methods, and in some way native Classes like String are not 
> hidden from the programmer, freeing the programmer to change the 
> behaviour if needed. Yes you can have the "required" clause and use 
> binary libraries, but would not be much more "natural" to have a 
> "require string" when you want to invoque string libraries instead of 
> having them loaded all the time ?. I want to say here that the 
> "primitive" keyword frees the language from it's implementation. This 
> favours the everything is a module aproach.

I'm not sure about everything you're asking here. But you can in fact
change the behavior of the standard classes, since the classes are "open."
There are many examples of this in TRW.

> Sintax Sugar (SS), other thing difficult to understand for me, the 
> question here is why ? Everything has exceptions very few things are 
> orthogonal with the principe that must drive it, you can wite a.+(3) or 
> a + 3 or a.+ 3 or a hundred other ways to write the same thing, yes, 
> this gives you freedom, but a bad deserved (not needed) one. I use one 
> form, but when I read programs from other persons the code seems strange 
> and somewhat dificult to read. Sometimes SS is right, v.g. x +=1, but 
> the every call is a method aproach could give you the same results 
> without trouble, in this case += could  be a method. As could be "++" or 
> others.

In Ruby, a += b means a = a + b ALWAYS, without fail. This means that you
get += "for free" when you define +, and you are spared having to write
both. If you want += to have some other meaning, I would have to ask "Why?"
It seems logical to me to tie the meaning of += to + (unlike C++).

As for ++ and --, these are impossible in Ruby for much the same reason
I mentioned before. They are operations on variables, whereas Ruby methods
and operators work on objects. If I say:  x++  I am trying to increment
the OBJECT that x refers to. Does this mean that every variable with the
same value should be changed also? For that matter, what should 5++ mean?

> Undeclared variables, I don't know other people but I do fast typing and 
> writing  "aVariable" and "aVariabel" is a mistake that I can do very 
> easily. Yes you can say, type more slowly, but this is not a solution, I 
> would like to have a way to force the compiler to generate a warning 
> when I use a non pre-declared (or pre asigned) variable.

If you use it on the right hand side, it will be an error.

It was difficult for me to get used to a language without variable 
declarations. But it seems to be a thing which Matz always insists on.
And I got used to it, and now I like it.

> Why are Strings arrays of integers ? aString[0] is an integer, yes, it's 
> the way it is, but I would like to have String as an array of chars, and 
> char if you want as a descendant of Integer (nice election because a 
> Unicode String is and array of double chars i.e. integer), I don't know 
> you, but for me aString[i].chr =='x' is somewhat unnatural, because it 
> breaks the semantic of a String, so it's not intuitive for me.

This was never intuitive for me either.

> Why is Ruby an interpreter ? Yes the less traditional bytecode aproach, 
> can be harder (or not), but enables external optimizations more easily 
> (JIT and similars) because the language are separated from the 
> implementation, enables reduced footprint and gives faster execution 
> times, yes, look at how Self executes programs, it's amazingly fast (and 
> incredibly complex also), but a separated implementation could help 
> develop better Ruby-engines.

This is planned. Matz wants to add bytecodes to 2.0 I think (which is 
still vaporware). In addition, Parrot is being designed not just with 
Perl in mind but Python and Ruby as well. So it should be possible to 
write a Parrotized version as well (though it has not been done yet).

There is also JRuby, which strives for interoperation with Java. I have
not played with it yet.

> Don't get me wrong, I understand that Ruby is a young language that 
> needs some maturing, and I love how easy is to learn, it's dinamicity 
> and the fact that is a kind of mix between my loved Smalltalk, Self and 
> other languages. In fact I'm writing this because I want to understand 
> Ruby better and becasue I want to make some suggestions for future 
> releases, maybe Mr. Matsumoto would like to consider some of them

My advice is to wait 90 days before suggesting language changes. :)
Every newbie makes these suggestions (as I guess I did too). But most
of them have been thought of before (as a search of the list archives
will show). Some are under consideration, some are planned for the
future, and some have been rejected by Matz.

> There are more things that I see as strange in Ruby, but this is enought 
> for now .....
> 
> Please if I've make any inaccuracy , don't be too rude with me, I'm 
> still learning, and I've a loooong way before understand everyting. I'm 
> just looking for answers.

I hope no one here is rude to you. If someone is, we will
come to your defense... :)


Hal Fulton