From: Julian Leviston <julian@...>
Date: 2009-02-11T23:01:43+09:00
Subject: Re: Ruby vs Perl performance

Just let him have his pain!

Blog: http://random8.zenunit.com/
Learn rails: http://sensei.zenunit.com/

On 12/02/2009, at 12:23 AM, Igor Pirnovar <gooigpi@gmail.com> wrote:

> David Masover wrote:
>
>> I fail to see how that's more inherently anarchistic than:
>>
>> - Re-opening classes at runtime
>> - Redefining methods, or whole classes, also at runtime
>> - Adding a method or mixing a module into just one instance
>> - All of the above with user input (eval)
>> - Doing no type checking whatsoever
>> - Overriding basic operators (make 2+2==5)
>> - Corrupt basic assumptions (make nil.nil? false) and crash
>
> Indeed, all this can lead to anarchy and chaos, but that is your  
> doing!
> There must be a reason for redefining a class, if it is a subversion
> than indeed it is anarchy, but how many creators sabotage their own
> creation?. Language enforcing the rules does not mean that it should
> stop you from making incorrect assumptions such as 2+2==5.
> Statistically, type checking is not needed and mostly presents an
> unnecessary clutter in the code with little if any benefit at all. And
> what's nil.nil - some devilish construct of yours?
>
>> Ruby's strength is in what you're calling "anarchy" -- except when  
>> you
>> choose to call it "flexibility".
>
> I do not call Ruby anythingexcept OOPL from start to the end. And most
> certainly all that you call inherently anarchistic above if used to
> model the reality you are trying to reproduce with your design is  
> power
> unheard of in the traditional OOPLs.
>
>> You've certainly not done a good job of explaining or defining such
>> rules.
>
> I did not invent nor made up those rules, they are spelt out in Booch,
> and nicely packed in design patterns. You can adhere to these rules in
> any language even assembler, it only is much harder to do so in
> procedural languages. Besides, it is not so much about following these
> rules as understanding them. Your misplaced comments about most of the
> details you are bringing up in this discussion and most noticeably  
> about
> encapsulation show a serious deficit in this area on your part.
>
>>> The fact that you see meritocracy in the same light as
>>> aristocracy ...
>> Show me where I said that.
>
> Are not the following your words: "Except that Ruby enforces the
> aristocracy with respect to which methods
> belong to which classes". I have gone to great length explaining the
> difference between taxonomy that classifies things by its membership  
> and
> the other that takes into account the merits. The two are orthogonal  
> and
> do not mix as you are suggesting by attributing knighthood based on
> behaviour (activity, methods, functions, processing) rather on  
> ancestral
> principles based on name or membership, as is known to us throughout  
> the
> history.
>
>> ... 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
> for encapsulation, orthogonality of aggregation or composition and
> inheritance, for rule of favouring delegation over inheritance,...  
> heck
> I do not even know you understand what I am talking about! And I  
> have no
> time explaining or defining all this to you. For any OO programmer,
> designer or analyst these are pure facts nobody questions or doubts  
> any
> more.
>
>> 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.
>
> You are a master of sabotage. I believe you do this only in forum
> discussions and not to your code and creative processes, however if  
> this
> writing is a creative process, you must somewhat of an anarchist.
>
>> It's a lot easier to ignore functionality you don't need than it is  
>> to
>> find functionality you do need missing.
>
> And what a generality is again this? I have not found it in any of the
> pertinent methodologies discussed here. Most likely it is a convenient
> concoction of yours for the sake of argument and no substance or merit
> for that matter.
>
>> Actually, Module _is_ a class.
>
> Modularity packs abstractions into discrete units. Abstractions are
> represented by classes. There is no way on the Earth to turn this
> definition around.  Namely a class can never be a module nor is  
> module a
> class as you are suggesting. Yes, you could make your own concoctions
> but that ain't gonna be OO!
>
>> Am I missing any?
>
> As I have shown you above, a great deal and much more.
>
> Have fun, cheers
> -- 
> Posted via http://www.ruby-forum.com/.
>