From: David Masover <ninja@...>
Date: 2009-02-11T17:43:59+09:00
Subject: Re: Ruby vs Perl performance

Igor Pirnovar wrote:
> OO itself is not chaotic and does not, as I have already said, promote 
> anarchy, which you are suggesting.

Was I suggesting anarchy? I thought I was suggesting a specific feature: 
Rip a method out of one class and apply it to another.

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

Ruby's strength is in what you're calling "anarchy" -- except when you 
choose to call it "flexibility".

> There are rules that have to be 
> adhered to, only they are much more relaxed than are rules in 
> hierarchical structured pyramids of structured organizations.
[snip]
> There are rules that govern the freedom of selecting 
> procedural or structured methods, and when to abide by the orthogonal OO 
> principles. Failing to understanding these principles leads to chaos and 
> anarchy.

You've certainly not done a good job of explaining or defining such rules.

> The fact that you see meritocracy in the same light as 
> aristocracy

Show me where I said that.

> In procedural languages you have to enforce these rules 
> yourself, in OO ideally the language enforces these concepts.

Erm... Why aren't you using Java again?

If I wanted a language to enforce those rules, I'd be back to something 
like:

class Hello {
  public static void main(String [] args) {
    System.out.println("Hello, world!");
  }
}

I don't. It's fine if the language can enforce them -- in Perl, I can do 
things like 'use strict' or 'use warnings'. In Ruby, I can simply grep 
through my source files to make sure I haven't stooped to using eval 
anywhere I don't absolutely have to.

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.

It's a lot easier to ignore functionality you don't need than it is to 
find functionality you do need missing.

> Module is 
> not a class,

Actually, Module _is_ a class.

> And 
> lastly, an instance method should not be treated as a loosely defined 
> function, nor should an object exhibit some foreign behaviour of some 
> arbitrary function, it totally violates encapsulation.

So do:

 - instance_variable_set
 - instance_variable_get
 - send
 - instance_eval
 - Binding#eval
 - extend
 - class << foo

And, to a lesser extent:

 - Modules as mixins (unless _very_ carefully written, they're touching 
the same instance variable namespace)
 - class_eval
 - include
 - const_set
 - define_method

Am I missing any?

If you wanted a language that enforced encapsulation, I say again, go 
back to Java, or to C++. You'll find encapsulation in Ruby is every bit 
as much convention as it is in Perl.

The language makes it harder to violate that convention by accident, 
that's all. And if you want to enforce it, all you have to do is grep 
through your codebase for cases of instance_variable_set, and similar 
constructs.

Take a quick look at that first list. Have you really never used any of 
those? Are you sure?

> Your propositions 
> and suggestions translate into total chaos and anarchy, where any 
> identity could be shared among all members of the universe

I'm suggesting that it be possible to rebind a method.

Again: How is that worse than any of the above? You're acting as if it 
would destroy the fabric of the universe!

I was expecting opposition along the lines of "This would be difficult, 
the way the Ruby interpreter is written." Instead, I'm getting the kind 
of response I would expect from the bad old Rails community: "You can't 
do that because we think it's a bad idea, so we're protecting you from 
yourself."

> many objects are actors and actors are subjects with 
> responsibilities and behaviours, by which you classify them.

Right. I don't know about you, but I classify them by their actual, 
demonstrated behavior, not their ancestry.

Why, then, does the system for copying methods from one object to 
another restrict by ancestry, and not by behavior?

>> Except Perl is not strictly procedural, and Javascript actually has a
>> very nice prototypal object system.
>>     
>
> This is is pure baloney. Perl was designed as such,

And Linux was designed as a terminal emulator. Quite literally. Look 
where it is now.

Now who's arguing aristocracy? Perl can never be OO, because it wasn't 
designed that way? Languages evolve.

> The 
> same is true for JavaScript, which, metaphorically speaking, became of 
> old age only after ten years of it's existence.

That only shows how little you know about JavaScript. It was actually 
originally written as a dialect of LISP, and only later given a C-like 
syntax to make the PHBs happy.

Because of its Lisp heritage, I can guess, but cannot prove, that it 
always had closures, and always had functions as first-class objects. 
Attempting to look at the history of object-oriented Javascript, you 
find that it is mostly about people finding ways to express the kind of 
object systems they want, using the powerful prototypal object system 
that was already in place.

In fact, when it comes down to it, there's no reason you can't program 
Javascript the way you program Ruby. It's not difficult to write a sane 
each() method, or add a class hierarchy (as opposed to prototypal 
inheritance). However, it is much more difficult to write Ruby the way I 
wrote Javascript, when I had to use it for more than just a web client, 
and some things, as I've mentioned, are actually impossible. You speak 
of "anarchy", but it worked, and it worked very well.