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: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public X-Google-Thread: 1014db,3d3f20d31be1c33a X-Google-Attributes: gid1014db,public X-Google-Thread: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public From: donh@syd.csa.com.au (Don Harrison) Subject: Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) Date: 1997/07/16 Message-ID: X-Deja-AN: 257155183 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-16T00:00:00+00:00 List-Id: Matt Heaney wrote: :In article , donh@syd.csa.com.au wrote: : :>Yes, through a round-about way using genericity. This is inelegant compared :>with multiple inheritance. However, it's simple compared to the obscure :>technique for acheiving multiple views in Ada95 Rationale, Section 4.6.3. :>I'm still trying to comprehend that one! : :Be careful bandying about terms like "more elegant" and "less pure." Those :are concepts invented by humans to convey an idea to another human. Nature :doesn't care about what is more or less elegant, she only cares about what :works and what doesn't. 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. IMO, it's software users that don't care about elegance and purity but only inasmuch as it doesn't affect them. That is, they couldn't care less if software is inelegant under-the-covers so long as it works and is easy to use. Unfortunately, what's more likely is that it won't work and won't be easy to use if it's design is complex - a poor designer doesn't radically change the way they do things when they come to the GUI and complexity tends to compromise reliability. :As system builders, especially as builders of software systems, we always :have to be concerned with keeping things simple. I agree. :The language designer :must balance expressiveness of the language against inclusion of yet more :features. I tend to think there are good and bad ways of delivering functionality - see below... :Does the putative "elegance" of the MI solution outweigh the language :complexity that would result had MI been included in Ada? Doesn't :simplicity count for something? Yes, it counts for a lot. However, I think it's helpful to recognise the relative complexity engendered by the two primary means of delivering functionality - language mechanisms and libraries. The former increases overall complexity more than the latter because language features interact with each other *non-orthogonality* and libraries are *standalone*. Also, I think we need to distinguish between *actual* and *perceived* orthogonality. A naive user, for example, may perceive a language such as Ada to be more complex than it actually is simply because they don't know what is orthogonal and what isn't. As an example of the standalone complexity of libraries (strictly in Ada it's optional language and libraries), Ada is not made more complex for a realtime user due to the existence of an Information Systems Annexe because it's immediately obvious from the fact that it's optional that it doesn't concern them. The same can't be said of language mechanisms whose orthogonality is recognised more through use rather than immediate comprehension. Most humans can only grasp a handful of concepts at a time so it's asking too much of them to immediately comprehend which of a multitude of language mechanisms are independent of each other. Obviously, the fewer there are, the less there is to learn and the quicker you will master the language. I doubt anyone would disagree that Annexes are a good idea. Minimalist languages (such as Eiffel) take this principle further by placing as much functionality as possible in "Annexes" (called libraries in Eiffel). In this way, the basic functionality of the language is reused heavily to provide other functionality. The analogy on the back of "Eiffel The Language" (ETL) is very apt: "Eiffel has been called a 'RISC language'". Some examples of this reuse which contrast with Ada are: - Implementation of basic types as classes. - Implementation of parts of the exception facilities as a class. - Implementation of various aspects of concurrency (timed interrupts, coroutines etc.) as classes. The more functionality you can implement in standalone libraries, the simpler the language itself becomes. A rough measure of that complexity is language validity rules. Eiffel only has about 81 including SCOOP. How many does Ada95 have? (I mean the number of distinct RM references which an Ada compiler can spit out) I've roughly estimated about 2400 - I can't tell for sure because the Librarian has annexed my copy of the LRM. This difference translates fairly directly into how complex the language is perceived to be, especially to a beginner. In the specific case of MI, I think it's such a useful modelling tool as to warrant its inclusion in the language itself if that will make it easier to use (which I think it does). :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. :Isn't it possible that there are other features of Ada, that allow some :things to be done more easily or more elegantly than in Eiffel? Sure. Low-level facilities may be one such area. But, IME, it's typically the other way round. :Is the :mechanism used to implement mixin inheritance so important that those other :features aren't significant? I think they're likely to be orthogonal wrt MI. :The multiple view technique is an admittedly difficult idiom to understand :- at first. But once apprehended, it makes perfect sense, and isn't hard :to do. You get multiple views for free, because it builds on existing :language mechanisms, and it very nearly gives you what you get in MI, :without requiring that MI be part of the language. : :You may want to study my discussion of the Adapter pattern in the SIGAda :patterns WG archives, where I specifically discuss and give code examples :of the multiple views technique. : : Thanks for the reference. If I get a chance, I'll take a look. Don. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Don Harrison donh@syd.csa.com.au