--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--