* Re: Is ADA as good for graphics programming as C? @ 1997-07-21 0:00 Ell 0 siblings, 0 replies; 6+ messages in thread From: Ell @ 1997-07-21 0:00 UTC (permalink / raw) Douglas A. Gwyn (gwyn@ix.netcom.com) wrote: : : Matthew Heaney <mheaney@ni.net> wrote in article : > : > Nature (interpret that to mean God, if that suits you) has : > chosen aggregation as the essential means of systems construction. : I think rather, many natural phenomena are *understood by humans* : via analysis as aggregative "systems". I think that aggregation can be shown to exist objectively. Aggregation, objects, and systems are not simply a matter of human cognition. : One can identify aspects of : nature that do not fit that mold, That doesn't mean aggregation doesn't exist objectively. : > 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! But often one or more aspects of one aggregate are passed on to another aggregate - inheritance. Elliott -- "The domain object model is the foundation of OOD." "We should seek out proven optimal practices and use them." ~~ The writer ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Is ADA as good for graphics programming as C? @ 1997-07-21 0:00 Ell 1997-07-21 0:00 ` Jon S Anthony 0 siblings, 1 reply; 6+ messages in thread From: Ell @ 1997-07-21 0:00 UTC (permalink / raw) Jon S Anthony (jsa@alexandria.organon.com) wrote: : : "Douglas A. Gwyn" <gwyn@ix.netcom.com> writes: : > : > [Don't know] wrote: : > : > > 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! : > That's not at all true. In the course of engineering, there is : > normally a vast amount of inheritance going into systems design. : > What is inherited is often a model for the general class of the : > particular product, and the less original the designer, the more : > this shows. For example, automobiles pretty much all look alike, : > and when a new one is designed they don't really start with a : > totally clean slate. I doubt that assumptions such as "has 4 : > wheels" are reexamined; they are merely inherited. : This is _not_ in any way shape or form anything like the sort of : "inheritance" codified and directly expressed in typical OOPLs. What : you mention above is "genealogy style inheritance". So, while there : is definitely truth in what you say, it is irrelevant to the topic at : hand. I do not see how it's so different. One class inheriting from another is actually one generalization being inherited from another. In biology it's not ideas that are inherited, but genes. The notion of passing on is common to both forms of inheritance. Elliott -- "The domain object model is the foundation of OOD." "We should seek out proven optimal practices and use them." ~~ The writer ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Is ADA as good for graphics programming as C? 1997-07-21 0:00 Ell @ 1997-07-21 0:00 ` Jon S Anthony 0 siblings, 0 replies; 6+ messages in thread From: Jon S Anthony @ 1997-07-21 0:00 UTC (permalink / raw) In article <5r089l$g1i$1@news2.digex.net> ell@access5.digex.net (Ell) writes: > Jon S Anthony (jsa@alexandria.organon.com) wrote: ... > : This is _not_ in any way shape or form anything like the sort of > : "inheritance" codified and directly expressed in typical OOPLs. What > : you mention above is "genealogy style inheritance". So, while there > : is definitely truth in what you say, it is irrelevant to the topic at > : hand. > > I do not see how it's so different. Somehow I don't find that surprising... > One class inheriting from another is actually one generalization > being inherited from another. In biology it's not ideas that are > inherited, but genes. The notion of passing on is common to both > forms of inheritance. The semantics of the information "transfer" and even what is "transfered are totally different. /Jon -- Jon Anthony OMI, Belmont, MA 02178 617.484.3383 "Nightmares - Ha! The way my life's been going lately, Who'd notice?" -- Londo Mollari ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)
@ 1997-07-15 0:00 Matthew Heaney
1997-07-16 0:00 ` Don Harrison
0 siblings, 1 reply; 6+ messages in thread
From: Matthew Heaney @ 1997-07-15 0:00 UTC (permalink / raw)
In article <EDAsu7.MLn@syd.csa.com.au>, 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.
As system builders, especially as builders of software systems, we always
have to be concerned with keeping things simple. The language designer
must balance expressiveness of the language against inclusion of yet more
features.
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? Should one reject Ada out of hand, because
mixin inheritance in Ada using generics is "inelegant" compared to using
multiple inheritence in Eiffel?
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? Is the
mechanism used to implement mixin inheritance so important that those other
features aren't significant?
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.
<http://www.acm.org/sigada>
Matt
--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) 1997-07-15 0:00 Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) Matthew Heaney @ 1997-07-16 0:00 ` Don Harrison 1997-07-17 0:00 ` Matthew Heaney 0 siblings, 1 reply; 6+ messages in thread From: Don Harrison @ 1997-07-16 0:00 UTC (permalink / raw) Matt Heaney wrote: :In article <EDAsu7.MLn@syd.csa.com.au>, 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. : :<http://www.acm.org/sigada> Thanks for the reference. If I get a chance, I'll take a look. Don. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Don Harrison donh@syd.csa.com.au ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) 1997-07-16 0:00 ` Don Harrison @ 1997-07-17 0:00 ` Matthew Heaney [not found] ` <01bc94e1$46912100$53aa20cc@default> 0 siblings, 1 reply; 6+ messages in thread From: Matthew Heaney @ 1997-07-17 0:00 UTC (permalink / raw) In article <EDEDB3.8rv@syd.csa.com.au>, donh@syd.csa.com.au wrote: >: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. You've fallen into a common trap, Don. You think that beauty and elegance exist independent of human perception; this is, of course, incorrect. 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 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...). 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. 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. 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. 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. 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. If these concepts are alien to you, then I suggest you study up on systems thinking. It'll make you a much better systems designer. Here's a couple of books to read The Blind Watchmaker Richard Dawkins W.W.Norton ISBN 0-393-30448-5 Dealing with Complexity Robert Flood and Ewart Carson Plenum Press ISBN 0-306-44299-X You may also want to take a gander at Capra's new book The Web of Life Fritjof Capra Anchor Books (Doubleday) 0-385-47675-2 >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. I think we're both in agreement here. >: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! Imagine that! 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! How is this even possible? the dear Eiffel reader must be wondering. 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_. So why build software systems any differently? 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) If neither I nor Jean-Pierre can convince you of the efficacy of aggregation over inheritence, then perhaps these authors can: Hierarchically Organized Systems In Theory & Practice Paul Weiss Theory of Hierarchical, Multilevel Systems Mesarovic, Macko, Takahara Hierarchical Structures Whyte, Wilson, and Wilson Hierarchy Theory Howard Pattee And by all means read the chapter The Architecture of Complexity, in The Sciences of the Artificial Herbert Simon which just came out in a brand spankin' new 3rd ed. (Oh, Herb won a Nobel prize, by the way.) 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 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. 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. 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). Suppose we need to write a disk controller. We manipulate the disk through a disk control block, located at memory address (octal) 77430. The block comprises 2 16 bit words: the function code and some status bits are located in upper byte of the first word, and the disk address is the second word, ie type Function_Code is (Read, Write, Write_With_Check, Seek); for Function_Code use (Read => 2#0000#, Write => 2#0010#, Write_With_Check => 2#0100#, Seek => 2#1000#); for Function_Code'Size use 4; type Disk_Control_Block is record Code : Function_Code; Write_Not_Permitted : Boolean; Disk_Busy : Boolean; Disk_Off_Line : Boolean; Disk_Address : Interfaces.Unsigned_16; end record; for Disk_Control_Block use record Code at 0 range 0 .. 3; Write_Not_Permitted at 0 range 5 .. 5; Disk_Busy at 0 range 6 .. 6; Disk_Off_Line at 0 range 7 .. 7; Disk_Address at 2 range 0 .. 15; end record; for Disk_Control_Block'Size 32; Control_Block : Disk_Control_Block; for Control_Block'Address use 8#77430#; Now, what were you saying about not be able to model the problem directly? -------------------------------------------------------------------- Matthew Heaney Software Development Consultant <mailto:matthew_heaney@acm.org> (818) 985-1271 ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <01bc94e1$46912100$53aa20cc@default>]
* Re: Is ADA as good for graphics programming as C? [not found] ` <01bc94e1$46912100$53aa20cc@default> @ 1997-07-20 0:00 ` Matthew Heaney 1997-07-21 0:00 ` Dennis Weldy 1997-07-21 0:00 ` Jon S Anthony 1 sibling, 1 reply; 6+ messages in thread From: Matthew Heaney @ 1997-07-20 0:00 UTC (permalink / raw) In article <01bc94e1$46912100$53aa20cc@default>, "Douglas A. Gwyn" <DAGwyn@null.net> wrote: >By the way, I am not taking sides in the subject debate, other than to >point out that the choice of language may often be rationally influenced >by factors other than purely linguistic considerations. For example, Ada >might be chosen by a DoD embedded systems provider simply because >getting a waiver is too difficult, while C might be chosen for another >project >simply because C compilers and programmers are easier to obtain. First of all, there is no waiver policy, because there is no mandate. Ada is a good enough language that it doesn't require one. Read Emmett Page's Official Letter: <http://sw-eng.falls-church.va.us/AdaIC/pol-hist/oasd497.shtml> Second of all, Ada might be chosen by a DoD embedded systems provider because the developers think it is the best language for the job, not because they are required to use Ada (which they aren't). Indeed, many commercial organizations use Ada, by choice. -------------------------------------------------------------------- Matthew Heaney Software Development Consultant <mailto:matthew_heaney@acm.org> (818) 985-1271 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Is ADA as good for graphics programming as C? 1997-07-20 0:00 ` Is ADA as good for graphics programming as C? Matthew Heaney @ 1997-07-21 0:00 ` Dennis Weldy 0 siblings, 0 replies; 6+ messages in thread From: Dennis Weldy @ 1997-07-21 0:00 UTC (permalink / raw) Thats not quite correct. There WAS a mandate, and you DID have to get a waiver to use non-ada code. When I was working for a defense contractor on a network-simulation project, we had to get a waiver because the proect was not going to be done in Ada,rather, Pascal. Recently, they've done away with the mandates and waivers, but they existed for a long time. Dennis Matthew Heaney wrote in article ... >In article <01bc94e1$46912100$53aa20cc@default>, "Douglas A. Gwyn" ><DAGwyn@null.net> wrote: > >>By the way, I am not taking sides in the subject debate, other than to >>point out that the choice of language may often be rationally influenced >>by factors other than purely linguistic considerations. For example, Ada >>might be chosen by a DoD embedded systems provider simply because >>getting a waiver is too difficult, while C might be chosen for another >>project >>simply because C compilers and programmers are easier to obtain. > >First of all, there is no waiver policy, because there is no mandate. Ada >is a good enough language that it doesn't require one. > >Read Emmett Page's Official Letter: > ><http://sw-eng.falls-church.va.us/AdaIC/pol-hist/oasd497.shtml> > >Second of all, Ada might be chosen by a DoD embedded systems provider >because the developers think it is the best language for the job, not >because they are required to use Ada (which they aren't). Indeed, many >commercial organizations use Ada, by choice. > >-------------------------------------------------------------------- >Matthew Heaney >Software Development Consultant ><mailto:matthew_heaney@acm.org> >(818) 985-1271 >. > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Is ADA as good for graphics programming as C? [not found] ` <01bc94e1$46912100$53aa20cc@default> 1997-07-20 0:00 ` Is ADA as good for graphics programming as C? Matthew Heaney @ 1997-07-21 0:00 ` Jon S Anthony 1 sibling, 0 replies; 6+ messages in thread From: Jon S Anthony @ 1997-07-21 0:00 UTC (permalink / raw) In article <01bc94e1$46912100$53aa20cc@default> "Douglas A. Gwyn" <gwyn@ix.netcom.com> writes: > > 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! > > That's not at all true. In the course of engineering, there is > normally a vast amount of inheritance going into systems design. > What is inherited is often a model for the general class of the > particular product, and the less original the designer, the more > this shows. For example, automobiles pretty much all look alike, > and when a new one is designed they don't really start with a > totally clean slate. I doubt that assumptions such as "has 4 > wheels" are reexamined; they are merely inherited. This is _not_ in any way shape or form anything like the sort of "inheritance" codified and directly expressed in typical OOPLs. What you mention above is "genealogy style inheritance". So, while there is definitely truth in what you say, it is irrelevant to the topic at hand. /Jon -- Jon Anthony OMI, Belmont, MA 02178 617.484.3383 "Nightmares - Ha! The way my life's been going lately, Who'd notice?" -- Londo Mollari ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~1997-07-21 0:00 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1997-07-21 0:00 Is ADA as good for graphics programming as C? Ell -- strict thread matches above, loose matches on Subject: below -- 1997-07-21 0:00 Ell 1997-07-21 0:00 ` Jon S Anthony 1997-07-15 0:00 Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) Matthew Heaney 1997-07-16 0:00 ` Don Harrison 1997-07-17 0:00 ` Matthew Heaney [not found] ` <01bc94e1$46912100$53aa20cc@default> 1997-07-20 0:00 ` Is ADA as good for graphics programming as C? Matthew Heaney 1997-07-21 0:00 ` Dennis Weldy 1997-07-21 0:00 ` Jon S Anthony
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox