From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,2c6139ce13be9980 X-Google-Attributes: gidfac41,public X-Google-Thread: 109fba,2c6139ce13be9980 X-Google-Attributes: gid109fba,public X-Google-Thread: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public X-Google-Thread: 1014db,3d3f20d31be1c33a X-Google-Attributes: gid1014db,public X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public From: donh@syd.csa.com.au (Don Harrison) Subject: Relative complexity - Eiffel and Ada. Date: 1997/07/22 Message-ID: X-Deja-AN: 258106445 Sender: news@syd.csa.com.au X-Nntp-Posting-Host: dev50 References: Organization: CSC Australia, Sydney Reply-To: donh@syd.csa.com.au Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel,comp.lang.c,comp.lang.c++ Date: 1997-07-22T00:00:00+00:00 List-Id: Matt Heaney wrote: :In article , donh@syd.csa.com.au wrote: : :>Have to disagree here. Appreciation of elegance and purity are God-given :>qualities which many either suppress or don't have much of in the first place. :>Judging by God's handiwork, He possesses them in abundance. : :You've fallen into a common trap, Don. You think that beauty and elegance :exist independent of human perception; this is, of course, incorrect. No, I realise they are perceived but believe that perception is pretty much the same among all people. IMO, apparent variance from this principle is attributable more to other factors such as dishonesty or mistaking other things for elegance than real variance. Assuming complexity is perceived the same by everybody, it suffices to speak simply of complexity rather than someone's perception of it. :Here's a quote for you, to provide an analogy: : :"Complexity per se is not the culprit, of course; rather it is our human :limitations in dealing with complexity that cause the problem." - William :Wulf, quoted by Booch This is true and a necessary consequence is that the complex task of software engineering should be made as simple as possible to accomodate our inadequacy in dealing with that complexity. :There is no such thing as complexity, really. Complexity is just a concept :- it's what is felt by a human, when he observes natural phenomena (or the :reaction of this human when he reviews software...). I disagree. The fact that it is an abstract concept, doesn't mean we can't use it meaningfully to compare things including languages or software. For example, since it's a relative concept, we can make meaningful qualitative statements like "Language A is more complex than language B". Further, since we can even measure complexity, we can say "Language A is roughly 50 times more complex than language B". [Languages A and B shall remain anonymous to protect the innocent.] :) :When you speak of beauty and elegance, those terms have no meaning without :speaking of the human who thinks something is beautiful or the human that :perceives something to be elegant. A thing is not beautiful all by itself :- it is beautiful only in the mind of a human. Agree. :Looking at it from a systems point of view, beauty and elegance are refered :to as "emergent properties," a thing that emerges because of the :interaction of parts. Okay here. :So we can dispense with any mention of God, because he has nothing to do :with it. Contrary to they're being handed over by God, "elegance" and :"purity" are simply concepts that emerge because of the structure of the :human brain. If you take away the human, then of course you take away :elegance and purity to. If you take away God, you take away the human and the ability God has given him to perceive elegance. But for the sake of discussion of perception, it's true that we can ignore the source of that ability. :You even hint at this yourself, when you say "Judging by God's handiwork." :It's a _human_ that does the judging; there being no judge, there can be no :elegant handiwork or pure handiwork - just handiwork. I think what you're saying here is that if something exists in isolation and no-one is aware of its existence, non-one can judge it to be elegant or otherwise. While this is true of some things, it isn't true of languages that we are familiar with. Since we are aware of their existence, we may judge their relative elegance. :In fact, the concept of God is an emergent property, which emerges as the :result of the interaction of a reflexive system aware of its own mortality, :and a strong, built-in propensity to maintain its own existance ("survival :instinct"). Take away the system, and of course you take away "God" too. This may be a convenient notion but there's a slight problem in that no-one seems to have told God about this. When I ultimately stand before His judgement seat, I hope to have something more convincing to say than: "I don't have to worry about you because you're just an emergent property." Actually, I doubt I'll have much to say as I will be the one spoken to, not listened to. ("It can't happen soon enough!", I hear someone saying.) :>:Should one reject Ada out of hand, because :>:mixin inheritance in Ada using generics is "inelegant" compared to using :>:multiple inheritence in Eiffel? :> :>No, but it may mean that you're not able to model things as directly as you :>might otherwise. : :Spoken like a true afficionado of inheritence! Well, I have some more news :for you, Don. Nature (interpret that to mean God, if that suits you) has :chosen aggregation as the essential means of systems construction. Oh, by :the way, artificial ("man-made") systems are built using aggregation too! Not just aggregation but also inheritance. God has chosen a common template in His creation which is applied repeatedly. An example is the animal template which is composed of a brain, a heart, limbs etc. (aggregation). God has applied this template to all animals (technically, it's the reverse relation of inheritance at work). :Imagine that! Not bad, eh? :In spite of what you may have heard, your dishwasher, your car, your watch, :and even you are constructed using aggregation. Last time I checked, :neither my computer (my little Mac, bless it), nor my stereo, nor my :microwave oven were constructed using inheritence - not even (gasp!) :multiple inheritence. Say it ain't so, Joe! Joe: "It ain't so". :) What you're missing is that all these things also inherit (the designs common to all computers, to all stereos etc. The designers of the particular objects you possess have applied the inherited the designs of their predecessors and simply refined them a little. We know this practice as "Not re-inventing the wheel". :How is this even possible? the dear Eiffel reader must be wondering. Tell us! Tell us! (Sorry - couldn't resist). :Oh, yes, I know the argument: Humans use classification to simplify things, :so we should use classification to build software, blah blah blah. Well :here's the real scoop: humans use _abstraction_ to simplify their world. :Humans view and build systems as multi-level, heirarchical structures, :using _aggregation_. .. and inheritance. :So why build software systems any differently? Why, indeed! :In spite of the propaganda enunciated by certain computer scientists, real :software systems do get built without inheritence. A lone voice in a :chaotic world, JP Rosen, says it clearly enough: : :"Once again, composition will exhibit a lower complexity and a greater :security at the cost of ease of design. For small-sized, quickly developed :projects, classification can be an efficient method. But for large-scale, :long-lasting projects, composition is necessary to ensure control on the :overall complexity." - JP Rosen, What Orientation Should Ada Objects :Take?, CACM, Nov 1992 (Vol 35, No 11) I don't know what the basis is for this claim, but he's probably talking about assertion-less software (eg. Ada). Inheritance minus DBC *is* dangerous and may introduce uncontrollable complexity. However, inheritance plus DBC scales up quite nicely thanks very much so there's no need to favour composition or inheritance depending on system size. :If neither I nor Jean-Pierre can convince you of the efficacy of :aggregation over inheritence, then perhaps these authors can:.. :And if that isn't enough, maybe the Gang of Four can put you over the edge:.. : :"Favor object compostion over class inheritance." -- p. 20 of Design :Patterns, by Gamma et al In view of the danger of using inheritance *without* DBC and the fact that no commercial OO language in wodespread use promotes DBC, is it any surprise that the bulk of respected literature tries to steer you away from inheritance. I don't find that at all surprising. :The argument that in Ada, "you can't model things as directly as you might :otherwise," is completely specious. Just the opposite is true, in fact. If I had the time, I could show this to be false (in general, compared to Eiffel) .. :Ada has a very rich type system, specifically designed to allow you to :"directly model" logical entities, and especially physical entities, as :would be necessary for its intended domain, embedded systems. I agree Ada is strong in this area. Your example below demonstrates it well. :Let's consider a simple example, from Ada: Language and Methodology, by :Watt, Wichmann, and Findlay (the "famous" book in which Tony Hoare tepidly ^^^^^^^ :) :endorses Ada in the Foreward). [example elided] :Now, what were you saying about not be able to model the problem directly? I agree Ada fares well in modelling low-level problems but I think Eiffel is better generally as a modelling tool. Also, so you may savour your moment of glory, I'll refrain from commenting on some syntactic issues. :) In terms of low-level modelling, I guess a different (more OO) approach would suit Eiffel better. BTW, I think you'll find most Eiffel developers use inheritance sparingly. Composition is the primary form of reuse. Don. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Don Harrison donh@syd.csa.com.au