From: Chad Perrin <perrin@...>
Date: 2009-02-12T04:10:41+09:00
Subject: Re: Ruby vs Perl performance

--MnLPg7ZWsaic7Fhd
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Feb 11, 2009 at 10:23:23PM +0900, Igor Pirnovar wrote:
> David Masover wrote:
> >=20
> > Ruby's strength is in what you're calling "anarchy" -- except when you
> > choose to call it "flexibility".
>=20
> I do not call Ruby anythingexcept OOPL from start to the end. And most=20
> certainly all that you call inherently anarchistic above if used to=20
> model the reality you are trying to reproduce with your design is power=
=20
> unheard of in the traditional OOPLs.

In that case, I think you're missing out on a lot of what Ruby has to
offer.  There's much more to it than object hierarchies.


> >=20
> >> The fact that you see meritocracy in the same light as=20
> >> aristocracy ...
> > Show me where I said that.
>=20
> Are not the following your words: "Except that Ruby enforces the=20
> aristocracy with respect to which methods
> belong to which classes". I have gone to great length explaining the=20
> difference between taxonomy that classifies things by its membership and=
=20
> the other that takes into account the merits. The two are orthogonal and=
=20
> do not mix as you are suggesting by attributing knighthood based on=20
> behaviour (activity, methods, functions, processing) rather on ancestral=
=20
> principles based on name or membership, as is known to us throughout the=
=20
> history.

I think you must have completely misinterpreted what David said.  He said
that Ruby enforces what you call an "aristocracy" model in some respects,
not that aristocracy and meritocracy are the same in any way.


> >=20
> > ... It's fine if the language can enforce them -- in Perl, I can do
> > things like 'use strict' or 'use warnings'...
> Again you are mixing apples and oranges. Perl's strict does not qualify=
=20
> for encapsulation, orthogonality of aggregation or composition and=20
> inheritance, for rule of favouring delegation over inheritance,... heck=
=20
> I do not even know you understand what I am talking about! And I have no=
=20
> time explaining or defining all this to you. For any OO programmer,=20
> designer or analyst these are pure facts nobody questions or doubts any=
=20
> more.

Blessing provides encapsulation.  The extreme simplicity of generating
lexical closures can provide both encapsulation and protection stronger
than the average Ruby object provides.


> >=20
> > 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.
>=20
> You are a master of sabotage. I believe you do this only in forum=20
> discussions and not to your code and creative processes, however if this=
=20
> writing is a creative process, you must somewhat of an anarchist.

I have a couple of points to make:

  1. You're obviously trying to slander the speaker rather than address
  his points.  That's pretty offensive.

  2. If you want to keep using "anarchy" that way, you should probably
  try making a case for "anarchy" being an inherently bad thing first.


> >=20
> > Actually, Module _is_ a class.
>=20
> Modularity packs abstractions into discrete units. Abstractions are=20
> represented by classes. There is no way on the Earth to turn this=20
> definition around.  Namely a class can never be a module nor is module a=
=20
> class as you are suggesting. Yes, you could make your own concoctions=20
> but that ain't gonna be OO!

Let's see what ri says:

---------------------------------------------------------- Class: Module
     A +Module+ is a collection of methods and constants. The methods in
     a module may be instance methods or module methods. Instance
     methods appear as methods in a class when the module is included,
     module methods do not. Conversely, module methods may be called
     without creating an encapsulating object, while instance methods
     may not. (See +Module#module_function+)

     In the descriptions that follow, the parameter _syml_ refers to a
     symbol, which is either a quoted string or a +Symbol+ (such as
     +:name+).

        module Mod
          include Math
          CONST =3D 1
          def meth
            #  ...
          end
        end
        Mod.class              #=3D> Module
        Mod.constants          #=3D> ["E", "PI", "CONST"]
        Mod.instance_methods   #=3D> ["meth"]

------------------------------------------------------------------------

--=20
Chad Perrin [ content licensed OWL: http://owl.apotheon.org ]
Quoth Jeff Henager: "If the average user can put a CD in and boot the
system and follow the prompts, he can install and use Linux.  If he
can't do that simple task, he doesn't need to be around technology."

--MnLPg7ZWsaic7Fhd
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (FreeBSD)

iEYEARECAAYFAkmTInIACgkQ9mn/Pj01uKXgaACgvXj0gBb6MZMjRZd8wMoncXtc
X/sAoNSzwalWftFCtdXbzUEbmG1WMW2h
=3VYh
-----END PGP SIGNATURE-----

--MnLPg7ZWsaic7Fhd--