Re: Thoughts on Ruby

On Mon, 4 Nov 2002 06:44:46 +0900, Enric Lafont wrote:
> Austin Ziegler wrote:
>> I don't actually see this (that everything is "almost" an
>> object). Personally, I think that matz has made the right choice
>> in making boolean operations (and, &&, or, ||) invariant in the
>> language. You can, by the way, redefine the bit operators (&and
>> |). There's nothing worse than a language which doesn't do what
>> you expect it to do with conditionals, and it does so on the whim
>> of another programmer.
> Ok, you are right, it's Mr. Matz decission, but, why then can I
> redefine the "and" method ? It must be a method in the very first
> time, not an exception.

  class Foo
      def and(o)
          "and"
      end
  end

  f = Foo.new
  p f
  p f and nil
  p (f and nil)
  p f.and("o")

If you run this, you'll see that Foo#and isn't related to the
boolean operation at all. Thus, while you can define an 'and'
method, you are not redefining the 'and' boolean operator.

You can redefine the '&' (bitwise-and) operator, because that's
actually a method '&'. So, I'm not sure what you're really asking
for, here.

>>> Why is not "=" a method?
>> Because it's not something done to objects, but to reference
>> variables that we use to manipulate objects. I'm really curious
>> as to why one would want to redefine assignment in the first
>> place. I mean, seriously. It's not like this is C++ where you
>> have to reinvent everything every time you work with the bloody
>> language.
> It's not a question to redefine the "=" operator it's a question
> of orthogonality, what you learn for one thing is equally
> applicable to other parts of the language, it's interesting some
> times to have the option to redefine the equal operator, but in
> most of the cases doing so is adding a real complexity to the
> understanding of the program, this does not means, that if you
> need to do it you can

There is no orthogonality allowed by the redefinition of assignment
in Ruby -- or in any other language that I've ever dealt with. What
it does is creates "exceptions" -- and that violates orthogonality.
Beyond that, since "=" (which is ASSIGNMENT in Ruby) isn't done to
objects, but to references. You can, of course, easily redefine
'==' (COMPARISON).

>>> 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.
>> This is just MNSHO, but again I don't see why one would want to
>> allow such basic constructs to be redefined. IMO, you can
>> redefine everything except boolean tests and still have a useful
>> -- if obtuse -- language; if you try to redefine those, you're
>> not going to be able to have any determinacy with the programs
>> that are written.
> You can...
> 
> class TrueClass
>   def and (anArgument)
>       return "hello"
>   end
> end
> 
> I've redefined the and, it does not work, but it does not generate
> any warning or error...

I just did that -- and I still get the "and" that I expect. As I
pointed out above, "and" isn't a method. Just because you can define
a method that is named the same as a keyword doesn't mean that it
will actually *be* that keyword.

>> Why is it necessary to access the primitives? IMO, Java's biggest
>> problem is that it makes the primitives available. In Ruby, by
>> the way, I can still change the behaviour of String -- this is
>> where Ruby differs from every other language that I've ever used:
>> it's dynamic. If I need a new function on String, I can add it
>> whenever I need. I'm looking at extending the functionality of a
>> library that I've ported so that it can optionally extend String
>> and Array to include this library as methods on String and Array
>> instead of as something else to operate on a String or an Array.
> Yes it's not needed, in Basic, you can not access the primitives
> and the language is still working, but Ruby is much more powerful
> and flexible, not because you can access the primitives, but
> because the language gives you more options. The primitive access
> is just another option.

IMO, Ruby is more expressive than Java -- which gives access to the
primitives behind a lot of objects.

> Consider for example the string extension you want
> class String
>   def strExtension
>       call libStrgExtension.o:110
>   end
> end
> 
> It's not this way much more easy to do?

No, it isn't, actually. Mostly because my library is written in Ruby
itself, but also because Ruby has clear and *easy* ways of extending
itself which don't require access to primitives *from within Ruby*.

[more on primitives elided]

>> It would NOT be much more natural to require every bloody module
>> I need every time I need it. A language -- especially a language
>> like Ruby, where Strings are fundamental to everything -- isn't
>> useful without certain defaults. Would it not make equal sense to
>> "require integer" when I need to use integers, or are you
>> suggesting that those are fundamentals and are always included?
>> Strings are part of what makes Ruby useful immediately (the same
>> applies to Files) because it's a scrpiting language.
> I did put "String" as an example, but in fact the only needed
> module is "kernel", the base of the language, where Object,
> Boolean, and Magnitude are defned (in Ruby there is no Boolean
> class and no Magnitude, but you have Fixnum and TrueClass and
> FalseClass, I think that this is going to change in the future).
> The rest are extensions, what an OO language is supposed to deal
> with.

Matz determined that String, Regex, Array, Files, and Hashes (among
other thigns) are necessary parts of the language. Given the sorts
of work that I've done with Ruby so far -- I agree.

>> I'm sorry, but I don't understand what you're getting at here.
>> The three examples you gave:
>>      a.+(3)
>>      a.+ 3
>>      a + 3
>> 
>> are actually the only ways to express that thought (without
>> getting silly wrt parenthesis). Ruby explicitly makes parentheses
>> optional on method calls. Parentheses make complex operations
>> easier to read, certainly, and can prevent confusion for the
>> interpreter and programmer, as when you have:
[...]
> You will like then the Perl's "there is a hundred ways to do it"
> slogan.. :-)

It's actually "TMTOWTDI" -- there's more than one way to do it.
Indeed, this is the mark of a mature, expressive language. Look
closely at your own native human language -- there's more than one
way to express something. Even silly invented languages like logban
have multiple ways of expressing ideas.

> The fact that there is more than one way to express something,
> weakens the mastery of the language. It's right sometimes becasue
> it makes things so "eye sugar" , but I prefer ( I PREFER, it's me,
> my option) a one way to do things, it makes things easy to code
> and easy to read your own code and the one made by others.

That's what coding standards are for, not programming language
designs.

>> Actually, it can't give you the same results without trouble. C++
>> *is* trouble because it allows the definition of:
>>      a = a + b   // a.=(a.+(b))
>> to be different from:
>>      a += b    // a.+=(b)
>> If the result of the first call isn't the same as the result of
>> the second call, then there's a disconnect which has to be
>> documented. Matz made the right choice here, I think, because it
>> prevents this sort of stupidity that C++ allows. (And this isn't
>> 'prevention' in the way that I think GvR was beyond silly to
>> require indentation for block definition in Python.)
> I disagree, You loose flexibility, it does not mean that you need
> to use it, it means that you have the flexibility there when you
> need it.

I don't see it as flexibility lost. I see it as "utterly stupid
behaviour" prevented. There is no legitimate reason for someone to
define a = a + b to be different from a += b.

> Anyways, if I define a.+=b to be diferent from a.=a.+b it's my own
> fault for using bad semantincs, but it can be posible that someone
> must be interested in having side efects associated with the +=
> operator (as in C++, and yes it's troublesome). In Smalltalk you
> can do it and there are no problems with the added flexibility,
> contrary to C++ where a lot of programmers started to do OOP
> without a solid background on OO analisys, this bring us the
> problems with C++

There's more problems with C++ than the "lack of solid background";
I suggest that Smalltalk, if it were as popular and widespread as
C++, would have a lot of the same stupid behaviours (like the
idiotic redefinition of a+=b differently from a=a+b).

>> The interpreter will warn you of this, to some degree. If I try
>> to use an undefined variable, it will complain (at least with
>> 1.7) because the value is unknown (it's not even properly 'nil').
>> This won't help, however, if you have two similarly named
>> variables.
> OK, I'll try...I'm using Linux with 1.6. Anyways a warning would
> be a great addition, you will catch the error at compile time
> instead of at run-time.

There is no compile time.

>> This one is easy: because it was a design decision made earlier.
>> A new version of String is being worked on, to the best of my
>> knowledge, that will deal with characters -- but this leaves the
>> problem of existing code which will break because it uses the
>> current implementation.
> It does not need to break nothing a character is an integer with a
> dual personality, maybe you will just need to redefine some
> methods based on the arguments, but I don't foresee serious
> problems.

It *will* break things. If string[i] no longer returns an integer,
then code will break. There are numerous libraries out there -- how
many of them use this behaviour? I don't know -- but there's a big
chance of breakage -- and not everything is easily available
anymore.

>> A bytecode system is being worked on, to the best of my
>> knowledge.
> Someone pointed me to Parrot, I've done him just a look, and it's
> interesting.

Parrot isn't Ruby's bytecode system, although it may work with it in
the future.

-austin
-- Austin Ziegler, [e-mail] on 2002.11.03 at 18.17.34