home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / ada / 4105 < prev    next >
Encoding:
Text File  |  1993-01-28  |  8.2 KB  |  162 lines
  1. Newsgroups: comp.lang.ada
  2. Path: sparky!uunet!ukma!usenet.ins.cwru.edu!magnus.acs.ohio-state.edu!cis.ohio-state.edu!news.sei.cmu.edu!ajpo.sei.cmu.edu!brosgol
  3. From: brosgol@ajpo.sei.cmu.edu (Benjamin Brosgol)
  4. Subject: Ada / C++ Panel at ASEET
  5. Message-ID: <1993Jan28.100616.3184@sei.cmu.edu>
  6. Sender: netnews@sei.cmu.edu (Netnews)
  7. Organization: Software Engineering Institute
  8. Date: Thu, 28 Jan 1993 10:06:16 EST
  9. Lines: 151
  10.  
  11. Recent messages have asked for a summary of the Ada / C++ panel that was
  12. held at the ASEET Symposium (Ada Software Engineering Education and
  13. Training) earlier this month, at Naval Postgraduate School in Monterey.  I
  14. was there; here's my of course impartial summary of what happened.
  15.  
  16. The scheduled panelists were Ed Schonberg and Robert Dewar from NYU, Jerry
  17. Schwartz from Lucid, Inc. (a company that sells C++ products), and Greg
  18. Aharonian from comp.lang.ada.  (OK, he's officially from Source Translation
  19. & Optimization, but most of you probably know him from his postings to
  20. this newsgroup.)  Unfortunately, Greg was not able to attend; that was
  21. really too bad, for several reasons.  First, it made poor Jerry rather
  22. outnumbered.  He was already feeling like an outsider at an Ada conference,
  23. and having to stand alone against some of the Ada community's most
  24. articulate and knowledgeable representatives is not for the faint of heart.
  25. Second, the more blood-pressure-raising issues in the Ada / C++ debate are
  26. socio/political/economic rather than technical.  Greg has certainly
  27. stressed these points on comp.lang.ada, and it would have been interesting
  28. hearing him in a forum where there were DoD representatives present.  He
  29. even could have walked around without an escort.
  30.  
  31. The conference organizers had cleverly scheduled the panel for the last
  32. session, figuring that the topic and the reputation of the speakers would
  33. convince attendees to stay around.  They were right; not even the
  34. competition from the week's first rays of sunshine could keep people away,
  35. and the panel did not disappoint.
  36.  
  37. Ed Schonberg gave a summary of the relative technical merits of C++ and Ada
  38. 9X.  Looking at the development of C++, he observed that V1 was a better C
  39. with classes; V2 added multiple inheritance; and V3.5 is introducing
  40. templates and exceptions.  Ada 9X may be viewed as Ada 83 plus classes
  41. (single inheritance), hierarchical libraries, protected types, and flexible
  42. scheduling.  He cited the following as advantages of Ada:
  43.    *   Type safety
  44.    *   Integrated library (versus .h files and make)
  45.    *   Integrated tasking (versus, say, Posix)
  46.    *   Existence as ISO standard [this applies at present to Ada 83,
  47.        not yet for Ada 9X]
  48.    *   Readability / maintainability
  49.    *   Benefits over the life cycle
  50. [Note: I am not trying to instigate a flame war on these points.  I know
  51. that some would argue violently that Ada's inclusion of tasking is a
  52. disadvantage rather than an advantage, that C++ is at least as maintainable
  53. as Ada, etc.  I'm just trying to report what the speaker said.]
  54.  
  55. Ed cited the following reasons for C++'s popularity:
  56.    *   It's a better C, and it satisfies the needs of an eager culture
  57.    *   Large amount of software capital
  58.    *   Less expensive compilers than for Ada
  59.    *   Object-Oriented features
  60.    *   Simpler system interfaces
  61.  
  62. He then looked in particular at the issue of Multiple Inheritance ("MI"),
  63. which some may feel is an area where C++ has more expressive power than 
  64. Ada 9X.  But he observed that the "mixin" model may be achieved in Ada 9X 
  65. via generics, formal packages, and access discriminants, and that the other
  66. applications of MI can also be realized directly.  Thus there is no loss of
  67. expressive power, and omitting MI language features avoids semantic and
  68. implementation complexity.
  69.  
  70. Jerry Schwartz then presented the C++ side.  He identified a number of
  71. issues where language designers have a range of alternatives, and
  72. contrasted the approaches taken in Ada and in C++:
  73.  
  74.    Static versus dynamic type system: C++ is more dynamic than Ada.
  75.  
  76.    Procedural (imperative) versus function model: C++ is more functional
  77.  
  78.    Permissiveness versus safety: C++ is more permissive, but Ada has a
  79.    major loophole in its access type mechanism since it requires
  80.    Unchecked_Deallocation if the programmer needs to assure storage
  81.    reclamation.
  82.  
  83.    High versus low level: C++ is lower level
  84.  
  85. He noted that Ada 9X and C++ are roughly equivalent with respect to the
  86. features they provide.  The major exceptions to this equivalence are
  87. Ada's omission of MI, and C++'s omission of tasking.  Regarding MI, he
  88. acknowledged the implementation difficulties and conceded that the
  89. complexity might not be worth it.  He also pointed out that namespace
  90. issues are currently an active item of discussion in the C++ community (for
  91. example, dealing with duplication of names in multiple libraries).
  92.  
  93. In the area of culture and environment, Jerry noted that C++ has several
  94. advantages over Ada: programmer familiarity, tool availability, and the
  95. existence of libraries.  He related that his company started as a LISP
  96. supplier but moved to C++ based on market issues.  He compared the
  97. development of C++ to that of Ada.  C++ was basically designed by
  98. B. Stroustrup on his own, as an increment from C.  The development was
  99. carried out somewhat in a "spiral" approach: design a little, implement,
  100. try it, design a little more, implement, etc., with standardization
  101. deferred until after there is user and implementor experience.
  102. A disadvantage of this approach is that "nothing comes out".  Once a 
  103. user has produced code exploiting a particular feature, "upward 
  104. compatibility" becomes a strong influence.  Ada, on the other hand,
  105. proceeded with formal requirements, then a design/review phase, then
  106. standardization, and finally implementation and user experience.  Jerry
  107. observed that Ada's path was very much like the traditional (and now much-
  108. maligned) "waterfall" model.  He concluded by remarking that "C++ is
  109. nobody's first choice but everybody's second choice."
  110.  
  111. The final presenter was Robert Dewar.  His basic point was the observation
  112. of a major philosophical difference between Ada and C++: C++ is more
  113. regular, at the price of language "pitfalls", whereas Ada does not mind
  114. having special case rules in order to avoid unpleasant run-time surprises.
  115. He cited several examples from Horstman's book, "Mastering C++", to
  116. illustrate such pitfalls.  He also noted that programmers from the C and
  117. C++ culture are accustomed to using a debugger to find "off by 1" errors,
  118. whereas in Ada the language syntax make such errors less likely.
  119.  
  120. Discussion of the role of syntax and language rules in program reliability
  121. led to some debate on the blame for the phone system crash in early 1990.  
  122. The bug was traced to a piece of C code that had the following structure:
  123.  
  124.    switch (expr) {
  125.       ...
  126.       case ... : { ...
  127.                    if (...) {
  128.                       ...
  129.                       break;
  130.                    }
  131.                    ...
  132.                   }
  133.  
  134. The programmer had intended that the "break" transfer control out of the
  135. "if" statement.  But that's not C semantics; instead, control broke out of
  136. the enclosing "switch".  One could argue that this bug is evidence of
  137. (1) defective language design, (2) programmer ignorance, (3) lack of adequate
  138. testing, or some combination of these.  Ada apologists tend to focus on (1);
  139. C champions say it's the programmer's and not the language's fault.  
  140. [This point has in fact been argued before on this newsgroup, so please let's
  141. not resurrect the debate.  I am just trying to report what happened at the
  142. panel.  My own opinion on this example is that the responsibility/blame
  143. goes much more to the programmer than to the language design.  "Read The
  144. Friendly Manual" is the expression that comes to mind.]
  145.  
  146. The panelists did not have formal papers or position statements in the
  147. published proceedings of the conference.  For further information, you may
  148. find the following references helpful:
  149.  
  150. E. Schonberg, "Contrasts: Ada 9X and C++", in CrossTalk, The Journal of
  151. Defense Software Engineering, Number 36, September 1992.
  152.  
  153. L. S. Tang, "A Comparison of Ada and C++", in Proc. TRI-Ada '92, ACM
  154. SIGAda, November 1992.
  155.  
  156. S. T. Taft, "Multiple Inheritance in Ada 9X", in CrossTalk, Number 38,
  157. November 1992.
  158.  
  159. -------------------
  160. Ben Brosgol
  161. brosgol@ajpo.sei.cmu.edu
  162.