* Re: Ichibah flames, and flames out over, Ada 9X @ 1993-03-07 19:15 John Goodsen 1993-03-08 0:45 ` David Emery 1993-03-08 15:36 ` Tucker Taft 0 siblings, 2 replies; 25+ messages in thread From: John Goodsen @ 1993-03-07 19:15 UTC (permalink / raw) >In article <1993Feb25.170827.2178@ennews.eas.asu.edu> stt@spock.camb.inmet.com (Tucker Taft) writes: >>. . . I hear all this hype about tagged types > >I'm glad to know that at least we are getting some "hype" out >on Ada 9X. As any good marketer knows, publicity of any kind is often >better than no publicity at all. ;-) > *often* but not *always*. In the case of this news thread, the "hype" is not helping the perception of Ada 9X in a positive manner... >> . . . and I see a >>few small examples of how they're used with packages/generics/..., >>but has anyone implemented a few OO problems with each and compared >>them? Semantically, it was easier to add extensiosn to Ada than a >>class construct. But, I think the jury's still out on the "type >>extensions >> classes" question. > >Actually, there really is not that much difference. A class-based language >happens to have type = module, whereas in package/module-based languages, >types are declared inside of modules. > Actually, there's nothing saying that you can't have *MORE* than one class per module (Ada package) in a class based language. The class supports the logical encapsulation of data and operations on that data (which is the norm in the OO community). Ada packages would provide the capability to group related classes and nested classes. What's the *real* problem with introducing the keyword "class" instead of "type ... is tagged" ?!?!? The tagged type extension doesn't provide the logical encapsulation mechanism for the associated operations. So if I *do* add more than one class (tagged type) to a package, where's the logical encapsulation of the operations that can be performed on that type? Leave it up to the programmer to place them in close proximity? Add more rules to coding guidelines to ensure it? I'd rather have the language enforce it... Is it really that painful to bite the bullet and add the keyword "class" to the Ada language. This simple addition to the current 9X approach will provide vendors such as us with a lot more "perceptual power" to lobby the OO community to seriously look at using Ada rather than languages such as C++ on their projects. Once again I'll state it: A *PERCEIVED* feature of an Object Oriented language is that it provides a class mechanism with polymorphic behavior. If Ada 9X comes out without direct support for the concept of class, then it will have trouble being *PERCEIVED* as a *real* OO language and you can kiss all those new OO markets bye-bye. It doesn't matter if I can *achieve* it with tagged types, the simple fact of the matter is that most people won't dig deep enough into the concept of tagged types to understand that this is where their class/inheritance/polymorphism support is embedded. They will end up choosing languages like C++ which provide *direct* support for the class concept. What do we mean by *direct* support for the class concept? Simple: Add the keyword "CLASS" to the language already !!! Heck, you've already got the 'CLASS attribute in the language! Is it really that much more effort to use "CLASS" instead of "TYPE ... IS TAGGED" ??? I'm getting the feeling that the real reason for not adding CLASS to the language is an extreeeeeeeeeme case of the "Not Invented Here" syndrome. In this case the NIH syndrome will hurt the marketing of Ada as an OO language worse than anything else I can think of (including the lack of direct support for multiple inheritance, which is another issue :-) >If you only declare one type ... [talk about one type per module ]... > >But in any case, the debate between Jean Ichbiah and the >Ada 9X Mapping/Revision Team (MRT) was not really about >"classes" vs. "type extensions," it was whether we >should use the keyword "class" in the syntax for type extensions. > From reading the above, you can see that my vote is with Mr. Ichbiah... >The MRT felt that it would simply further confuse the issue by trying >to cloak our type extensions in the word "class." > "Cloak" ?? Hmmm, so what you're saying is that Ada 9X truly doesn't have a "class" concept but rather it is a "type extension" ? > >So the issue was really about which syntax was most suggestive of the >semantics --a kind of issue that unfortunately does not lend itself to >objective debate, even though it creates strong feelings on both sides. > How about a debate which includes $$ and cents in the marketing of the language. Too much technical focus and not enough market focus on the OO support of Ada 9X will come back to haunt us ... > > . . . People seem to use what they like and OO developers like a >class construct. Tagged types are not new and for some reason or >another were never embraced by the OO community. > ... [ more talk about types inside modules ] ... > >Despite the enormous success of C++, there is still a lot of (at least >academic) interest in the new OOP languages Modula-3 and Oberon-2, both >of which have gone the type-inside-module. So it may be too early to say that >"we have a winner." > As the C++ market doubles each year, I don't think there is much debate who the "winner" will likely be. C++ has already layed out most of commercial market battle field for OO languages in the next 10 years. Wouldn't it be nice to say that "Ada has everything C++ has *PLUS* tasking, hierarchical libraries, etc..."? Ada 9X has got to directly match the class concept of C++ or it will lose too many potential users to a language which supports it. When people read an OOD book and it talks about "classes", "inheritance" and "polymorphism", they will naturally look for these constructs in a language. The majority of these people will bypass Ada 9X when they see that it doesn't have direct support for "classes" (unless this advice is heeded and the tagged types are changed to classes :-) >And for that matter, once you start using one >of these languages, you will probably discover the type=module vs. >type-inside-module choice has very little effect on how you design >and structure your OOP systems. You will end up creating groups of >types whether or not the language directly supports the concept of >"modules." Similarly, you will often end up having one (primary) type >in a module, even if the language allows multiple such types. >The structure of the problem will probably have more effect on >the structure of the program than does the type=module vs. type-inside-module >decision of the language designer. > All the more reason to allow multiple CLASSes in an Ada package? (which tagged types gives us). Now all we need to do is make them look like a class instead of a "tagged type". Then we've got the best of both worlds! :-) Leave Ada types and subtypes as they are in Ada 83. They serve their purpose just fine. Don't confuse them with classes and inheritance. >> . . .Should be an >>interesting next few years. > >No debate there. > It would be even more interesting if Ada 9X became a *real* commercial competitor of C++ !!! CLASS! CLASS! CLASS! If you don't have class, you won't be considered an OO language!!! I doubt many reading this c.l.a newsgroup want to hear: "Ada's a nice language, but it doesn't have any CLASS!" :-) EDITOR'S NOTE: There's more to changing "TYPE ... IS TAGGED" to "CLASS" than addressed in this post. In particular the syntax and semantics of encapsulating functions/procedures within a class are left as excercise to the MRT. :-) Once again I'll point to Colin Atkinson's book on DRAGOON as an excellent example on how to do it... -- John Goodsen Software Process & Environments EVB Software Engineering jgg@evb.com ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Ichibah flames, and flames out over, Ada 9X 1993-03-07 19:15 Ichibah flames, and flames out over, Ada 9X John Goodsen @ 1993-03-08 0:45 ` David Emery 1993-03-08 15:36 ` Tucker Taft 1 sibling, 0 replies; 25+ messages in thread From: David Emery @ 1993-03-08 0:45 UTC (permalink / raw) In my opinion, the term "class" is too tied up with C++ now. I'ave said many times that Ada's greatest strength is that it is *NOT* C/C++. Consider the average unwashed programmer who knows (or think he knows C++). When he sees the word "class", he will expect C++ class semantics. If Ada9X does not deliver C++ semantics, then he'll start screaming that Adas9X "got it wrong." By not using the boogie-word "class", we avoid bringing in all of the baggage now associated with C++ classes. On the other hand, people who know multiple OO languages (e.g. Eiffel, SmallTalk, Modula-3, etc.) will probably jnot be intimidated by the absence of the "C-word". We will not convince the died-in-the-wool (pun intended) programmer who believes C is the greatest thing ever, and C++ is even better (is this attitude consistent??), taht Adas9X offers a serious alternative. In many respects, our big hope for Ada9X is for software engineers who have tried C++ and don't like it, for whatever reason. dave ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Ichibah flames, and flames out over, Ada 9X 1993-03-07 19:15 Ichibah flames, and flames out over, Ada 9X John Goodsen 1993-03-08 0:45 ` David Emery @ 1993-03-08 15:36 ` Tucker Taft 1993-03-08 16:28 ` Michael Feldman ` (3 more replies) 1 sibling, 4 replies; 25+ messages in thread From: Tucker Taft @ 1993-03-08 15:36 UTC (permalink / raw) In article <1993Mar7.191557.5547@evb.com> jgg@evb.com (John Goodsen) writes: >>In article <1993Feb25.170827.2178@ennews.eas.asu.edu> > stt@spock.camb.inmet.com (Tucker Taft) writes: > >>>. . . I hear all this hype about tagged types >> >>I'm glad to know that at least we are getting some "hype" out >>on Ada 9X. As any good marketer knows, publicity of any kind is often >>better than no publicity at all. ;-) >> > >*often* but not *always*. In the case of this news thread, the >"hype" is not helping the perception of Ada 9X in a positive manner... Please note the "smiley." > . . . >What's the *real* problem with introducing the keyword "class" >instead of "type ... is tagged" ?!?!? > >The tagged type extension doesn't provide the logical encapsulation >mechanism for the associated operations. So if I *do* add more >than one class (tagged type) to a package, where's the logical >encapsulation of the operations that can be performed on that type? >Leave it up to the programmer to place them in close proximity? >Add more rules to coding guidelines to ensure it? I'd rather have >the language enforce it... I can feel a religious war coming on... In Ada 83, the package is the encapsulation/information-hiding construct. Adding a keyword "class" to "type ... is tagged" wouldn't change that at all, and the keyword substitution was all that Jean Ichbiah was proposing. In fact, he specifically made it clear in his proposal that we should *not* change the encapsulation rules. After all, his team designed packages in the first place, with full knowledge of the "class-based" alternatives present in Simula-67, CLU, etc. Using classes for encapsulation works great in some circumstances, but breaks down in others. If you are familiar with the way operators work in C++, and the subtleties having to do with implicit conversions on the "this" parameter versus the other parameter (the "that" parameter ;-), the appropriate use of "friends," etc., you begin to see the places where class=module approach breaks down. Consider a typical definition of a "complex" abstract data type in Ada 83 (names of operations can be debated in e-mail): generic type Real is digits <>; package Complex_Numbers is type Complex is private; function "+"(L, R : Complex) return Complex; function "*"(L, R : Complex) return Complex; . . . function Cmplx(Re, Im : Real) return Complex; function Re(C : Compex) return Real; function Im(C : Compex) return Real; type Imaginary is private; i : constant Imaginary; -- This allows "3.5 + 4.0*i" notation function "*"(L : Real; R : Imaginary) return Imaginary; function "*"(L : Imaginary; R : Real) return Imaginary; function "+"(L : Real; R : Imaginary) return Complex; function "+"(L : Imaginary; R : Real) return Complex; . . . private type Complex is record Re, Im : Real; end record; type Imaginary is new Real; end Complex_Numbers; How would you write this in a "class-based" language? At least in C++, operators almost always have to be made "friends" to work right. So much for language-enforced encapsulation. And here we have two types, Complex and Imaginary, that are interrelated, and are naturally defined in a single package. One would have to resort to "friends" or perhaps nesting in C++. The C++ solution might nevertheless be quite elegant, if structured properly according to reasonable coding guidelines, using the file=module model where appropriate. But in this case, we see that Ada provides better direct encapsulation support than does a class-based language. So for some cases, where most operations have only a single "interesting" parameter, the class-based approach seems more direct. In other cases (like the above), the package-based approach seems more direct and supportive of encapsulation. In any case, Ada 83 clearly chose the package-based approach, and we are not trying to change that for Ada 9X. We felt that there was no need to force Ada programmers to adopt a different way of doing encapsulation just to get more support for dynamic binding and type extension. We don't see the need to make Ada 9X a "me too" object-oriented language. Instead, we want it to combine the best ideas of Ada 83 and OO languages, into something that advances the state of the art, not something that trails just behind always trying to catch up. We believe that this approach makes the most sense, both technical, and marketing. Your mileage may of course vary... > . . . >John Goodsen >EVB Software Engineering S. Tucker Taft stt@inmet.com Ada 9X Mapping/Revision Team Intermetrics, Inc. Cambridge, MA 02138 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Ichibah flames, and flames out over, Ada 9X 1993-03-08 15:36 ` Tucker Taft @ 1993-03-08 16:28 ` Michael Feldman 1993-03-08 22:15 ` Gregory Aharonian 1993-03-09 17:49 ` Harry Koehnemann 1993-03-09 18:12 ` Tom Wicklund ` (2 subsequent siblings) 3 siblings, 2 replies; 25+ messages in thread From: Michael Feldman @ 1993-03-08 16:28 UTC (permalink / raw) In article <1993Mar8.153639.3603@inmet.camb.inmet.com> stt@spock.camb.inmet.com (Tucker Taft) writes: > [ good stuff deleted] >In any case, Ada 83 clearly chose the package-based approach, and >we are not trying to change that for Ada 9X. We felt that there >was no need to force Ada programmers to adopt a different way of >doing encapsulation just to get more support for dynamic binding >and type extension. > >We don't see the need to make Ada 9X a "me too" object-oriented >language. Instead, we want it to combine the best ideas of >Ada 83 and OO languages, into something that advances the state >of the art, not something that trails just behind always trying >to catch up. We believe that this approach makes the most sense, >both technical, and marketing. Your mileage may of course vary... > Hear, hear! It seems the same people who have trashed Ada for being too stodgy and conservative now want Ada to be merely imitative of the latest craze. Just because C++ does something in a certain way does NOT make it the only way, or the only correct way. There is nothing to prevent Ada from charting its own course. Ada's success will be fostered far more by the ready availability of Ada9X compilers and tools at fair prices, including some free ones so that we academics can muck around in the source code, than by whether or not it uses the magic word "class". Instead of constantly kvetching about classes vs. tagged types, let's get on about the _real_ business. Freeze the language and get the compilers done. I meet too many people who describe OOP as follows: "I don't know much about it, but whatever it is, it's that stuff C++ can do and Ada can't." It's high time to change this culture of ignorance. It starts in the schools and works its way outward. The Ada83 "in group" missed this point. Thank Heaven that the Ada9X "in group" seems (_seems_) to be getting it. We shall see... Cheers - Mike Feldman ------------------------------------------------------------------------ Michael B. Feldman co-chair, SIGAda Education Committee Professor, Dept. of Electrical Engineering and Computer Science School of Engineering and Applied Science The George Washington University Washington, DC 20052 USA (202) 994-5253 (voice) (202) 994-5296 (fax) mfeldman@seas.gwu.edu (Internet) "The most important thing is to be sincere, and once you've learned how to fake that, you've got it made." -- old show-business adage ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Ichibah flames, and flames out over, Ada 9X 1993-03-08 16:28 ` Michael Feldman @ 1993-03-08 22:15 ` Gregory Aharonian 1993-03-09 14:20 ` Tucker Taft ` (2 more replies) 1993-03-09 17:49 ` Harry Koehnemann 1 sibling, 3 replies; 25+ messages in thread From: Gregory Aharonian @ 1993-03-08 22:15 UTC (permalink / raw) With regards to the comments by Tucker and Mike, I think the original emphasis of the posting is being overlooked. Like it or not, Ada right now is in a vicious competition with C++ and Smalltalk, and not doing very well. Thus it seems to me that some purity will have to be sacrificed with regards to Ada9X to achieve that level of commercial success necessary for the DoD to achieve its original goals from Ada83 days. Looking at the people involved with Ada9X, there are very few people with a business stake in the language (DoD types), or a great track record in promoting Ada in the non-Mandated world (vendor types). From the outside, one could make the case that the Ada9X effort is doing its best to improve the language while maintaining the status quo with regards to a language that too many in the non-Mandated world can ignorantly, but easily, dismiss. I highly doubt that many on the Ada9X effort ever though the following thought in any of their deliberations: "If I was spending my own money on this, what would I want". From this point of view, the original posting's call for more features in Ada9X that allows better competition with C++ (and Smalltalk) should be heeded. Greg Aharonian -- ************************************************************************** Greg Aharonian Source Translation & Optimiztion P.O. Box 404, Belmont, MA 02178 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Ichibah flames, and flames out over, Ada 9X 1993-03-08 22:15 ` Gregory Aharonian @ 1993-03-09 14:20 ` Tucker Taft 1993-03-09 14:55 ` C. Michael Holloway 1993-03-10 14:51 ` Gregory Aharonian 1993-03-09 17:12 ` Harry Koehnemann 1993-03-09 20:14 ` Larry M. Jordan 2 siblings, 2 replies; 25+ messages in thread From: Tucker Taft @ 1993-03-09 14:20 UTC (permalink / raw) In article <SRCTRAN.93Mar8171548@world.std.com> srctran@world.std.com (Gregory Aharonian) writes: > . . . > Looking at the people involved with Ada9X, there are very few people with >a business stake in the language (DoD types), or a great track record in >promoting Ada in the non-Mandated world (vendor types). This sentence is a bit hard to understand. But my best guess of what it means is quite far from the truth. It seems that you have become so frustrated with the Ada and DoD worlds that you have stopped talking to anyone in those worlds. That's fine, but then you should try to refrain from generalizing about them. Rest assured that *many* of the people involved in Ada 9X have a *huge* stake in the language. Some of the best people involved work for small companies that are quite likely to go belly-up if Ada 9X is a failure. And those that work for larger companies have a very large personal stake in the success of Ada 9X, both economic and career-wise. > . . . From the outside, >one could make the case that the Ada9X effort is doing its best to improve >the language while maintaining the status quo with regards to a language >that too many in the non-Mandated world can ignorantly, but easily, dismiss. You could make that case, I suppose, but you would almost certainly lose it, since the evidence to support it is incredibly flimsy; the case on the opposite side is much stronger. > I highly doubt that many on the Ada9X effort ever though the following >thought in any of their deliberations: "If I was spending my own money on >this, what would I want". You may "highly doubt" it, but I wonder on what basis you formed your opinion. The truth is, in fact, just the opposite. This question, at least, I can answer with some authority ;-). If we were spending our own money, we would design Ada 9X the way we did design it. And in any case, like many people involved in computer science, spending our own money is not nearly as painful as spending our own time and energy. It is our express goal, and always has been, that Ada 9X will be the language of choice for systems programmers who have a choice. > . . .From this point of view, the original posting's >call for more features in Ada9X that allows better competition with C++ >(and Smalltalk) should be heeded. There are many ways to skin a cat. In many cases, imitation is not the most effective strategy. Why choose Ada 9X if it makes the same mistakes that C++ does? We should learn from the strengths and weaknesses of other languages, and advance the state of the art, not solidify it around a 1985-vintage design. Like others, I welcome your efforts to "wake up" the Ada community. But you only serve to dilute your message by making unnecessary generalizations based on lack of direct knowledge. If you really care, why not try to meet a few of the people involved with the Ada 9X project? If you don't, then don't dilute your message by making unwarranted claims about us. >Greg Aharonian S. Tucker Taft stt@inmet.com Ada 9X Mapping/Revision Team Intermetrics, Inc. Cambridge, MA 02138 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Ichibah flames, and flames out over, Ada 9X 1993-03-09 14:20 ` Tucker Taft @ 1993-03-09 14:55 ` C. Michael Holloway 1993-03-10 14:51 ` Gregory Aharonian 1 sibling, 0 replies; 25+ messages in thread From: C. Michael Holloway @ 1993-03-09 14:55 UTC (permalink / raw) >>>>> On 9 Mar 93 14:20:13 GMT, stt@spock.camb.inmet.com (Tucker Taft) said: tt> ... If we were spending our own money, we would design Ada 9X the way we tt> did design it. And in any case, like many people involved in computer tt> science, spending our own money is not nearly as painful as spending our tt> own time and energy. It is our express goal, and always has been, that tt> Ada 9X will be the language of choice for systems programmers who have a tt> choice. ... There are many ways to skin a cat. In many cases, tt> imitation is not the most effective strategy. Why choose Ada 9X if it tt> makes the same mistakes that C++ does? We should learn from the tt> strengths and weaknesses of other languages, and advance the state of the tt> art, not solidify it around a 1985-vintage design. From a purely technical point of view, I agree with this completely. Mr. Taft and the mapping/revision team have designed an excellent language -- one that I would choose for systems programming, were I to do such programming and to have such a choice. Were technical factors the only factors that mattered, then Ada 9X would be a resounding success; unfortunately, technical factors are rarely even the most important ones. We can all think of numerous examples of technically inferior products that have become successes (to avoid offending someone, I'll refrain from listing a few examples that come to my mind). This is especially true in programming languages, because in many companies, agencies, projects, etc, technically knowledgeable people are not the ones who make the decisions as to what programming language will be used. That's not the way that things ought to be, but it is the way that things are in many places. Personally, I am fully persuaded by Mr. Taft's arguments for the current syntax and semantics of the object-oriented aspects of Ada 9X. But that syntax may well prevent the language from being used in many places; enough places, I am afraid, to doom it to commercial failure. In fact, if Mr. Taft were to make these arguments to high level managers, the end of the discussion might well resemble Paul's discussion with Festus in Acts 26 (to paraphrase): Now as Mr. Taft thus made his defense, Mr. Manager said with a loud voice, "Tucker, you are beside yourself! Much learning is driving you mad!" But he said, "I am not mad, most noble manager, but speak the words of truth and reason." Now, Paul was discussing eternal truth and could not compromise his message, but since Ada 9X is a little more temporal, some compromise ought to be possible. ================================================================= C. Michael Holloway Email: c.m.holloway@LaRC.NASA.GOV NASA Langley Research Center Fax: 1 804 864 4234 Mail Stop 130 Voice: 1 804 864 1701 Hampton VA 23681-0001 -- ================================================================= C. Michael Holloway Email: c.m.holloway@LaRC.NASA.GOV NASA Langley Research Center Fax: 1 804 864 4234 Mail Stop 130 Voice: 1 804 864 1701 Hampton VA 23681-0001 Verse: Psalm 97:1 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Ichibah flames, and flames out over, Ada 9X 1993-03-09 14:20 ` Tucker Taft 1993-03-09 14:55 ` C. Michael Holloway @ 1993-03-10 14:51 ` Gregory Aharonian 1 sibling, 0 replies; 25+ messages in thread From: Gregory Aharonian @ 1993-03-10 14:51 UTC (permalink / raw) >This sentence is a bit hard to understand. But my best guess of what >it means is quite far from the truth. It seems that you have become >so frustrated with the Ada and DoD worlds that you have stopped talking >to anyone in those worlds. That's fine, but then you should try to >refrain from generalizing about them. Rest assured that *many* of the >people involved in Ada 9X have a *huge* stake in the language. Some >of the best people involved work for small companies that are quite likely >to go belly-up if Ada 9X is a failure. And those that work for >larger companies have a very large personal stake in the success of Ada 9X, >both economic and career-wise. Tucker, Let me make it easier to understand. Consider the general trade press in computing, with such publications as Computerworld, Software, Datamation, Mid-Range Systems, Computer Language, Infoworld, Open Systems Today, Computer Design, the IEEE and ACM general publications, Data Management Review, and others. I rarely, if ever, see any ads for Ada compilers from most of the companies reflected in the Ada9X effort. Nothing. Consider the general (by general, I mean non-Mandated) trade shows. Object World, CASE World, Software Engineering XX, etc. Rarely, if ever, do I see much of an Ada presence by most of the companies reflected in the Ada9X effort. Sure, I believe that you guys have a "huge" stake in the Ada9X effort, but based on this behavior analysis, it seems that the stake you are striving for is the nice cozy Mandated world. I do not see much evidence that you guys are taking the evangelizing of Ada seriously, outside the Mandated world. I rarely if ever see ads for Ada, trade show booths for Ada, bingo cards in card decks for Ada, direct mail pieces for Ada, anything for Ada. I just don't see anything being done to better promote Ada. Nothing from the DoD, nothing from DoD contractors, and especially nothing from Ada compiler vendors. You tell me where are the continually running ads for Intermetrics, Alsys, Meridian, Verdix, Aetech, etc. Scattershot is what I see at best, especially compared to the advertising square inch space for other languages. Thus Tucker, my original concern still holds. I barely see any presence of many of the Ada9X people in the non-Mandated world, and am afraid that what will come out of the Ada9X effort will be a great language that will be even less accepted in the non-Mandated world than Ada83. Prove me wrong that there you guys have a much bigger presence in the non-Mandated world. If nothing else, explain to me why Intermetrics (at least in Cambridge) seems to keep on losing its best programmers (many of whom are my friends) to numerous C/C++ efforts in the Boston area. If nothing else, how about a round of golf at Fresh Pond to settle this one way or the other. If you win, I'll admit that Ada has behind it the best marketing campaign in advertising history, and if I win, you'll admit that you are all a bunch of parasites (in the strictly biological analogy meaning). Greg Aharonian -- ************************************************************************** Greg Aharonian Source Translation & Optimiztion P.O. Box 404, Belmont, MA 02178 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Ichibah flames, and flames out over, Ada 9X 1993-03-08 22:15 ` Gregory Aharonian 1993-03-09 14:20 ` Tucker Taft @ 1993-03-09 17:12 ` Harry Koehnemann 1993-03-09 20:54 ` Michael Feldman 1993-03-09 20:14 ` Larry M. Jordan 2 siblings, 1 reply; 25+ messages in thread From: Harry Koehnemann @ 1993-03-09 17:12 UTC (permalink / raw) In article <SRCTRAN.93Mar8171548@world.std.com> srctran@world.std.com (Gregory Aharonian) writes: >From this point of view, the original posting's >call for more features in Ada9X that allows better competition with C++ >(and Smalltalk) should be heeded. All I wanted to know was why type extensions were chosen over the class construct (which I think Mr. Taft addressed). I've always had the question - Do classes or type extensions map better to typical OO problems? I've never seen any studys that compared the two. I figured that, since the OO additions were perhaps that largest change in a rather costly revision process, someone might have looked into why classes were so popular - maybe even done that study I've been looking for. Another point is that neither construct is new (despite what I hear on c.l.a) and classes seem to have "won" in the OO world. If Ada wants to play ball in that community, I feel it's got a pretty big sell ahead of itself - which could probably start with that study comparing classes and type extensions for some model OO problems. (kindof like doing the feasibility study after the products built) People seem to enjoy finding flaws in Ada. Will type extensions be another one of those problem areas people love to point at when talking about Ada? ("Type extensions! We saw type extensions way back in...") Either way, I think it's a big area of risk for 9X. -- Harry Koehnemann Arizona State University koehnema@enuxha.eas.asu.edu Computer Science Department ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Ichibah flames, and flames out over, Ada 9X 1993-03-09 17:12 ` Harry Koehnemann @ 1993-03-09 20:54 ` Michael Feldman 0 siblings, 0 replies; 25+ messages in thread From: Michael Feldman @ 1993-03-09 20:54 UTC (permalink / raw) In article <1993Mar9.171230.28664@ennews.eas.asu.edu> koehnema@enuxhb.eas.asu.edu (Harry Koehnemann) writes: > >All I wanted to know was why type extensions were chosen over the >class construct (which I think Mr. Taft addressed). I've always had >the question - Do classes or type extensions map better to typical OO >problems? I've never seen any studys that compared the two. I figured Ummm - you might start with Rosen's article in Nov. 92 Comm. ACM. Mike Feldman ------------------------------------------------------------------------ Michael B. Feldman co-chair, SIGAda Education Committee Professor, Dept. of Electrical Engineering and Computer Science School of Engineering and Applied Science The George Washington University Washington, DC 20052 USA (202) 994-5253 (voice) (202) 994-5296 (fax) mfeldman@seas.gwu.edu (Internet) "The most important thing is to be sincere, and once you've learned how to fake that, you've got it made." -- old show-business adage ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Ichibah flames, and flames out over, Ada 9X 1993-03-08 22:15 ` Gregory Aharonian 1993-03-09 14:20 ` Tucker Taft 1993-03-09 17:12 ` Harry Koehnemann @ 1993-03-09 20:14 ` Larry M. Jordan 2 siblings, 0 replies; 25+ messages in thread From: Larry M. Jordan @ 1993-03-09 20:14 UTC (permalink / raw) In article <SRCTRAN.93Mar8171548@world.std.com> srctran@world.std.com (Gregory Aharonian) writes: > With regards to the comments by Tucker and Mike, I think the original >emphasis of the posting is being overlooked. Like it or not, Ada right now >is in a vicious competition with C++ and Smalltalk, and not doing very well. [lots of excellent stuff deleted] > >this, what would I want". From this point of view, the original posting's >call for more features in Ada9X that allows better competition with C++ >(and Smalltalk) should be heeded. > Let me register my agreement with Greg. I'd sure like to know how many others feel this way. --Larry ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Ichibah flames, and flames out over, Ada 9X 1993-03-08 16:28 ` Michael Feldman 1993-03-08 22:15 ` Gregory Aharonian @ 1993-03-09 17:49 ` Harry Koehnemann 1993-03-09 21:01 ` Michael Feldman 1 sibling, 1 reply; 25+ messages in thread From: Harry Koehnemann @ 1993-03-09 17:49 UTC (permalink / raw) In article <1993Mar8.162831.8767@seas.gwu.edu> mfeldman@seas.gwu.edu (Michael Feldman) writes: >I meet too many people who describe OOP as follows: "I don't know much >about it, but whatever it is, it's that stuff C++ can do and Ada can't." Hmmm. Most the OO people I know talk about OO as "objects, classes, and inheritance" and discuss objects as active entities (rather than passive as they are with tagged types). I don't mean to downplay the work done on 9X and I personally haven't resolved the "Classes vs. Type Extensions" question yet, but these are likely arguments you're going to get from the OO community. Every OO text I know of defines an OO language as Objects, Classes, and Inheritance. Granted type extensions yield a form of classification, but it is not as evident as it is in a language with a construct called "class". And, we have yet to determined whether that form of classification is as useful as a class. Second, OO principles are very big on objects being active. I write Obj.Operation rather than Operation(Obj). In fact, people have hinted at Ada83 being OO because of the tasking mechanism, simply because it uses hte proper notation (and that tasks have an internal thread of control). How does my OO design translate into a language where objects aren't active? >It's high time to change this culture of ignorance. It starts in the >schools and works its way outward. The Ada83 "in group" missed this point. >Thank Heaven that the Ada9X "in group" seems (_seems_) to be getting it. >We shall see... I agree completely. If you're going to sell Ada as object-oriented, you'd better be prepared to defend that statment. I disagree with your assessment of the OO community. Most of them really know their shit when it comes to OOness and we sure as hell don't want to loose arguments because we are ignorant of the facts. I'm just getting prepared for what's likely ahead. Adios. -- Harry Koehnemann Arizona State University koehnema@enuxha.eas.asu.edu Computer Science Department ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Ichibah flames, and flames out over, Ada 9X 1993-03-09 17:49 ` Harry Koehnemann @ 1993-03-09 21:01 ` Michael Feldman 0 siblings, 0 replies; 25+ messages in thread From: Michael Feldman @ 1993-03-09 21:01 UTC (permalink / raw) In article <1993Mar9.174925.29392@ennews.eas.asu.edu> koehnema@enuxha.eas.asu.edu (Harry Koehnemann) writes: >In article <1993Mar8.162831.8767@seas.gwu.edu> mfeldman@seas.gwu.edu (Michael Feldman) writes: >>I meet too many people who describe OOP as follows: "I don't know much >>about it, but whatever it is, it's that stuff C++ can do and Ada can't." > >Hmmm. Most the OO people I know talk about OO as "objects, classes, >and inheritance" and discuss objects as active entities (rather than >passive as they are with tagged types). I don't mean to downplay the >work done on 9X and I personally haven't resolved the "Classes vs. Type >Extensions" question yet, but these are likely arguments you're going to >get from the OO community. Oh, you and I are tekkies. I mean the project managers, the ones who get to make the decisions. Some of them even have gold braid on their starched shirts. > >Every OO text I know of defines an OO language as Objects, Classes, and >Inheritance. Granted type extensions yield a form of classification, >but it is not as evident as it is in a language with a construct called >"class". And, we have yet to determined whether that form of >classification is as useful as a class. Correct. 'Course the OO texts have picked up on a recent bit of jargon. They may not have a monopoly on truth; they've just co-opted the buzzwords. > >Second, OO principles are very big on objects being active. I write >Obj.Operation rather than Operation(Obj). In fact, people have >hinted at Ada83 being OO because of the tasking mechanism, simply >because it uses hte proper notation (and that tasks have an internal >thread of control). How does my OO design translate into a language >where objects aren't active? You are obviously not in the category of folks I was referring to. > >>It's high time to change this culture of ignorance. It starts in the >>schools and works its way outward. The Ada83 "in group" missed this point. >>Thank Heaven that the Ada9X "in group" seems (_seems_) to be getting it. >>We shall see... > >I agree completely. If you're going to sell Ada as object-oriented, >you'd better be prepared to defend that statment. I disagree with >your assessment of the OO community. Most of them really know their >shit when it comes to OOness and we sure as hell don't want to loose >arguments because we are ignorant of the facts. I'm just getting >prepared for what's likely ahead. > The folks I mean are not in "the OO community." I meant what I said QUITE LITERALLY: they know little about OO but somebody, somewhere, told them that C++ could do it and Ada couldn't. They haven't got the foggiest idea whether Objects, Classes, Inheritance, etc., would make a damn bit of difference in the cost-effectveness of their project. But somebody told 'em that OO was the greatest thing since sliced bread, reason enough to fight the Ada Mandate. Arrant nonsense. But it's out there. It's enough to make your hair stand on end. And it's your tax money and mine. Mike ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Ichibah flames, and flames out over, Ada 9X 1993-03-08 15:36 ` Tucker Taft 1993-03-08 16:28 ` Michael Feldman @ 1993-03-09 18:12 ` Tom Wicklund 1993-03-11 8:04 ` Encapsulation in Ada vs. C++ (Was Re: Ichibah [sic] ...) Magnus Kempe 1993-03-09 18:53 ` Ichibah flames, and flames out over, Ada 9X Larry M. Jordan 1993-03-16 17:34 ` Robert Firth 3 siblings, 1 reply; 25+ messages in thread From: Tom Wicklund @ 1993-03-09 18:12 UTC (permalink / raw) In <1993Mar8.153639.3603@inmet.camb.inmet.com> stt@spock.camb.inmet.com (Tucker Taft) writes: >I can feel a religious war coming on... I don't want to start a religious war, but I think Mr. Taft's experience with C++ is too limited. On the other hand, I've never done any real Ada programming so I apologize in advance for any errors in my knowledge of Ada. Both C++ and Ada have their strengths and weaknesses, I'm not fond of either as a "favorite" langauge though I have some preference for C++ due primarily to better familiarity. >Using classes for encapsulation works great in some circumstances, >but breaks down in others. If you are familiar with the >way operators work in C++, and the subtleties having to do >with implicit conversions on the "this" parameter versus the >other parameter (the "that" parameter ;-), the appropriate >use of "friends," etc., you begin to see the places where >class=module approach breaks down. However, C++ doesn't use a class=module approach. You're comment applies more to a language like Eiffel. C++ uses the class to control information hiding, similar to (one function of) Ada's package. >Consider a typical definition of a "complex" abstract data type in >Ada 83 (names of operations can be debated in e-mail): > generic > type Real is digits <>; > package Complex_Numbers is > type Complex is private; > function "+"(L, R : Complex) return Complex; > function "*"(L, R : Complex) return Complex; > . . . > function Cmplx(Re, Im : Real) return Complex; > function Re(C : Compex) return Real; > function Im(C : Compex) return Real; > type Imaginary is private; > i : constant Imaginary; -- This allows "3.5 + 4.0*i" notation > function "*"(L : Real; R : Imaginary) return Imaginary; > function "*"(L : Imaginary; R : Real) return Imaginary; > function "+"(L : Real; R : Imaginary) return Complex; > function "+"(L : Imaginary; R : Real) return Complex; > . . . > private > type Complex is record > Re, Im : Real; > end record; > type Imaginary is new Real; > end Complex_Numbers; >How would you write this in a "class-based" language? >At least in C++, operators almost always have to be made "friends" >to work right. No they don't. I suggest you look at the GNU g++ library implementation of complex, which I summarize below. Note that there are NO friend functions. There are differences, reflecting the differences between Ada's and C++'s approaches to types and differences in the approach to the implementation. On the other hand, Ada packages are analagous to providing a "friend" declaration between all types declared in the package. If "friends are so bad, then Complex and Imaginary should be in different packages so they can't get at each other's internals (which is basically what a C++ friend declaration does). NOTE: I've edited the following somewhat to remove inline function implementations and several of the operations. /* Copyright (C) 1988 Free Software Foundation written by Doug Lea (dl@rocky.oswego.edu) This file is part of GNU CC. */ class Complex { protected: // analagous to Ada's private part double re; double im; public: inline double real() const; // get real part of number inline double imag() const; // get imaginary part of number // Create a complex number inline Complex(); inline Complex(const Complex& y); inline Complex(double r, double i=0); // assignment inline Complex& operator = (const Complex& y); // Basic operations (add to number, subtract from number, etc). inline Complex& operator += (const Complex& y); inline Complex& operator += (double y); inline Complex& operator -= (const Complex& y); inline Complex& operator -= (double y); inline Complex& operator *= (const Complex& y); inline Complex& operator *= (double y); Complex& operator /= (const Complex& y); Complex& operator /= (double y); }; // Other operations on Complex. No friend functions needed. // Comparison operations. int operator == (const Complex& x, const Complex& y); int operator == (const Complex& x, double y); int operator != (const Complex& x, const Complex& y); int operator != (const Complex& x, double y); Complex operator - (const Complex& x); // negation Complex conj(const Complex& x); // conjugate // Arithmetic: Complex operator + (const Complex& x, const Complex& y); Complex operator + (const Complex& x, double y); Complex operator + (double x, const Complex& y); Complex operator - (const Complex& x, const Complex& y); Complex operator - (const Complex& x, double y); Complex operator - (double x, const Complex& y); // Similarly for *, /. // More complicated operations: Complex polar(double r, double t = 0.0); Complex cos(const Complex& x); Complex sin(const Complex& x); // (removed abs, norm, arg, sinh, cosh, exp, log, pow (power), sqrt). > So much for language-enforced encapsulation. And >here we have two types, Complex and Imaginary, that are interrelated, >and are naturally defined in a single package. One would >have to resort to "friends" or perhaps nesting in C++. I'm sure a C++ example could be created with classes Real, Imaginary, and Complex. There are also things which a C++ version could do and Ada can't. For instance, I don't think your Ada version as specified above allows assignment between types, in particular, how do I assign an imaginary value to a complex? Complex := Imaginary; -- type violation. Complex := Cmplx(Real, Imaginary); -- defined as Cmplx(Real, Real) Complex := (0, Imaginary); -- private type. I assume I have to get the package implementor to write a new function: function Cmplx(re: Real; Im: Imaginary) return Complex; Or alternately something like: Complex := Cmplx(Re, Real(Im)); -- use explicit conversion. ` -- can I do this to generics? >The C++ solution might nevertheless be quite elegant, if structured >properly according to reasonable coding guidelines, using the >file=module model where appropriate. But in this case, we see >that Ada provides better direct encapsulation support than does >a class-based language. And one could write a very poorly structured Ada implementation which violates package structures. You may have some protection above because the package is generic, I'm not familiar enough with Ada generics. I do agree that it's easier to create poorly packaged code in C++ than in Ada. From that standpoint Ada provides better encapsulation, but it's by no means ideal. There is also a problem discussed extensively in the Ada 9X materials about how to handle mixing operations of types Matrix and Vector, so Ada's encapsulation has it's problems also (this particular problem isn't easy in either class based languages like Eiffel or in C++ either, though solutions can be done in any of these langauges). >In any case, Ada 83 clearly chose the package-based approach, and >we are not trying to change that for Ada 9X. We felt that there >was no need to force Ada programmers to adopt a different way of >doing encapsulation just to get more support for dynamic binding >and type extension. Regardless of the above, you're right to maintain Ada's encapsulation philosophy. I don't like Ada's approach as much as some others, but there's nothing inherently wrong with it. >We don't see the need to make Ada 9X a "me too" object-oriented >language. Instead, we want it to combine the best ideas of >Ada 83 and OO languages, into something that advances the state >of the art, not something that trails just behind always trying >to catch up. We believe that this approach makes the most sense, >both technical, and marketing. Your mileage may of course vary... True, though I'm not sure Ada 9X is advancing the state of the art past other languages (personal opinion). >S. Tucker Taft stt@inmet.com >Ada 9X Mapping/Revision Team >Intermetrics, Inc. >Cambridge, MA 02138 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Encapsulation in Ada vs. C++ (Was Re: Ichibah [sic] ...) 1993-03-09 18:12 ` Tom Wicklund @ 1993-03-11 8:04 ` Magnus Kempe 1993-03-16 6:34 ` Dag Bruck 0 siblings, 1 reply; 25+ messages in thread From: Magnus Kempe @ 1993-03-11 8:04 UTC (permalink / raw) Taft showed how a package allows one to encapsulate _several_ types and their operations, providing such natural and efficient notations as "A := 2 + 3 * i;" ("A" is of type Complex and "i" is of type Imaginary; "+" and "*" are the operations). The crux of Taft's example is that Ada allows one to declare _several_ types _together_ and thus be able to easily provide an efficient subprogram operating on _several_ objects of _different_ types. All this can be achieved within a package with the safety provided by private types (since no one else is allowed to proclaim itself so "friendly" as to see the private parts of your package...). To achieve this, operators would have to be "friends" in C++, because of its equation "module = class"; however, the problem with such an approach is that _anyone_ can then claim to be a "friend", and therefore _anyone_ can break the abstraction of the class. C++ "friends" break the encapsulation and its equation becomes an approximation: "a class with friends is almost a module". wicklund@intellistor.com (Tom Wicklund) answered Taft with an irrelevant example: : : I suggest you look at the GNU g++ library implementation of complex, : which I summarize below. Note that there are NO friend functions. Of course, there are no friends in your C++ code (not repeated here), since the C++ class you included does _not_ propose _two_ types and operations working on objects of both types. (BTW, I'd rather see a discussion of principles with approriate examples; pouring hundreds of lines of C++ code in comp.lang.ada is uninteresting. Thank you.) To summarize, the crucial concepts involved are the following: we want a natural notation to declare several types and associated, efficient subprograms operating on several parameters of different types, and we want all this while preserving the abstraction in its encapsulation and type safety. Ada satisfies such software engineering requirements, and Ada 9X will soon provide still more programming power to satisfy still more software engineering requirements. (How great!) -- Magnus Kempe "No nation was ever drunk when wine was cheap." magnus@lglsun.epfl.ch -- Thomas Jefferson ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Encapsulation in Ada vs. C++ (Was Re: Ichibah [sic] ...) 1993-03-11 8:04 ` Encapsulation in Ada vs. C++ (Was Re: Ichibah [sic] ...) Magnus Kempe @ 1993-03-16 6:34 ` Dag Bruck 1993-03-16 7:51 ` Magnus Kempe 0 siblings, 1 reply; 25+ messages in thread From: Dag Bruck @ 1993-03-16 6:34 UTC (permalink / raw) In <comp.lang.ada> magnus@lglsun.epfl.ch (Magnus Kempe) writes: > >To achieve this, operators would have to be "friends" in C++, >because of its equation "module = class"; however, the problem >with such an approach is that _anyone_ can then claim to be a >"friend", and therefore _anyone_ can break the abstraction of >the class. This is incorrect. A class grants friendship to other functions or classes, which means that the author of a class controls who gets access to the private members of the class. You cannot grant yourself access to any random class. -- Dag Bruck ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Encapsulation in Ada vs. C++ (Was Re: Ichibah [sic] ...) 1993-03-16 6:34 ` Dag Bruck @ 1993-03-16 7:51 ` Magnus Kempe 1993-03-16 9:51 ` Dag Bruck 0 siblings, 1 reply; 25+ messages in thread From: Magnus Kempe @ 1993-03-16 7:51 UTC (permalink / raw) dag@control.lth.se (Dag Bruck) writes: : A [C++] class grants friendship to other functions or classes, which means : that the author of a class controls who gets access to the private : members of the class. You cannot grant yourself access to any random : class. If your class Foo grants "friendship" to a function/class Bar, _anyone_ can write such a function/class and, having granted itself "friendliness", will have access to the internals of Foo. To repeat: contrary to Ada, C++ does not provide a safe means to create subprograms acting on parameters of two or more types (classes). In C++, either you write an unsafe class because the language lacks the concept of a module, or you twist around with .h files and say good-bye to limited, separate recompilations. -- Magnus Kempe "No nation was ever drunk when wine was cheap." magnus@lglsun.epfl.ch -- Thomas Jefferson ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Encapsulation in Ada vs. C++ (Was Re: Ichibah [sic] ...) 1993-03-16 7:51 ` Magnus Kempe @ 1993-03-16 9:51 ` Dag Bruck 0 siblings, 0 replies; 25+ messages in thread From: Dag Bruck @ 1993-03-16 9:51 UTC (permalink / raw) In <comp.lang.ada> magnus@lglsun.epfl.ch (Magnus Kempe) writes: >dag@control.lth.se (Dag Bruck) writes: >: A [C++] class grants friendship to other functions or classes, which means >: that the author of a class controls who gets access to the private >: members of the class. You cannot grant yourself access to any random >: class. > >If your class Foo grants "friendship" to a function/class Bar, _anyone_ >can write such a function/class and, having granted itself "friendliness", >will have access to the internals of Foo. If we assume that the author of a class also writes the classes/functions he/she grants friendship, the "one definition rule" prohibits you from writing a second function or class with the same name. The alternative, that the author grants friendship without actually writing the friend classes/functions, seems highly unlikely. If you manipulate library files, for example, replace standard functions with functions you have written yourself, then you can of course get access to anything. You may also patch the symboltable or the objectcode itself. However, I doubt that Ada is safer in this respect. There is a much simpler way to break encapsulation (and I'm sure Magnus Kempe wants to hear it): write a your own class with the same contents and copy the bits from the protected object to a look-alike object with standard C function "memcpy". I doubt that "unsafe" features of this nature is of any real interest. Can anyone give a plausible example? -- Dag ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Ichibah flames, and flames out over, Ada 9X 1993-03-08 15:36 ` Tucker Taft 1993-03-08 16:28 ` Michael Feldman 1993-03-09 18:12 ` Tom Wicklund @ 1993-03-09 18:53 ` Larry M. Jordan 1993-03-09 20:24 ` David Weller 1993-03-16 17:34 ` Robert Firth 3 siblings, 1 reply; 25+ messages in thread From: Larry M. Jordan @ 1993-03-09 18:53 UTC (permalink / raw) I must agree with the recent posts that express concern over Ada 9X's OOP features not be recognized as such. I'm not an 'average' programmer (I know Ada, C++, Turbo Pascal, a number of Modula-2s with OOP, Oberon-2). Yet, I had no little difficulty reading the Ada 9X rationale and understanding just how 9X will support OOP. I think introducing the keyword 'tagged' is a mistake. It sure didn't facilitate my understanding. It wasn't until I read the paper by Dismukes and Rome that I realized, 'Oh, this isn't so different after all.' My impression (and it may be only mine) is that 'tagged' is an implementation detail that has somehow leaked out. What an ugly word it is (and how many times will it be misspelled!--one 'g' or two?). Ichbiah's suggestion seems preferable. There will probably be better sources for learning Ada 9X OOP features (there probably are now). But at the time, the rationale was all I had. Maybe a book/monograph needs to be written that's palatable to the pop programming culture, speaking to them at their level, an 'Ada 9X Primer'?! Until there is, I'm afraid that Ada 9X OOP will be preceived as something 'unfamiliar'. --Larry ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Ichibah flames, and flames out over, Ada 9X 1993-03-09 18:53 ` Ichibah flames, and flames out over, Ada 9X Larry M. Jordan @ 1993-03-09 20:24 ` David Weller 1993-03-09 21:03 ` Michael Feldman 0 siblings, 1 reply; 25+ messages in thread From: David Weller @ 1993-03-09 20:24 UTC (permalink / raw) In article <1nip3kINNb2c@news.aero.org> jordan@aero.org (Larry M. Jordan) writes: >I must agree with the recent posts that express concern over >Ada 9X's OOP features not be recognized as such. I'm not an >'average' programmer (I know Ada, C++, Turbo Pascal, a number >of Modula-2s with OOP, Oberon-2). Yet, I had no little difficulty >reading the Ada 9X rationale and understanding just how 9X will >support OOP. > Indeed, it IS a nontrivial document aimed at the Ada fluent (and C++/CLOS/Smalltalk fluent, to a degree). I'm not so sure this makes it a Bad Thing. There has been considerable discussion about simplifying the Rationale (right, Tuck?). >I think introducing the keyword 'tagged' is a mistake. It sure >didn't facilitate my understanding. It wasn't until I read >the paper by Dismukes and Rome that I realized, 'Oh, this >isn't so different after all.' My impression (and it may be only >mine) is that 'tagged' is an implementation detail that has >somehow leaked out. What an ugly word it is (and how many times >will it be misspelled!--one 'g' or two?). Ichbiah's suggestion >seems preferable. > Yeah, and I've lost count of how many Ada programmers I've taught that can't spell seperate(sic) :-) Tucker would be quick to point out that the word "record" is also an implementation detail, but that it's become generally accepted in the programming domain. Frankly, I don't care for the word "tagged" either, but "class" doesn't fit in its place. Do you have an alternate suggestion? One other thing that's bothered me -- why are we raising such a fuss about the word "tagged" to mean "this record may have it's state description extended"? Perhaps we're being pedantic? Where were such arguments when the "C" language reference said "*" means "pointer"? :-) (Smiley for the humor impaired) >There will probably be better sources for learning Ada 9X OOP >features (there probably are now). But at the time, the rationale was >all I had. Maybe a book/monograph needs to be written that's palatable >to the pop programming culture, speaking to them at their level, an >'Ada 9X Primer'?! Until there is, I'm afraid that Ada 9X OOP >will be preceived as something 'unfamiliar'. > If you'll look in the Ada 9X Project Plan (whatever), you'll see there's TWO 9X primers: one for the Ada literate and one for the "Real Language" impaired :-) I believe there's also a plan for video tapes (hopefully it will be a little more lively than the ones Alsys sold back in the mid 80's). I'm not sure of the release dates for the primers, but I'm sure it won't be before the ANSI acceptance of 9X. >--Larry > dgw ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Ichibah flames, and flames out over, Ada 9X 1993-03-09 20:24 ` David Weller @ 1993-03-09 21:03 ` Michael Feldman 1993-03-12 14:49 ` Tucker Taft 0 siblings, 1 reply; 25+ messages in thread From: Michael Feldman @ 1993-03-09 21:03 UTC (permalink / raw) In article <1993Mar9.152454.739@sei.cmu.edu> wellerd@ajpo.sei.cmu.edu (David Weller) writes: > >If you'll look in the Ada 9X Project Plan (whatever), you'll >see there's TWO 9X primers: one for the Ada literate and one for >the "Real Language" impaired :-) I believe there's also a >plan for video tapes (hopefully it will be a little more lively >than the ones Alsys sold back in the mid 80's). I'm not sure >of the release dates for the primers, but I'm sure it won't be before >the ANSI acceptance of 9X. > Ummm - anyone know who's writing it? Mike ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Ichibah flames, and flames out over, Ada 9X 1993-03-09 21:03 ` Michael Feldman @ 1993-03-12 14:49 ` Tucker Taft 1993-03-12 23:54 ` Michael Feldman 0 siblings, 1 reply; 25+ messages in thread From: Tucker Taft @ 1993-03-12 14:49 UTC (permalink / raw) In article <1993Mar9.210350.14567@seas.gwu.edu> mfeldman@seas.gwu.edu (Michael Feldman) writes: >In article <1993Mar9.152454.739@sei.cmu.edu> > wellerd@ajpo.sei.cmu.edu (David Weller) writes: >> >>If you'll look in the Ada 9X Project Plan (whatever), you'll >>see there's TWO 9X primers: one for the Ada literate and one for >>the "Real Language" impaired :-) I believe there's also a >>plan for video tapes (hopefully it will be a little more lively >>than the ones Alsys sold back in the mid 80's). I'm not sure >>of the release dates for the primers, but I'm sure it won't be before >>the ANSI acceptance of 9X. >> >Ummm - anyone know who's writing it? John Barnes is working on the 9X Rationale these days, with help from other members of the Mapping/Revision Team. Some version of the rationale will accompany the documents circulated for ANSI Canvass/ISO balloting. Several video tapes will be produced, some (short) "glossy" ones for CEOs, CIOs, chief technical officers, etc., and some (longer) "pragmatic" ones for programmers, both Ada 83 and C/C++ types. These will probably not be ready until after the balloting process is nearly complete. >Mike S. Tucker Taft stt@inmet.com Ada 9X Mapping/Revision Team Intermetrics, Inc. Cambridge, MA 02138 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Ichibah flames, and flames out over, Ada 9X 1993-03-12 14:49 ` Tucker Taft @ 1993-03-12 23:54 ` Michael Feldman 0 siblings, 0 replies; 25+ messages in thread From: Michael Feldman @ 1993-03-12 23:54 UTC (permalink / raw) In article <1993Mar12.144940.18386@inmet.camb.inmet.com> stt@spock.camb.inmet.com (Tucker Taft) writes: [stuff deleted] > >John Barnes is working on the 9X Rationale these days, >with help from other members of the Mapping/Revision Team. >Some version of the rationale will accompany the documents >circulated for ANSI Canvass/ISO balloting. > A Rationale is fine, but the original question asked about the promise of _primers_ written to _teach_ 9X. This has been promised in the last few versions of the transition plan. Is this happening? (I can tell you for sure that nobody has asked _me_ to write it :-)) Mike Feldman ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Ichibah flames, and flames out over, Ada 9X 1993-03-08 15:36 ` Tucker Taft ` (2 preceding siblings ...) 1993-03-09 18:53 ` Ichibah flames, and flames out over, Ada 9X Larry M. Jordan @ 1993-03-16 17:34 ` Robert Firth 3 siblings, 0 replies; 25+ messages in thread From: Robert Firth @ 1993-03-16 17:34 UTC (permalink / raw) In article <1993Mar8.153639.3603@inmet.camb.inmet.com> stt@spock.camb.inmet.com (Tucker Taft) writes: >So for some cases, where most operations have only a single >"interesting" parameter, the class-based approach seems more direct. >In other cases (like the above), the package-based approach >seems more direct and supportive of encapsulation. Thanks, Tucker, and I agree. Those enamoured of formality might like to revisit Part I and the first half of Part II of Russell and Whitehead's 'Principia Mathematica'. They discuss at great length the same issue in formal logic: whether relations between two different classes can be represented adequately in terms of attributes of one class or the other. The answer, not surprisingly, is yes, for special cases, but no, for the general case. In these terms, the class/attribute model represents a reversion to the Aristotelian approach, where the only relations are predication and inclusion. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Encapsulation in Ada vs. C++ (Was Re: Ichibah [sic] ...) @ 1993-03-16 22:37 John Goodsen 0 siblings, 0 replies; 25+ messages in thread From: John Goodsen @ 1993-03-16 22:37 UTC (permalink / raw) magnus@lglsun.epfl.ch (Magnus Kempe) writes: > >If your class Foo grants "friendship" to a function/class Bar, _anyone_ >can write such a function/class and, having granted itself "friendliness", >will have access to the internals of Foo. > Oh my! And shame, shame, shame on you for even thinking imitating my "BAR". This argument is remeniscent of the facist arguments which have the common theme of "you might use it wrong, therefore I want to keep you from using it at all". BTW, you won't get too far in the link stage with both "BAR"s in the system (multiply defined identifiers and such..) > >To repeat: contrary to Ada, C++ does not provide a safe means to create >subprograms acting on parameters of two or more types (classes). In >C++, either you write an unsafe class because the language lacks the >concept of a module, or you twist around with .h files and say good-bye >to limited, separate recompilations. > "UNSAFE CLASS" ??? Huh? Come now! "friendship" is not necessarily unsafe. Only if you use it wrong. True, Ada packaging and "classtypes" (I refuse to use tagged type syntax anymore ;-) overcome this *perceived* defect in C++, but to *twist* the truth in suggesting that you lose separate recompilations is not responsible. In fact to the contrary, the *friend* concept allows for separate recompilation of these related classes and functions. Ada packages *REQUIRE* recompilation of all related "classtypes" (there it is again, isn't it a pretty syntax ;-), since they're in the same package. -- John Goodsen Software Process & Environments EVB Software Engineering jgg@evb.com ^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~1993-03-16 22:37 UTC | newest] Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1993-03-07 19:15 Ichibah flames, and flames out over, Ada 9X John Goodsen 1993-03-08 0:45 ` David Emery 1993-03-08 15:36 ` Tucker Taft 1993-03-08 16:28 ` Michael Feldman 1993-03-08 22:15 ` Gregory Aharonian 1993-03-09 14:20 ` Tucker Taft 1993-03-09 14:55 ` C. Michael Holloway 1993-03-10 14:51 ` Gregory Aharonian 1993-03-09 17:12 ` Harry Koehnemann 1993-03-09 20:54 ` Michael Feldman 1993-03-09 20:14 ` Larry M. Jordan 1993-03-09 17:49 ` Harry Koehnemann 1993-03-09 21:01 ` Michael Feldman 1993-03-09 18:12 ` Tom Wicklund 1993-03-11 8:04 ` Encapsulation in Ada vs. C++ (Was Re: Ichibah [sic] ...) Magnus Kempe 1993-03-16 6:34 ` Dag Bruck 1993-03-16 7:51 ` Magnus Kempe 1993-03-16 9:51 ` Dag Bruck 1993-03-09 18:53 ` Ichibah flames, and flames out over, Ada 9X Larry M. Jordan 1993-03-09 20:24 ` David Weller 1993-03-09 21:03 ` Michael Feldman 1993-03-12 14:49 ` Tucker Taft 1993-03-12 23:54 ` Michael Feldman 1993-03-16 17:34 ` Robert Firth -- strict thread matches above, loose matches on Subject: below -- 1993-03-16 22:37 Encapsulation in Ada vs. C++ (Was Re: Ichibah [sic] ...) John Goodsen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox