From: Chad Perrin Date: 2009-02-14T04:51:22+09:00 Subject: Re: Ruby vs Perl performance --0OAP2g/MAC+5xKAE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 13, 2009 at 06:22:45AM +0900, Igor Pirnovar wrote: >=20 > (2) > ---------------- > Mike Gold wrote: > > If you are committed to measuring everything in accordance with Booch,= =20 > > you will find a whole legion of sinners here. Indeed, that I and other= s=20 > > keep wondering why you are not using Java or C++ makes sense in light o= f=20 > > this. For the most part Ruby goes duck-typing route, which is=20 > > fundamentally different than the route of Java or C++=20 > > patterns/methodologies you find in Booch. >=20 > Perhaps you are mislead by the nature of the discussion here, which has= =20 > deformed into something other than what the thread's title suggests. I=20 > am not an OO purist and should basically be rather surprised at most of= =20 > what you've said above, mostly because of how I entered this discussion.= =20 Actually, he was probably misled by the fact that you keep using the "fact" that Perl is a "procedural language" as a means of attacking it, and holding up Ruby's OO-ness as proof of its superiority, then follow that up by holding up Booch as the standard of all that is good and right in the world of programming technique. >=20 > I have also repeatedly praised Ruby's inherent duck-typing philosophy,=20 > which ironically seems to be one of the strongest points my opponents=20 > make, when they mindlessly and unjustly build it up as significant=20 > Ruby's flaw. The other point that I was arguing was that Ruby's=20 > flexibility is not its fault but its strength, which again the opponents= =20 > of the idea that Ruby is setting standards for future OOP language=20 > developments are constantly attacking with irrelevant arguments. They=20 > support their attacks by dissecting nonsensical algorithms that in=20 > normal circumstances indeed are inherently bad or even evil. Ruby with=20 > many of its extensions, some of which indeed are shared with more=20 > procedural Perl and OB (object-based) Lisp, but especially, as you say,= =20 > with its ability to allow programs to effectively rewrite and redefine=20 > themselves at runtime, is a powerful tool. All these attributes do not=20 > make Ruby a procedural language, it remains one of the best, if not The= =20 > best, OOPLs around today! I don't think anyone's talking about Ruby's duck typing as a flaw of the language. One or two may have used its duck typing as being similar to some of the more dynamic aspects of Perl (and JavaScript), however, in pointing out that dynamism isn't always bad. You seem to completely, and repeatedly, miss that point in your attacks on Perl, though -- when you keep using its more dynamic aspects as "evidence" of how much it sucks. The point people are trying to make when they bring up Ruby characteristics like duck typing is not some claim that duck typing sucks, as you assert here, but that duck typing is *good*, thus proving that your distaste for Perl's similarly dynamic characteristics is just that: *your* distaste. It's not a universally accepted sign of badness, as you seem to want everyone to believe. In fact, it may have been implied that, in attacking Perl for its dynamic characteristics while blindly praising Ruby's in almost the same breath, you are behaving hypocritically. From where I'm sitting, that's exactly what you seem to be doing; praising Ruby for things that are, in principle, exactly the same as the things for which you deplore Perl. >=20 > > Take the example of delegation. There is no notion of Java-like=20 > > interfaces or C++-like classes of just pure virtuals. In Ruby a=20 > > delegate can have no relation, ancestry-wise, to the object it wraps.= =20 > > It violates all the Booch rules: it should be outlawed! >=20 > I could not disagree more. You are suggesting the rigidity that can only= =20 > be attributed to literary interpretation of the "scripture". It is in=20 > fact Ruby's virtue that it did away with unnecessary virtuals and=20 > abstract classes. But as I am repeatedly saying, it is up to the=20 > designer to ignore these features or reinforce them. Go ahead and=20 > reinforce them with an "abstract" class of "virtual" methods that do=20 > nothing but throw exceptions, to make sure you actually define them. At= =20 > the end My code will be shorter and more elegant, and true, for a Java=20 > or C++ virtuoso perhaps less legible. You're the one trying to use the "scripture" as the final Word on all that is good and right in the world of programming. The above quote was just someone applying your own "logic" to Ruby, and showing you that your ham-fisted attempt to wield Booch as a bludgeon in this discussion doesn't achieve what you seem to think it does -- elevating Ruby to the status of "awesome" while bringing Perl down to the status of "suck". >=20 > (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,=20 > > at least as practiced in most languages -- including, to a=20 > > lesser extent, Ruby. >=20 > The term "orthogonal" is not an OOM (OO methodology) term, though it is= =20 > often used in texts and discussions pertaining to OO. Its meaning in OOM= =20 > discussions is an evolved meaning that expands even the definition in=20 > Oxford dictionary, where it is explained merely as something=20 > "right-angled". Logically in OOM the term loosely means "the opposite".= =20 > An object organization is flat organization, and is orthogonal to=20 > structured pyramid organization. "Is-a" relationship defines hierarchy=20 > and is orthogonal to "has-a" relationship which represents aggregation=20 > or composition. In flat organization one set of rules apply, while in=20 > the structured organization orthogonal rules apply. In this respect=20 > procedural programing is orthogonal to OOP. Now the tricky part is that= =20 > OO includes procedural programming as a "part-of" or a "has-a" thing.=20 > This means that programming in procedural way in an OOPL should be=20 > possible without any effort, however, the reverse is not true because=20 > the two programming paradigms are orthogonal. Again this does not mean=20 > that in procedural language it is not possible to program in OO=20 > programing paradigm, it only takes extraordinary effort and/or overhead= =20 > to do so. This is how orthogonality is accounted for with respect to OOP= =20 > and procedural programming. I know it's not an OO term. Where did you get the crazy idea I suggested it was? The term "orthogonal" *never* means "opposite", *ever* -- except in cases where it is misused, as you used it, just as "infer" never means "imply" except when misused, and "car" never means "golf club" except when misused, and "Empire State Building" never means "Eggs Benedict" except when misused. The use of the term "orthogonal" in discussions such as this should only be used metaphorically, and metaphorically "opposite" would be something that goes back whence the compared object came, not in a completely different direction the way "orthogonal" does. --=20 Chad Perrin [ content licensed OWL: http://owl.apotheon.org ] Quoth Alan Kay: "I invented the term 'Object-Oriented', and I can tell you I did not have C++ in mind." --0OAP2g/MAC+5xKAE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (FreeBSD) iEYEARECAAYFAkmVzyMACgkQ9mn/Pj01uKXEGACfdCH5IuvlJtvv1t02QKMvxx5p 7sQAn2rtBufSJ3z1nLknMP/VBwhCALZf =kI9H -----END PGP SIGNATURE----- --0OAP2g/MAC+5xKAE--