From: David Masover <ninja@...>
Date: 2009-02-12T02:40:41+09:00
Subject: Re: Ruby vs Perl performance

Igor Pirnovar wrote:
> David Masover wrote:
>
>   
>> I fail to see how that's more inherently anarchistic than:
>>
>>  - Re-opening classes at runtime
>>  - Redefining methods, or whole classes, also at runtime
>>  - Adding a method or mixing a module into just one instance
>>  - All of the above with user input (eval)
>>  - Doing no type checking whatsoever
>>  - Overriding basic operators (make 2+2==5)
>>  - Corrupt basic assumptions (make nil.nil? false) and crash
>>     
>
> Indeed, all this can lead to anarchy and chaos, but that is your doing! 
>   

Exactly my point. So if I am allowed these things which can lead to 
anarchy, why am I not allowed this other thing that can lead to anarchy?

Unless you mean they are "my doing" in that I wrote these capabilities 
into Ruby, which I didn't.

> Language enforcing the rules does not mean that it should 
> stop you from making incorrect assumptions such as 2+2==5. 
>   

I'm talking about:

class Fixnum
  alias_method :old_plus, :+
  def +(other)
    if self == 2 && other == 2
      5
    else
      self.old_plus(other)
    end
  end
end

> Statistically, type checking is not needed and mostly presents an 
> unnecessary clutter in the code with little if any benefit at all.

Ok, but what does that have to do with statistics? And does it not 
strictly enforce the rules you seem to care about?

> And 
> what's nil.nil - some devilish construct of yours?
>   

All objects respond to .nil?, and I'm surprised you made it this far in 
a discussion of Ruby without knowing about this.

And, since classes are open, you can do this:

class NilClass
  def nil?
    false
  end
end

Go ahead, type that into irb. Watch it crash on the very next command.

> power 
> unheard of in the traditional OOPLs.
>   

Traditional, like, I don't know, Smalltalk? It seems just as reflective.

>>> The fact that you see meritocracy in the same light as 
>>> aristocracy ...
>>>       
>> Show me where I said that.
>>     
>
> Are not the following your words: "Except that Ruby enforces the 
> aristocracy with respect to which methods
> belong to which classes". I have gone to great length explaining the 
> difference between taxonomy that classifies things by its membership and 
> the other that takes into account the merits. The two are orthogonal and 
> do not mix as you are suggesting by attributing knighthood based on 
> behaviour (activity, methods, functions, processing) rather on ancestral 
> principles based on name or membership, as is known to us throughout the 
> history.
>   

Except that which objects are allowed to have a certain method is 
restricted entirely by ancestral principles.

I did not say that I saw a meritocracy in the same light as an 
aristocracy -- that's something you're inferring beyond what I actually 
said. In this particular instance, Ruby is _not_ a meritocracy.

>> ... It's fine if the language can enforce them -- in Perl, I can do
>> things like 'use strict' or 'use warnings'...
>>     
> Again you are mixing apples and oranges. Perl's strict does not qualify 
> for encapsulation, orthogonality of aggregation or composition and 
> inheritance,

True enough. It is, however, an example of choice vs being forced to -- 
Perl's strict mode will force me to declare variables. However, if I 
don't turn it on, the language will let me define variables as I like.

It is an unrelated feature, but Ruby does similar things -- in 1.9, we 
have send and public_send. If I want to be safe, and respect 
encapsulation, I use public_send. If I don't, I use send.

> And I have no 
> time explaining or defining all this to you. For any OO programmer, 
> designer or analyst these are pure facts nobody questions or doubts any 
> more.
>   

Clearly, I am an OO programmer. And clearly, I doubt them.

And clearly, you have time to write long, rambling responses that 
_don't_ explain these principles. Argument from Authority?

>> So, if there was an UnboundMethod#bind! method, which would bind that
>> method to an object completely unrelated, I could choose not to use that
>> method. So could you. I don't see how its very existence threatens that.
>>     
>
> You are a master of sabotage.
>   

Nice ad-hominem. It doesn't answer my question.

>> It's a lot easier to ignore functionality you don't need than it is to
>> find functionality you do need missing.
>>     
>
> And what a generality is again this? I have not found it in any of the 
> pertinent methodologies discussed here.

No, I consider it to be a self-evident truth, and something you see in 
the design of Ruby.

For example: The ability to deliberately break encapsulation, and use 
instance_eval, or send instead of public_send, etc, is something I've 
certainly found useful in my own code. Tell me, have you never found a 
use for these? Or even for class_eval?

How would you feel if someone removed them, because they felt they were 
"sabotage", that they violated the "purity" of Ruby's OO system?

Certainly, you don't want to just be using them all the time, because 
that would lead to, as you said, "anarchy". But when you need them, you 
need them, and nothing else will do.

>> Actually, Module _is_ a class.
>>     
>
> Modularity packs abstractions into discrete units. Abstractions are 
> represented by classes. There is no way on the Earth to turn this 
> definition around.  Namely a class can never be a module nor is module a 
> class as you are suggesting.
>   

Modules are not classes, you are right. However, the global constant 
Module is a class. That is what I meant.

Oh, and classes are modules. You can verify this for yourself:

Class.new.kind_of? Module