* Inheritance versus Generics @ 1997-04-24 0:00 Craig Smith 1997-04-25 0:00 ` Robert Dewar ` (5 more replies) 0 siblings, 6 replies; 28+ messages in thread From: Craig Smith @ 1997-04-24 0:00 UTC (permalink / raw) Generics were a very power feature of Ada-83. With the OO features introduced into Ada-95 (in particuliar, the tagged record and ability to inherit), are Generics obsolute? I would guess since several features were added to generics (like generic formal package parameters), the answer is no. Does anyone have any thoughts on this? Craig D. Smith ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Inheritance versus Generics 1997-04-24 0:00 Inheritance versus Generics Craig Smith @ 1997-04-25 0:00 ` Robert Dewar 1997-04-25 0:00 ` Michael F Brenner 1997-04-26 0:00 ` Michael Feldman 1997-04-25 0:00 ` Lionel Draghi ` (4 subsequent siblings) 5 siblings, 2 replies; 28+ messages in thread From: Robert Dewar @ 1997-04-25 0:00 UTC (permalink / raw) Craig Smith asks <<Generics were a very power feature of Ada-83. With the OO features introduced into Ada-95 (in particuliar, the tagged record and ability to inherit), are Generics obsolute? I would guess since several features were added to generics (like generic formal package parameters), the answer is no. Does anyone have any thoughts on this?>> One group that has thoughts on this is the C++ design committee. Originally the attempt was to develop OO stuff, and decide that genericity was not needed, but eventually it was clear that this was over-restrictive, and so genericity (templates) was added. Note that the Ada 83 design is an interesting dual. The Ada 83 design committee was well aware of the object oriented approach (many of them had been using Simula-67 for over a decade -- it is well to remember that the basic OO idea are ancient). Their experience said that writing large scale programs using the OO approach was ineffective, and they very conciously decided against incorporating such features into Ada 83, deciding that the same basic functionality could be achieved in a language that concentrated on providing powerful genericty. Now at least in some sense, Ada 95, shows the same phenomenon as C++, in deciding that both are necessary. However, the situation in the Ada 95 case is a little more clouded, since the basic motivation for adding OO stuff was not purely technial, but the decision was largely driven by "following the trend" fadism. Only time will tell the full story here ... A lot of people find genericity to be much more significant than OO stuff (a good example of this is the designers of the standard template library in C++, which uses genericity extnsively, but inheritance barely at all. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Inheritance versus Generics 1997-04-25 0:00 ` Robert Dewar @ 1997-04-25 0:00 ` Michael F Brenner 1997-04-25 0:00 ` Robert Dewar 1997-04-26 0:00 ` Michael Feldman 1 sibling, 1 reply; 28+ messages in thread From: Michael F Brenner @ 1997-04-25 0:00 UTC (permalink / raw) Robert said: > The Ada 83 design > committee was well aware of the object oriented approach (many of them > had been using Simula-67 for over a decade -- it is well to remember > that the basic OO idea are ancient). Their experience said that writing > large scale programs using the OO approach was ineffective, and they > very conciously decided against incorporating such features into Ada 83, > deciding that the same basic functionality could be achieved in a > language that concentrated on providing powerful genericty. May I add that the same functionality would have been achieved had packages been either first class (makable into arrays) or second class (passable as generic parameters) objects. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Inheritance versus Generics 1997-04-25 0:00 ` Michael F Brenner @ 1997-04-25 0:00 ` Robert Dewar 1997-04-27 0:00 ` Nick Roberts 1997-04-29 0:00 ` Mats Weber 0 siblings, 2 replies; 28+ messages in thread From: Robert Dewar @ 1997-04-25 0:00 UTC (permalink / raw) Michael said <<May I add that the same functionality would have been achieved had packages been either first class (makable into arrays) or second class (passable as generic parameters) objects.>> I assume you are aware of all the subtle semantic problems in doing this. This is an issue that has been discussed very extensively during the design process, and the issues are well known and well understood, and the consensus was that package types are simply too much additional complexity ... ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Inheritance versus Generics 1997-04-25 0:00 ` Robert Dewar @ 1997-04-27 0:00 ` Nick Roberts 1997-04-29 0:00 ` Michael F Brenner 1997-04-29 0:00 ` Mats Weber 1 sibling, 1 reply; 28+ messages in thread From: Nick Roberts @ 1997-04-27 0:00 UTC (permalink / raw) Surely the most fundamental capability introduced by the O. O. features of Ada 95 is dynamic dispatching. Is there a viable alternative way to provide the same functionality? Also, fill me in a little on the idea of arrays of packages, please. This seems like a weird concept to li'l ol' me (but interesting). Nick. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Inheritance versus Generics 1997-04-27 0:00 ` Nick Roberts @ 1997-04-29 0:00 ` Michael F Brenner 1997-05-02 0:00 ` Nick Roberts 1997-05-02 0:00 ` John G. Volan 0 siblings, 2 replies; 28+ messages in thread From: Michael F Brenner @ 1997-04-29 0:00 UTC (permalink / raw) Nick said > Fill me in on arrays of packages Arrays of packages are what is missing in Ada-95 for packages to act as objects. For example, in any generic instantiation which creates an ADO (abstract data object), you can use object oriented notation to access the methods (package.method is identical to object.method in this case. ) However, in the case of an ADT (abstract data type), the package permits you to create a type (class) from which objects are then created. In this case package.method is not equal to object.method; instead, you need to say package.method (object). This partial inversion of the notation (object.method in ADOs versus package.method for ADTs) results in many anomalies, such as most existing generic code being ADOs, to make the objects LOOK like objects. BTW, this method of grouping methods with the object not only preceeds the great object-oriented languages such as smalltalk, Ada-95, and Java, but also predates computer science. For example, category theory, abstract algebra, and discrete mathematics have all grouped the methods with the objects, rather than using a structured programming approach with a top-down design. Mathematicians have followed the best of the object-oriented philosophy (design bottom up, relating the methods to the objecs) but describe that design top down in a logical manner. Making arrays of objects AS Packages would make packages into what is called First Class Objects. This is not politically feasible given the beliefs of the people who get to vote on this. However, making the packages second class objects, that is permitting passing of packages (non-generic) to packages adds no new problems; it only suffers from the same things that any other form of multiple inheritance suffers from. For example, if we have a double linked list package and a scheduling package and a 3d transformation package, there are severe limitations to our ability to make linked lists of scheduled transformation. We basically have to create each level of intermediate object MANUALLY, inducing the comcomitant bugs, and imbuing the source code with lines of code which packages as second class objects would obviate. When you have existing packages and you know how you would like to parameterize them, it would be nice if Ada-2005 would permit you to do it. The type of problem we are trying to solve in this discussion is the classical case of multiple back ends for a single visible part. With external file systems and configuration management tools, we can have multiple back ends. However, within the Ada language, we can only do this if we have a single level of inheritance (or if we manually create the intermediate record types which, as said above, is error-prone). If packages were second class objects (passable to packages), then we could re-instantiate new back ends for packates within the language. While not as cool as arrays of packages, it would solve the outstanding issue of programming for multiple backends within the Ada-2005 language. It would NOT require the creation of packages as TYPES, but rather would re-use the concept of abstract packages, and merely relieve the restriction that packages as parameters must be generic. There are problems, yes, and those problems are worth solving, yes. . ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Inheritance versus Generics 1997-04-29 0:00 ` Michael F Brenner @ 1997-05-02 0:00 ` Nick Roberts 1997-05-03 0:00 ` Robert Dewar 1997-05-02 0:00 ` John G. Volan 1 sibling, 1 reply; 28+ messages in thread From: Nick Roberts @ 1997-05-02 0:00 UTC (permalink / raw) Michael F Brenner <mfb@mbunix.mitre.org> wrote in article <5k5suu$bhj@top.mitre.org> an excellent article about arrays of packages, and packages as First Class Objects. Many thanks, Michael. I would wholeheartedly agree that it is a great pity that Ada 95 did not include some sort of facility for the dynamic manipulation of package binding. Naturally, this facility would imply a variety of implementation difficulties. It would be difficult (or impossible) to implement dynamically bindable packages as efficiently as statically bound ones. Nevertheless, the speed penalty would, in many cases, be acceptable, and the advantages of such a facility would often be considerable. This may sound surprising, coming from such a technologically conservative person as myself, but I think I would go so far as to say that this is a serious omission, and not one to be lightly brushed aside. Nick. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Inheritance versus Generics 1997-05-02 0:00 ` Nick Roberts @ 1997-05-03 0:00 ` Robert Dewar 0 siblings, 0 replies; 28+ messages in thread From: Robert Dewar @ 1997-05-03 0:00 UTC (permalink / raw) Nick said <<This may sound surprising, coming from such a technologically conservative person as myself, but I think I would go so far as to say that this is a serious omission, and not one to be lightly brushed aside.>> Actually the light brushing here seems to be more on your side. Yes, the idea of making packages first class is superficially appealing, and it certainly was not "lighly brushed aside", but was on the contrary carefully examined over a long period of time by a lot of people. In the light of that discussion, the great majority of the DR's (really everyone except Tony Luckham, who subsequently dropped out) decided that the added complexity was not worth the functoinality, which we felt could be adfequately obtained in other ways without introducing as much complexity. So you may or may not agree with this, but should probably examine the issue in more detail. it is a deep one! ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Inheritance versus Generics 1997-04-29 0:00 ` Michael F Brenner 1997-05-02 0:00 ` Nick Roberts @ 1997-05-02 0:00 ` John G. Volan 1 sibling, 0 replies; 28+ messages in thread From: John G. Volan @ 1997-05-02 0:00 UTC (permalink / raw) Michael F Brenner wrote: > Arrays of packages are what is missing in Ada-95 for packages to > act as objects. I must admit that I find this whole discussion of packages as first- or second- class objects somewhat confusing. I don't quite see what they buy you that isn't already supported by tagged record types and generics. Michael, it might be helpful if you could post a "code" example that showed what you had in mind for the syntax and semantics of these beasts. :-) Then either someone could show you that what you want can actually be done in Ada95, or else you could make it clear what is missing. > For example, in any generic instantiation which > creates an ADO (abstract data object), you can use object oriented > notation to access the methods (package.method is identical to > object.method in this case. ) However, in the case of an ADT (abstract > data type), the package permits you to create a type (class) from > which objects are then created. In this case package.method is not > equal to object.method; instead, you need to say package.method (object). > This partial inversion of the notation (object.method in ADOs versus > package.method for ADTs) results in many anomalies, such as most > existing generic code being ADOs, to make the objects LOOK like objects. Sigh ... is this just a religious issue over cosmetics? Why so much bitterness over superficial syntactic differences? Isn't it plain that there's a _semantic_ homomorphism between these two notations: controlling parameter (target) distinguished by type analysis (doesn't necessarily have to be first) | | scope.method (target, parameters); -- Ada95: scope = package | -- "scope." can be omitted | -- after a "use" period as scope delimiter double-colon as scope operator | | target.scope::method (parameters); // C++: scope == class | // "scope::" can be omitted | // anytime controlling parameter (target) distinguished by period syntax Can you not see how parochial your interpretation of the period character (.) is? An analogy: In the United States, we write out numbers thus: "123,456.789". In some countries in Europe, the same number might be written thus: "123.456,789". A telephone number in the US is usually written like this: "(800) 555-1212". The same number might be written in Europe as: "800.555.1212". Does anyone have a problem with this? _I_ sure don't. I can figure out what is meant either way. > BTW, this method of grouping methods with the object not only preceeds > the great object-oriented languages such as smalltalk, Ada-95, and Java, What about Common Lisp? A very object-oriented language indeed, and yet it manages to do this without changing the old Lisp syntax: (method target parameters) ;; controlling parameter doesn't ;; necessarily have to be first > but also predates computer science. For example, category theory, > abstract algebra, and discrete mathematics have all grouped the methods > with the objects, Mathematics groups methods with _objects_? Or does it group methods with _types_? What do you mean by "grouping"? An Ada95 package can declare a type and its associated primitive subprograms together. In fact, that's what defines those subprograms as "primitive" -- their co-location in the same package spec with the type. In what way does this fail to achieve the "grouping" you seek? Why do I suspect that it won't count as "grouping" unless it is attended with the "politicially correct" syntactic sugar? > rather than using a structured programming approach > with a top-down design. What does this have to do with Ada95? Are you somehow insinuating that Ada95 packages cannot support any notion other than top-down structured design? Surely you can't mean that, given the overwhelming evidence to the contrary! > Mathematicians have followed the best of the > object-oriented philosophy (design bottom up, relating the methods to > the objecs) but describe that design top down in a logical manner. > > Making arrays of objects AS Packages would make packages into what is > called First Class Objects. This is not politically feasible given the > beliefs of the people who get to vote on this. Sounds like sour grapes to me. I do remember seeing something about package types way back when during the Ada9X process. I bet they were discussed seriously and extensively. But, as we all know, a different solution was chosen instead. It is my belief that the current solution can be shown to be _semantically homomorphic_ to whatever it is that you want, but it will take a concrete example to demonstrate that. > However, making the > packages second class objects, that is permitting passing of packages > (non-generic) to packages adds no new problems; it only suffers from > the same things that any other form of multiple inheritance suffers > from. Interesting. How would your package-passing concept create "multiple inheritance"? And why do you think multiple inheritance is what you need to solve the kind of problem you describe, anyway? MI is not the only technique for flexibly composing abstractions. Sounds like a case of "hammer syndrome" to me (that's where every problem looks like a nail). > For example, if we have a double linked list package and > a scheduling package and a 3d transformation package, there are > severe limitations to our ability to make linked lists of scheduled > transformation. Interesting. It seems to me that something like this _can_ be achieved with tagged types, combined with generics. Let's see this example fleshed out a bit, then we can talk. > We basically have to create each level of intermediate > object MANUALLY, inducing the comcomitant bugs, and imbuing the source > code with lines of code which packages as second class objects > would obviate. When you have existing packages and you know how > you would like to parameterize them, it would be nice if Ada-2005 > would permit you to do it. The type of problem we are trying to > solve in this discussion is the classical case of multiple > back ends for a single visible part. Why can't this be achieved using an abstract tagged type with multiple concrete derived types and classwide programming? > With external file systems > and configuration management tools, we can have multiple back ends. > However, within the Ada language, we can only do this if we have > a single level of inheritance (or if we manually create the > intermediate record types which, as said above, is error-prone). Interesting. Again, a fleshed out example might be instructive. > If packages were second class objects (passable to packages), then > we could re-instantiate new back ends for packates within the > language. While not as cool as arrays of packages, it would solve > the outstanding issue of programming for multiple backends within > the Ada-2005 language. It would NOT require the creation of packages > as TYPES, but rather would re-use the concept of abstract packages, > and merely relieve the restriction that packages as parameters must > be generic. There are problems, yes, and those problems are worth > solving, yes. Well, maybe they've _already_ been solved... ------------------------------------------------------------------------ Internet.Usenet.Put_Signature (Name => "John G. Volan", Home_Email => "johnvolan@sprintmail.com", Slogan => "Ada95: The World's *FIRST* International-Standard OOPL", Disclaimer => "These opinions were never defined, so using them " & "would be erroneous...or is that just nondeterministic now? :-) "); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Inheritance versus Generics 1997-04-25 0:00 ` Robert Dewar 1997-04-27 0:00 ` Nick Roberts @ 1997-04-29 0:00 ` Mats Weber 1997-05-01 0:00 ` Robert Dewar 1 sibling, 1 reply; 28+ messages in thread From: Mats Weber @ 1997-04-29 0:00 UTC (permalink / raw) Robert Dewar wrote: > > Michael said > > <<May I add that the same functionality would have been achieved had packages > been either first class (makable into arrays) or second class (passable > as generic parameters) objects.>> > > I assume you are aware of all the subtle semantic problems in doing this. > This is an issue that has been discussed very extensively during the > design process, and the issues are well known and well understood, and > the consensus was that package types are simply too much additional > complexity ... I have done some extensive work on that topic (package types as classes), and I disagree. You can find my proposal at <http://lglwww.epfl.ch/Team/MW/Ada-Extensions/Ada-Extensions.html> On the other hand, I would be very interested in knowing the arguments that lead to the consensus that rejected package types. Is there a paper, report, or anything ? ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Inheritance versus Generics 1997-04-29 0:00 ` Mats Weber @ 1997-05-01 0:00 ` Robert Dewar 0 siblings, 0 replies; 28+ messages in thread From: Robert Dewar @ 1997-05-01 0:00 UTC (permalink / raw) Mats said, replying to me <<> I assume you are aware of all the subtle semantic problems in doing this. > This is an issue that has been discussed very extensively during the > design process, and the issues are well known and well understood, and > the consensus was that package types are simply too much additional > complexity ... I have done some extensive work on that topic (package types as classes), and I disagree. You can find my proposal at <http://lglwww.epfl.ch/Team/MW/Ada-Extensions/Ada-Extensions.html>>>> I think your language is a little imprecise here, I think you are saying that you disagree with the consensus, not that anything I said is wrong (this issue WAS debated extensively -- extensively enough that I certainly don't feel like any more technical talk on it :-) -- and there was a consensus that it was a bad idea. Sure there is a small (very noisy :-) minority that disagreed, but it was a very small minority (the notable member of this minority was Tony Luckham, if you want to track down a kindred spirit on this issue). (and of course there was the Intel compiler ...) ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Inheritance versus Generics 1997-04-25 0:00 ` Robert Dewar 1997-04-25 0:00 ` Michael F Brenner @ 1997-04-26 0:00 ` Michael Feldman 1 sibling, 0 replies; 28+ messages in thread From: Michael Feldman @ 1997-04-26 0:00 UTC (permalink / raw) A Few "Sound Bites" on Object-Oriented Programming Michael B. Feldman The George Washington University ------------------------------------------------------------- "My guess is that object-oriented programming will be in the 1980s what structured programming was in the 1970s. Everyone will be in favor of it. Every manufacturer will promote his products as supporting it. Every manager will pay lip service to it. Every programmer will practice it (differently). And no one will know just what it is." Tim Rentsch 1982 (one of the original Xerox Smalltalkers) (as quoted by Booch) ------------------------------------------------------------- "Everything is an object these days; if it doesn't have o-b-j-e-c-t in the name, it won't sell...OOT is so radically different that we must break and reset programmers' coding hands before they can write object-oriented instead of procedural programs. This is much worse than the structured programming hoopla of the 1970s...If we convert one Cobol programmer per minute to Smalltalk, we should have a revolution by the time Capt. Kirk and the USS Enterprise return from Vulca on impulse power." Ted Lewis, "The Dark Side of Objects", IEEE Computer, Dec. 1994. ------------------------------------------------------------- Composition vs. Classification (paraphrasing here) Objects gather both data structures and program structures. Classification: objects are organized in a hierarchy of classes. General classes contain features common to many subclasses, and specalized subclasses implement only behaviors that are common to a subset of the parent class's objects. Composition: objects are made of different parts, and that the same parts can be used to make a variety of higher-level objects. Each object is designed as an assembly of lower-level components. There is no need to know how a component is made in order to use it. A set of parts that form an object constitutes an abstraction layer. This is what is generally used in engineering, and has been especially successful in the electronic industry. (quoting directly here) "Why do so many people believe that classification is the only 'true' object orientation? Perhaps because OOL designers place a heavy emphasis on inheritance, which is clearly necessary only to classification." J-P Rosen, "What Orientation Should Ada Objects Take?" Communications of the ACM, Nov. 1992 ------------------------------------------------------------- "There is a very real tension between inheritance and encapsulation. To a large degree, the use of inheritance exposes some of the secrets of an inherited class. Practically, this means that to understand the meaning of a particular class, you must often study all of its superclasses, sometimes including their inside views." Grady Booch, Object-Oriented Design with Applications, Benjamin Cummings, 1991. ------------------------------------------------------------- "OOT has a nasty 'fragile base class problem,' which means that once a program is designed and implemented as a class hierarchy, it is maximally coupled. Changing one interface specification brings the whole house of cards tumbling down. We were warned against this in 1975 (minimize coupling, maximize cohesion). Coupling is a serious maintenance nightmare that bit Mentor Graphics (Falcon Framework) in the bottom line. How many other software companies are headed for OOT malaise?" Lewis, op. cit. ------------------------------------------------------------- "[I]nheritance is often used not for classification, but just to grab pieces of code. . .makes a class PARROT inherit from the class HUMAN-BEING because it needs the property CAN-SPEAK. This kind of misuse of the inheritance mechanism, especially when multiple inheritance is available, is extremely tempting to the programmer who just wants to 'reuse' existing code, while actually introducing a terrible mess in the dependencies between objects. ... "In the slums, people build houses by reusing old items such as pieces of wood and tires, and adjusting them to their needs. This kind of reuse is often extremely clever, and if you absoutely need a shelter rapidly, it is certainly an efficient method. But will the house withstand a storm? This is certainly not industrial reuse, which is building houses from well-engineered, standard prefabricated components. ... "Ada object orientation will still not just follow classification, because classification does not answer properly a number of requirements for Ada applications. In general, classification will favor ease of design and rapidly varying specifications such as those encountered when prototyping software, while composition will better match the needs of secure, long-lasting systems, requiring various implementations of the same abstract behavior." J-P Rosen, op. cit. ------------------------------------------------------------- "-- Most past progress in software productivity has come from eliminating non-inherent difficulties such as awkward machine languages and slow batch turnaround. "-- There are not a lot more of these easy pickings. "-- Radical progress is going to have to come from attacking the essential difficulties of fashioning complex conceptual constructs. "The most obvious way to do this recognizes that programs are made up of conceptual chunks much larger than the individual high-level language statement -- subroutines, or modules, or classes. If we can limit design and building so that we only do the putting together and parameterization of such chunks from prebuilt collections, we have radically raised the conceptual level, and eliminated the vast amounts of work and the copious opportunities for error that dwell at the individual statement level. "Parnas's information-hiding definition of modules is the first published step in that crucially important research program, and it is an intellectlual ancestor of object-oriented programming He defined a module as a software entity with its own data model and its own set of operations. Its data can only be accessed via one of its proper operations. "The second step was a contribution of several thinkers: the upgrading of the Parnas module into an abstract data type, from which many objects could be derived. The abstract data type provides a uniform way of thinking about and specifying module interfaces, and an access discipline that is easy to enforce. "The third step, object-oriented programming, introduces the powerful concept of inheritance, whereby classes (data types) take as defaults specified attributes of their ancestors in the class hierarchy. Most of what we hope to gain from object-oriented programming derives in fact from the first step, module encapsulation, plus the idea of prebuilt libraries or modules or classes that are designed and tested for reuse." Fred Brooks, "The Mythical Man-Month after 20 Years", IEEE Computer, Sept. 1995. ------------------------------------------------------------- "Unfortunately for the information technology industry, many object technology (OT) gurus are still touting the role of inheritance and subclassing in building reusable business objects. One well-designed parent, they say, such as a Customer object, allows developers to effortlessly spawn dozens of reusable kin. These theories of inheritance sound pretty good-until you try applying them to building an industrial -strength application . "We have spent more than 150 work-years tackling this issue and many others related to building commercial object-oriented systems. The verdict on inheritance and reuse? Uncontrolled and unplanned subclassing results in code as fragile and hard to maintain as the COBOL programs we're replacing. Moreover, subclassing often is counterproductive. Inheritance, by its nature, means changing the objects designed to be reused, which will cancel out any benefits of reuse because each new subclassed object then requires testing, the biggest drag on rapid development. Our internal studies show that as much as 60% of the total implementation effort for a client/server system is spent on testing. "The best approach is to treat inheritance as a power tool for churning out objects when appropriate. Inheritance can give you a boost in programmer productivity, but it won't make possible the high degree of reuse that delivers the vital combinition of speed, agility, and power that today's business systems need. "That's the crucial equation for making information technology work: speed + agility + power. By speed, we mean the overall productivity gains from building applications from a store of reusable objects. Power means using the computer to do things that couldn't be done before-integrating hypertext, graphics, video, and Integrated Performance Support, which transmit more information in new ways to knowledge workers. We use the term "agility" because it conveys much more than "flexibility," a feature of object technology comnioiily associated with ease of maintenance. While flexibility-the system's ability to be adapted to new or changing specs-remains all important goal for software, agility refers to the organization as a whole and its ability to change processes and strategies with the nimbleness of a small company. "To build these types of solutions, look to encapsulation. Encapsulation provides for more useful reuse than inheritance because it reduces testing, not just programming. Encapsulated objects project abstract business traits that make them valuable (and reusable!), rather- than inheriting and propagating inflexible, un-reusable code. Moreover, this approach to reuse adds for more value than inheritance does to object-oriented design because it delivers the agile systems organizations need to support continuous reengineering and capitalize on its benefits-accelerating new services and products to market, increasing responsiveness to customers, and supporting new processes and global operations." Jim Adamczyk and Tom Moldauer (Andersen Consulting) Object Magazine, Sept. 1995 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Inheritance versus Generics 1997-04-24 0:00 Inheritance versus Generics Craig Smith 1997-04-25 0:00 ` Robert Dewar @ 1997-04-25 0:00 ` Lionel Draghi 1997-04-25 0:00 ` Mats Weber ` (3 subsequent siblings) 5 siblings, 0 replies; 28+ messages in thread From: Lionel Draghi @ 1997-04-25 0:00 UTC (permalink / raw) To: cdsmith0 Craig Smith wrote: > > Generics were a very power feature of Ada-83. With the OO features > introduced into Ada-95 (in particuliar, the tagged record and ability to > inherit), are Generics obsolute? ... Clearly not, generics are even used by Ada 95 to provide certain kind of inheritance :-) I think this is a design issue : Inheritance and genericity have different use, and this justify existence of both : - when you need to factorize common "properties" between related object, you should use inheritance, and build classes. - when you need to factorize some algorythm between object possibly without any relation, you should use genericity. Inheritance imply the "is a kind of" relation, Genericity do not. D'accord ou pas? :-) ________________________________________________________________________________ Lionel Draghi 01 45 28 88 50 17, rue Simon Dereure 93 110 Rosny-sous-Bois France http://ada.eu.org/ http://www.adahome.com/ ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Inheritance versus Generics 1997-04-24 0:00 Inheritance versus Generics Craig Smith 1997-04-25 0:00 ` Robert Dewar 1997-04-25 0:00 ` Lionel Draghi @ 1997-04-25 0:00 ` Mats Weber 1997-04-27 0:00 ` Matthew Heaney 1997-04-25 0:00 ` Tucker Taft ` (2 subsequent siblings) 5 siblings, 1 reply; 28+ messages in thread From: Mats Weber @ 1997-04-25 0:00 UTC (permalink / raw) Craig Smith wrote: > > Generics were a very power feature of Ada-83. With the OO features > introduced into Ada-95 (in particuliar, the tagged record and ability to > inherit), are Generics obsolute? I would guess since several features > were added to generics (like generic formal package parameters), the > answer is no. Does anyone have any thoughts on this? No, generics are by no means obsolete. The were also introduced into Modula-3, which already had inheritance, by people who like simple languages. You can simulate generics with inheritance (the technique is described in Meyer's "Object Oriented Software Construction" (very good book BTW)), but it is really just a simulation, not the real thing. You loose type checking among other things. Note that Eiffel also has generics. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Inheritance versus Generics 1997-04-25 0:00 ` Mats Weber @ 1997-04-27 0:00 ` Matthew Heaney 1997-04-27 0:00 ` Robert Dewar 1997-04-29 0:00 ` bertrand 0 siblings, 2 replies; 28+ messages in thread From: Matthew Heaney @ 1997-04-27 0:00 UTC (permalink / raw) In article <3360CA7A.2272@elca-matrix.ch>, Mats.Weber@elca-matrix.ch wrote: >You can simulate generics with inheritance (the technique is described >in Meyer's "Object Oriented Software Construction" (very good book >BTW))... A very good book that every programmer should read. The 2nd edition has just come out, with some egregious cricisms of Ada. And I was naive enough to hope that once type extension and dynamic dispatching were added, Bertrand would like Ada. Comments, anyone? Matt P.S. He actually has a link to your dissertation in his book, Mats. -------------------------------------------------------------------- Matthew Heaney Software Development Consultant <mailto:matthew_heaney@acm.org> (818) 985-1271 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Inheritance versus Generics 1997-04-27 0:00 ` Matthew Heaney @ 1997-04-27 0:00 ` Robert Dewar 1997-04-28 0:00 ` Bertrand Meyer 1997-04-29 0:00 ` bertrand 1 sibling, 1 reply; 28+ messages in thread From: Robert Dewar @ 1997-04-27 0:00 UTC (permalink / raw) Matthew Heaney said <<A very good book that every programmer should read. The 2nd edition has just come out, with some egregious cricisms of Ada. And I was naive enough to hope that once type extension and dynamic dispatching were added, Bertrand would like Ada. Comments, anyone?>> Well the world of language advocacy has always been one in which people are very ready to criticize without much practical experience. A good rule would be that you should not criticize a language unless you have written substantial amounts of real delivered production code in that language. That would eliminate Bertrand's criticisms, it would also eliminate a lot of the criticisims on CLA of other languages. Come to think of it, it might pretty much eliminate all language advocacy altogether :-) ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Inheritance versus Generics 1997-04-27 0:00 ` Robert Dewar @ 1997-04-28 0:00 ` Bertrand Meyer 1997-05-03 0:00 ` Jon S Anthony 1997-05-03 0:00 ` Robert A Duff 0 siblings, 2 replies; 28+ messages in thread From: Bertrand Meyer @ 1997-04-28 0:00 UTC (permalink / raw) Robert Dewar wrote (apropos my book "Object-Oriented Software Construction", second edition, Prentice Hall, and some of its critical comments about Ada 95): > Well the world of language advocacy has always been one in which people > are very ready to criticize without much practical experience. A good rule > would be that you should not criticize a language unless you have written > substantial amounts of real delivered production code in that language. A bit facile perhaps. Prove that my comments about Ada 95 are wrong, if they are; or, barring such a proof, state where and why you disagree; but discuss my arguments, not the number of lines of Ada 95 you assume I have compiled. Large-scale practical experience with a language cannot hurt, of course, but (posited) lack thereof does not disqualify one from talking about the language. If we took Prof. Dewar's advice literally, there would be (among other extreme consequences) no room for broad-ranging programming language surveys, since no one can be a seasoned programmer in all of - say - Ada, Eiffel, Lisp, Tcl, Visual Basic, Fortran 90, Snobol etc. Or, to continue the reductio ad absurdum, one of the justly praised aspects of the original Ada design was that it was heavily critiqued before it was finalized Applying the Dewar principle would have meant that none of that criticism was meaningful, since none of the critics had any extensive practice in the languages being discussed (especially those that were rejected, so that no one ever wrote any "substantial amount of real delivered product code" in them!). "You can't criticize Y because you have not written at least x lines of working Y code" is not a valid dismissal. If you want to debate someone's conclusions, you have to do it on the merits or demerits of his stated case. Otherwise we would fall into ad hominem disputes - and, as we all know, this is not permitted to happen on Usenet. Thanks, by the way, for the nice comments about the book. -- Bertrand Meyer, President, ISE Inc., Santa Barbara (California) 805-685-1006, fax 805-685-6869, <Bertrand.Meyer@eiffel.com> Web page: http://www.eiffel.com OOSC-2 book info: http://www.eiffel.com/doc/oosc.html ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Inheritance versus Generics 1997-04-28 0:00 ` Bertrand Meyer @ 1997-05-03 0:00 ` Jon S Anthony 1997-05-04 0:00 ` Robert Dewar 1997-05-03 0:00 ` Robert A Duff 1 sibling, 1 reply; 28+ messages in thread From: Jon S Anthony @ 1997-05-03 0:00 UTC (permalink / raw) In article <336596D9.2781E494@eiffel.com> Bertrand Meyer <bertrand@eiffel.com> writes: > Large-scale practical experience with a language cannot hurt, of > course, but (posited) lack thereof does not disqualify one from > talking about the language. I must agree with you here - with one possible caveate (see below). > Applying the Dewar principle would have meant that none of that > criticism was meaningful, since none of the critics had any > extensive practice in the languages being discussed (especially Nicely done... > "You can't criticize Y because you have not written at least > x lines of working Y code" is not a valid dismissal. If you > want to debate someone's conclusions, you have to do it on > the merits or demerits of his stated case. Right. However, for this context there is one aspect that needs to be watched out for when "failing the Dewar Principle". That has to do with differences of how a particular sort of goal is achieved in different language designs. In particular, a goal that is "handled" by providing some sort of explicit support for that goal _can_ lead the unwary into thinking that some sort of explicit construct for this particular goal is necessary in order to achieve it. And "thus" that a languae without some directly corresponding construct can't achieve it. As we know this is not true (as it may well be covered by a more general construct or an intended combination of some other constructs), but I've seen this mistake made many times. Multiple inheritance is a favorite to trip over here. "Friendship" and "public,protected,private" are other typical examples. As are co,contra,and a-variance in class based OO. Anyway, if you happen to have the luxury of engaging in the DP, then it is much more likely that you will be aware of how such diverse goals are easily handled (even without some explicit constructs specifically for them). This will "save" you from saying "X can't accomplish Y because it does not have Z like R does", when X can in fact easily accomplish Y... > Otherwise we would fall into ad hominem disputes - and, as we all > know, this is not permitted to happen on Usenet. Hey, now don't you go dissing the grand tradition! :-) /Jon -- Jon Anthony Organon Motives, Inc. Belmont, MA 02178 617.484.3383 jsa@organon.com ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Inheritance versus Generics 1997-05-03 0:00 ` Jon S Anthony @ 1997-05-04 0:00 ` Robert Dewar 0 siblings, 0 replies; 28+ messages in thread From: Robert Dewar @ 1997-05-04 0:00 UTC (permalink / raw) <<> Applying the Dewar principle would have meant that none of that > criticism was meaningful, since none of the critics had any > extensive practice in the languages being discussed (especially >> Let me make a distinction here. Obviously one can discuss specific technical aspects of a language without having written piles of code. For example, given my experience, I would say it is a mistake to design a language without recursion in its basic procedure invocation structure, and I would consider that a legitimate specific criticism of COBOL, even by someone who had not written piles of code in COBOL. What is not legitimate is to make overall judgments of usability in general or in specific domains. In other words, if you now carry that worry about recursion in COBOL to make a statement that COBOL is not useful for applicatoins in xxx domain, without having experience in how large COBOL programs are written, then you are almost certainly speaking nonsense. I was always amazed by how many people who did not know COBOL at all were surprised to find out that Realia COBOL was written 100% in COBOL. They simply assumed that this would be tricky, and that we must have had great difficulty doing this. Complete nonsense of course -- I would far rather write a compiler in COBOL than in C (and that is based on having done both!) Indeed, let's take the recursion example. One might assume that lack of recursion in a language would be a nuiscance, especially when compiling a language like COBOL with a heavily recursive syntax. In fact in the kind of domain we were working in, with a limited memory, it is always a bad idea to use recursion in a compiler, since it introduces complexity limits into programs that are induced by the maximum memory available (Realia COBOL is one of the very few compilers I know of that has aboslutely NO limits of any kind other than available disk space, and in an environment with only 200K or so of available memory (no virtual memory around) can compile programs that are millions of lines long. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Inheritance versus Generics 1997-04-28 0:00 ` Bertrand Meyer 1997-05-03 0:00 ` Jon S Anthony @ 1997-05-03 0:00 ` Robert A Duff 1997-05-03 0:00 ` Robert Dewar 1 sibling, 1 reply; 28+ messages in thread From: Robert A Duff @ 1997-05-03 0:00 UTC (permalink / raw) In article <336596D9.2781E494@eiffel.com>, Bertrand Meyer <bertrand@eiffel.com> wrote: >Large-scale practical experience with a language cannot hurt, of >course, but (posited) lack thereof does not disqualify one from >talking about the language. I tend to agree with Bertrand Meyer here. I mean, I've criticized some aspects of Eiffel without having written a line of code in Eiffel (well, at least not something serious). But I've at least read the language definition carefully. Perhaps Robert Dewar is (over)reacting to those who criticize Ada without knowing the first thing about it. I don't think Meyer is one of those. I can read a language definition (carefully), and feel some confidence in criticizing it, despite the fact that I haven't invested several years of my life programming in it. Otherwise, how can we make progress in language design? There are thousands of languages out there -- the best we can expect from language designers is to be familiar with them by reading -- not direct experience. Of course, there are those who believe Ada or Eiffel or whatever to be the ultimate -- but they're wrong; there's a lot of progress still to be made in this field. >Thanks, by the way, for the nice comments about the book. I liked your book, too. :-) - Bob ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Inheritance versus Generics 1997-05-03 0:00 ` Robert A Duff @ 1997-05-03 0:00 ` Robert Dewar 0 siblings, 0 replies; 28+ messages in thread From: Robert Dewar @ 1997-05-03 0:00 UTC (permalink / raw) Bob Duff said <<In article <336596D9.2781E494@eiffel.com>, Bertrand Meyer <bertrand@eiffel.com> wrote: >Large-scale practical experience with a language cannot hurt, of >course, but (posited) lack thereof does not disqualify one from >talking about the language. I tend to agree with Bertrand Meyer here. I mean, I've criticized some aspects of Eiffel without having written a line of code in Eiffel (well, at least not something serious). But I've at least read the language definition carefully. I am just stating a rule that comes from a lot of experience. I have all too often seen experts in this field make statements about languages they do not know well enough. Often these comments are just factually incorrect. I could give lots of examples, with lots of famous names, but that seems perhaps inappropriate :-) Anyway, it is a rule I follow for myself. I have seen far too many people who should know better make completely ridiculous statements about languages they do not know well enough -- this is particularly true for lesser known languages such as COBOL (I mean of course lesser known among the language design crowd :-) I have also seen plenty of absurd statements about C++ by Ada advocates, and plenty of absurd statements about Ada by all sorts of people. Anyway, I follow the rule myself, you won't see me criticizing Eiffel until such time as I have done some substantial programming in that language for example. Yes, it makes it harder to compare languages, but I still find it a very useful rule in filtering out objective observsations from subjective wishes. Language design is full of advocacy from people who urgently wish language X to be the best, and are consequently blinder than they should be to shortcomings of X, and strenghts of (not X). Going back to the quote, my concern is NOT with people who don't know anything, it is with experts who just don't have enough working familiarity with how a language is actually used in practice. This is a very important aspect of understanding a language design. This cannot be obtained from reading a reference manual. <<Perhaps Robert Dewar is (over)reacting to those who criticize Ada without knowing the first thing about it. I don't think Meyer is one of those.>> By the way, please note that I did not, and did not intend to specifically suggest Betrand as someone who made incorrect statements, and I have made no such statement. Bertrand added his own name to the thread in his follow up :-) I certainly did not say that Bertrand knows nothing about Ada, and I sure hope he did not take me to be saying that. I also do not say that anything disqualifies anyone from talking about anything! All I am saying is that I value comments more from people who have the practical experience to go along with their theoretical understanding. And that I apply this to myself, so if you see a comment from me criticizing a language, then it means I have written substantial amounts of code in the language (substantial = for me large scale delivered commercial code). (unless of course my evil twin brother has been masquerading as me again and violating this rule :-) Robert ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Inheritance versus Generics 1997-04-27 0:00 ` Matthew Heaney 1997-04-27 0:00 ` Robert Dewar @ 1997-04-29 0:00 ` bertrand 1997-04-29 0:00 ` Robert Dewar 1 sibling, 1 reply; 28+ messages in thread From: bertrand @ 1997-04-29 0:00 UTC (permalink / raw) Mats Weber as quoted by Matthew Heaney: > > >You can simulate generics with inheritance (the technique is described > >in Meyer's "Object Oriented Software Construction" Just a small clarification: the discussion (appendix B in the recent edition of my book, entitled "Genericity vs. Inheritance" and the n-th iteration of an article originally in the first OOPSLA conference in 1986) shows that inheritance can simulate some aspects of genericity, but not all, and that genericity by itself can only cover a small part of inheritance. On the basis of this analysis it concludes that one needs both mechanisms, and deduces the precise combination that appears adequate to cover all needs at minimal complexity. > P.S. He actually has a link to your dissertation in his book, Mats. Right... I must say I am impressed by the amount and quality of Ada 95-related material available on the Web. -------------------==== Posted via Deja News ====----------------------- http://www.dejanews.com/ Search, Read, Post to Usenet ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Inheritance versus Generics 1997-04-29 0:00 ` bertrand @ 1997-04-29 0:00 ` Robert Dewar 0 siblings, 0 replies; 28+ messages in thread From: Robert Dewar @ 1997-04-29 0:00 UTC (permalink / raw) Bertrand said <<Just a small clarification: the discussion (appendix B in the recent edition of my book, entitled "Genericity vs. Inheritance" and the n-th iteration of an article originally in the first OOPSLA conference in 1986) shows that inheritance can simulate some aspects of genericity, but not all, and that genericity by itself can only cover a small part of inheritance. On the basis of this analysis it concludes that one needs both mechanisms, and deduces the precise combination that appears adequate to cover all needs at minimal complexity.>> It is always tempting to try to unify features in programming languages which seem related, and it has always been tempting for designers to try to avoid having both inheritance and genericity, but given the very clear attempts that have been rethought (C++ adding templates, and Ada adding generalized inheritance), it really seems like we cannot avoid having both facilities. Bertrand's argument is certainly convincing, but in a way it is even more convincing when advocates of the contrary viewpoint come to change their mind. My view is that at this stage, any language not providing effective facilities in both departments is definitely decrepit (you may make up your own list of languages that are thus declared decrepit, or perhaps, with less flowery language, lacking :-) -- one interesting entry on that list is OO-COBOL, which has remarkably powerful OO features, including full inheritance, but completely lacks genericity (well I suppose you can use COPY REPLACING for a very limited version of text oriented macros to address some subset of the problem ...) Robert Dewar ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Inheritance versus Generics 1997-04-24 0:00 Inheritance versus Generics Craig Smith ` (2 preceding siblings ...) 1997-04-25 0:00 ` Mats Weber @ 1997-04-25 0:00 ` Tucker Taft 1997-04-25 0:00 ` Robert A Duff 1997-04-28 0:00 ` Martin Lorentzon 5 siblings, 0 replies; 28+ messages in thread From: Tucker Taft @ 1997-04-25 0:00 UTC (permalink / raw) Craig Smith (cdsmith0@flash.net) wrote: : Generics were a very power feature of Ada-83. With the OO features : introduced into Ada-95 (in particuliar, the tagged record and ability to : inherit), are Generics obsolute? I would guess since several features : were added to generics (like generic formal package parameters), the : answer is no. Does anyone have any thoughts on this? This one should get a lot of responses... Inheritance is good for building an extensible abstraction, whereas a generic is good for building a parameterized abstraction. The distinction between extension and parameterization is fundamental in my view, and both are very useful. It is interesting to look at Java, which supports only extension -- no parameterization. You can't build a compile-time-type-safe container abstraction in Java, such as a list of T, or a dictionary mapping T1 to T2, without writing a separate one for each possible T, or each possible T1/T2 combination. In Java, you end up using the univeral "java.lang.Object" class for many things, allowing you to create heterogenous "bags" of anything, but similarly providing no compile-time guarantee that a given "bag" has only what you want in it. By the way, our Ada 95 => Java byte code compiler supports both generics and extension, since generics are basically a compile-time concept, and we are only using the Java run-time model, not its compile-time model. I might say, when I am feeling a bit unfair, that Java has an elegant run-time model dressed in an impoverished surface syntax. : Craig D. Smith -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Burlington, MA USA ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Inheritance versus Generics 1997-04-24 0:00 Inheritance versus Generics Craig Smith ` (3 preceding siblings ...) 1997-04-25 0:00 ` Tucker Taft @ 1997-04-25 0:00 ` Robert A Duff 1997-04-28 0:00 ` Martin Lorentzon 5 siblings, 0 replies; 28+ messages in thread From: Robert A Duff @ 1997-04-25 0:00 UTC (permalink / raw) In article <33601924.774@flash.net>, Craig Smith <cdsmith0@flash.net> wrote: >Generics were a very power feature of Ada-83. With the OO features >introduced into Ada-95 (in particuliar, the tagged record and ability to >inherit), are Generics obsolute? No, generics are not obsolete. Bertrand Meyer explains why quite clearly in his OO book. He talks a lot about Eiffel, but his arguments on this point apply to Ada as well. *Some* uses of Ada 83 generics are better done with Ada 95 tagged types, but certainly not all. In fact, a mixture of the two features often makes sense. E.g., consider data structure generic package, like "Generic_Lists", where the element type is a generic formal parameter. You might want to have homogeneous lists of some specific type (list-of-integer). You might also want to have heterogeneous lists, by passing in Some_Type'Class. The same generic works for both. If you use tagged types to make your lists, instead of generics, then you end up losing type checking -- you *can't* constrain the type of list elements. (Java has this problem, as does Smalltalk.) You also end up having to derive from some central List_Item type, so if you have an existing type T, you have to go back and modify if it you want it in lists. (Assuming the links are in the list items, which is one way you might want to do it.) (Smalltalk doesn't have this problem. But then it doesn't try to do much type checking.) >... I would guess since several features >were added to generics (like generic formal package parameters), the >answer is no. Does anyone have any thoughts on this? And generic formal derived types. - Bob ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Inheritance versus Generics 1997-04-24 0:00 Inheritance versus Generics Craig Smith ` (4 preceding siblings ...) 1997-04-25 0:00 ` Robert A Duff @ 1997-04-28 0:00 ` Martin Lorentzon 5 siblings, 0 replies; 28+ messages in thread From: Martin Lorentzon @ 1997-04-28 0:00 UTC (permalink / raw) Craig Smith <cdsmith0@flash.net> writes: > Generics were a very power feature of Ada-83. With the OO features > introduced into Ada-95 (in particuliar, the tagged record and ability to > inherit), are Generics obsolute? I would guess since several features > were added to generics (like generic formal package parameters), the > answer is no. Does anyone have any thoughts on this? Mastering both features can prove very powerful. Parametrization can be used to reduce the length/complexity of the inheritance lattice of your system. I've found that parametrization is often used to end an inheritance lattice. /Martin Lorentzson ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Inheritance versus Generics
@ 1997-04-27 0:00 tmoran
0 siblings, 0 replies; 28+ messages in thread
From: tmoran @ 1997-04-27 0:00 UTC (permalink / raw)
In <5juemo$bca@felix.seas.gwu.edu> Michael Feldman gives
>A Few "Sound Bites" on Object-Oriented Programming
After about 9 months of fairly heavy use of tagged types, it seems
to me that they are a powerful tool, but tend easily to lead away
from correctness, understandability, and reusability.
It's easy to wind up calling a different routine than you thought.
It can be difficult to realize that you're calling the wrong routine.
Base types easily have too many primitives, and each generation of
descendants adds a few, resulting in a supposeduly reusable
encapsulated component that has a very large 'surface area' that the
re-user must understand. At each generation the conceptual nature
of the object tends to be slightly distorted (analogous to the
transmission of rumors), and these minor distortions tend to add
up to significant changes in the original concept. It may develop
that the newer generations, and the uses of their objects, show
the Ur-object to be less than ideal, but it's much too late to change.
Orthogonally, there is a problem with the mushiness of the word
'object' in the industry. Thus in MS Windows, an 'object' more or
less means 'a handle to a private data record'. These have somewhat
different behavior than one might expect an abstract 'menu object'
or 'pen object' to have. Another source of confusion and thus error.
Inheritance does allow some powerful ways of doing things, and
perhaps after 5-10 years, when the next Silver Bullet comes along,
we will all use OO flawlessly. ;)
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Inheritance versus Generics
@ 1997-05-03 0:00 tmoran
0 siblings, 0 replies; 28+ messages in thread
From: tmoran @ 1997-05-03 0:00 UTC (permalink / raw)
>I can read a language definition (carefully), and feel some confidence
>in criticizing it, despite the fact that I haven't invested several
>years of my life programming in it. Otherwise, how can we make progress
>in language design? There are thousands of languages out there -- the
>best we can expect from language designers is to be familiar with them
>by reading -- not direct experience. Of course, there are those who
There is a third alternative: look at the results of thousands of
real programmers using the language. It may be impractical for language
designers to have lots of direct experience in lots of languages, but
the history of science since the Greeks suggests there are real limits
on how far you can get by merely writing about other's ideas, without
going into the real world and trying out your ideas to see how they work
in practice.
Take a look at "Strategic Directions in Programming Languages" in the
new ACM Computing Surveys. Under "Exceptions", it says "introduced in
PL/1 but extensively studied and formalized in ML; similar concepts
appeared later in C++." Did the "extensive study and formalization" in
ML include having thousands of real programmers, of varying excellence,
write millions of lines of code using exceptions in various
idiosyncratic ways, thus providing grist for the language designers to
fine tune the syntax, semantics, and guidelines about exceptions?
^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~1997-05-04 0:00 UTC | newest] Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1997-04-24 0:00 Inheritance versus Generics Craig Smith 1997-04-25 0:00 ` Robert Dewar 1997-04-25 0:00 ` Michael F Brenner 1997-04-25 0:00 ` Robert Dewar 1997-04-27 0:00 ` Nick Roberts 1997-04-29 0:00 ` Michael F Brenner 1997-05-02 0:00 ` Nick Roberts 1997-05-03 0:00 ` Robert Dewar 1997-05-02 0:00 ` John G. Volan 1997-04-29 0:00 ` Mats Weber 1997-05-01 0:00 ` Robert Dewar 1997-04-26 0:00 ` Michael Feldman 1997-04-25 0:00 ` Lionel Draghi 1997-04-25 0:00 ` Mats Weber 1997-04-27 0:00 ` Matthew Heaney 1997-04-27 0:00 ` Robert Dewar 1997-04-28 0:00 ` Bertrand Meyer 1997-05-03 0:00 ` Jon S Anthony 1997-05-04 0:00 ` Robert Dewar 1997-05-03 0:00 ` Robert A Duff 1997-05-03 0:00 ` Robert Dewar 1997-04-29 0:00 ` bertrand 1997-04-29 0:00 ` Robert Dewar 1997-04-25 0:00 ` Tucker Taft 1997-04-25 0:00 ` Robert A Duff 1997-04-28 0:00 ` Martin Lorentzon -- strict thread matches above, loose matches on Subject: below -- 1997-04-27 0:00 tmoran 1997-05-03 0:00 tmoran
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox