From: Igor Pirnovar Date: 2009-02-13T06:22:45+09:00 Subject: 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/.