Re: Ruby vs Perl performance

(1)
--------------------
David Masover wrote:
> 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.

I have told you are the master of sabotage. Now tell me why on Earth 
would one define things like { true==false } and { 2+2==5 }. I have more 
trouble with Ruby crashing because of your sabotage! But that I can live 
with, since I understand that Ruby internals depend on the premise { 
true != false }!

As for your surprise that how far I have come, I must tell you that I am 
only surprised I keep debating you. This is what happens when one 
engages in public debates :( Much of what you are saying may be true 
from your perspective, however, I simply do not have time to babble so 
much.


(2)
----------------
Mike Gold wrote:
> If you are committed to measuring everything in accordance with Booch, 
> you will find a whole legion of sinners here.  Indeed, that I and others 
> keep wondering why you are not using Java or C++ makes sense in light of 
> this.  For the most part Ruby goes duck-typing route, which is 
> fundamentally different than the route of Java or C++ 
> patterns/methodologies you find in Booch.

Perhaps you are mislead by the nature of the discussion here, which has 
deformed into something other than what the thread's title suggests. I 
am not an OO purist and should basically be rather surprised at most of 
what you've said above, mostly because of how I entered this discussion. 
Let me repeat:

>> Ruby and Perl are two totally different programing 
>> environments and are really not to be compared with regards
>> to their run time performance. With Ruby the performance 
>> issue is shifted to the entire project life cycle, and indeed
>> to the complexity of the project. Mere execution time of an 
>> application represents only a tiny fraction of what is truly 
>> measured when comparing procedural language like Perl and 
>> object oriented Ruby. If you compare the two languages in 
>> this respect Perl doesn't come even close to where Ruby stands. 
>> In fact I believe if you look at performance issues from this 
>> angle, Ruby stands out very proudly as the best performing 
>> programming language of all times.

Most likely, with my focus on OO, I am also responsible for the 
splintering of this discussion into many branches. But the fact remains 
that despite some of its immaturities Ruby is one of the best OOPLs 
around today.

I have also repeatedly praised Ruby's inherent duck-typing philosophy, 
which ironically seems to be one of the strongest points my opponents 
make, when they mindlessly and unjustly build it up as significant 
Ruby's flaw. The other point that I was arguing was that Ruby's 
flexibility is not its fault but its strength, which again the opponents 
of the idea that Ruby is setting standards for future OOP language 
developments are constantly attacking with irrelevant arguments. They 
support their attacks by dissecting nonsensical algorithms that in 
normal circumstances indeed are inherently bad or even evil. Ruby with 
many of its extensions, some of which indeed are  shared with more 
procedural Perl and OB (object-based) Lisp, but especially, as you say, 
with its ability to allow programs to effectively rewrite and redefine 
themselves at runtime, is a powerful tool. All these attributes do not 
make Ruby a procedural language, it remains one of the best, if not The 
best, OOPLs around today!

> Take the example of delegation.  There is no notion of Java-like 
> interfaces or C++-like classes of just pure virtuals.  In Ruby a 
> delegate can have no relation, ancestry-wise, to the object it wraps. 
> It violates all the Booch rules: it should be outlawed!

I could not disagree more. You are suggesting the rigidity that can only 
be attributed to literary interpretation of the "scripture". It is in 
fact Ruby's virtue that it did away with unnecessary virtuals and 
abstract classes. But as I am repeatedly saying, it is up to the 
designer to ignore these features or reinforce them. Go ahead and 
reinforce them with an "abstract" class of "virtual" methods that do 
nothing but throw exceptions, to make sure you actually define them. At 
the end My code will be shorter and more elegant, and true, for a Java 
or C++ virtuoso perhaps less legible.

(3)
------------------
Chad Perrin wrote:
> I'm not sure you're clear on the definition of "orthogonal".
> . . . and OOP is actually very hierarchical in a lot of ways, 
> at least as practiced in most languages -- including, to a 
> lesser extent, Ruby.

The term "orthogonal" is not an OOM (OO methodology) term, though it is 
often used in texts and discussions pertaining to OO. Its meaning in OOM 
discussions is an evolved meaning that expands even the definition in 
Oxford dictionary, where it is explained merely as something 
"right-angled". Logically in OOM the term loosely means "the opposite". 
An object organization is flat organization, and is orthogonal to 
structured pyramid organization. "Is-a" relationship defines hierarchy 
and is orthogonal to "has-a" relationship which represents aggregation 
or composition. In flat organization one set of rules apply, while in 
the structured organization orthogonal rules apply. In this respect 
procedural programing is orthogonal to OOP. Now the tricky part is that 
OO includes procedural programming as a "part-of" or a "has-a" thing. 
This means that programming in procedural way in an OOPL should be 
possible without any effort, however, the reverse is not true because 
the two programming paradigms are orthogonal. Again this does not mean 
that in procedural language it is not possible to program in OO 
programing paradigm, it only takes extraordinary effort and/or overhead 
to do so. This is how orthogonality is accounted for with respect to OOP 
and procedural programming.

Perl is an excellent example of what was just said. It takes an 
extraordinary effort to use it as an OOPL. It requires that the 
programmer knows much more about OO rules than the programmer who uses 
Ruby where everything is an object. A totally and utterly different 
question is whether you use these languages correctly be it Perl, C, 
C++, Java, Ruby or ooCobol. This is where most of us fail most of the 
time, and that is why Design Patterns and Booch OOA/D exist.
-- 
Posted via http://www.ruby-forum.com/.