From: Igor Pirnovar Date: 2009-02-11T15:50:24+09:00 Subject: Re: Ruby vs Perl performance David Masover wrote: > However, you should also realize that both Perl and > Javascript have a few similar features that make Ruby actually stricter > than either. Similarities exist because Ruby is OOPL, and supports much broader domain and programming paradigm than that in which and for which Perl was designed and invented. Ruby is OOPL from the start, and has to be able to model both geriatric pyramid organizations as well as flat object organizations. The two indeed are orthogonal. However, OO has not totally relaxed all the rules and does not promote a kind of anarchy one could create with JavaScript and Perl. > The examples I gave both revolve around the fact that in > Perl and Javascript, functions (or subroutines) are just that. They can > be used as methods, and thus related to an object or a class, but they > are not inherently tied to that object. > > In Ruby, however, I can't use a method from one class on a method from > another class, unless the two classes are related. I also can't use a > class as a module. In other words, it's the exact same sort of static > type checking, protect-you-from-yourself mentality as Java. Though the advent of OO enabled us to much better cope with complex, parallel and concurrent systems all of which are also elements of chaos, OO itself is not chaotic and does not, as I have already said, promote anarchy, which you are suggesting. There are rules that have to be adhered to, only they are much more relaxed than are rules in hierarchical structured pyramids of structured organizations. OO organizations are flat and they accept and tolerate orthogonal concepts, something unimaginable in pyramid structural organizations and programming. There are rules that govern the freedom of selecting procedural or structured methods, and when to abide by the orthogonal OO principles. Failing to understanding these principles leads to chaos and anarchy. The fact that you see meritocracy in the same light as aristocracy is one such example of poor understanding of classification and membership, or inheritance, aggregation, association and delegation for that matter. In procedural languages you have to enforce these rules yourself, in OO ideally the language enforces these concepts. Module is not a class, which is not only true in Ruby but also in the OO bible - Booch's OOA/D. This can be said for all general OO methodologies. And lastly, an instance method should not be treated as a loosely defined function, nor should an object exhibit some foreign behaviour of some arbitrary function, it totally violates encapsulation. Your propositions and suggestions translate into total chaos and anarchy, where any identity could be shared among all members of the universe (read any domain)! > Except that Ruby enforces the aristocracy with respect to which methods > belong to which classes. You are ignoring the merits on which a pure OO class enforces membership rights. This unjustly is often seen as an anthropological attribute objects have, but many objects are actors and actors are subjects with responsibilities and behaviours, by which you classify them. You are pushing aristocracy where it has no place. True there are objects that only exist to carry a state, and they do have their place in the universe as passive entities born with a silver spoon in their mouth, one might say. However, not much would be happening if objects with behaviour would not exist. Ask yourself, what connotation is ascribed to the above mentioned property: "born with a silver spoon in your mouth", and on the other hand what the orthogonal connotation ascribed to the phrase "well earned" is? > Except Perl is not strictly procedural, and Javascript actually has a > very nice prototypal object system. This is is pure baloney. Perl was designed as such, and OO is only it's extension - a bonus so to speak, which becomes a tremendous burden to the language, and very quickly even larger burden to the developer as well as the project as it grows beyond certain level of complexity. The same is true for JavaScript, which, metaphorically speaking, became of old age only after ten years of it's existence. Cheers, have fun! -- Posted via http://www.ruby-forum.com/.