home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / ada / 3760 < prev    next >
Encoding:
Internet Message Format  |  1992-12-20  |  5.5 KB

  1. Path: sparky!uunet!munnari.oz.au!goanna!ok
  2. From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
  3. Newsgroups: comp.lang.ada
  4. Subject: Re: C++ vs. Ada -- Is Ada loosing?
  5. Message-ID: <16269@goanna.cs.rmit.oz.au>
  6. Date: 18 Dec 92 04:06:02 GMT
  7. References: <1992Dec4.141816.1@happy.colorado.edu^<11330@prijat.cs.uofs.edu> <172@fedfil.UUCP>
  8. Organization: Comp Sci, RMIT, Melbourne, Australia
  9. Lines: 91
  10.  
  11. In article <172@fedfil.UUCP>, news@fedfil.UUCP (news) writes:
  12. > The more I think about it, Ada (safe, sane....) reminds me of the Volvo.
  13. > You see all those advertisements for Volvos tauting safety features, and
  14. > they never mention the best safety feature, i.e. the fact that they usually
  15. > don't run and you can only hurt yourself so badly sitting under a tree
  16. > in a car.  
  17.  
  18. I have deleted the rest of Holden's flame.  Let me offer a data point.
  19. Just recentrly, I posted an article to comp.lang.c in which I listed a
  20. number of errors in a textbook.  The textbook is about data structures
  21. in C.  The authors understand data structures very well.
  22.     Author X "is chair of the CS dept and Professor of CS&EE at
  23.     <famous university>.  [He] has published 30 proceedings, managed
  24.     research grants totalling over US$3.5 million, ... "
  25.     Author Y "is Professor of CS in <not so famous university but I've
  26.     heard of it even here>.  [He] has published over 140 articles and 
  27.     has written several texts.  He is an editor of four professional
  28.     journals and has managed over US$8 million in research grants."
  29.     Author Z "is chair of <a third good university>'s CS dept and a
  30.     veteran of 14 years of teaching."
  31. The authors thank Profesor P, Dr Q, and Messrs R & S for "debugging"
  32. the book.  They also thank Mr T of AT&T Bell Labs (who has written
  33. several books on C himself) for reviewing the manuscript.
  34.  
  35. Sounds good, no?  The authors also say that the code in the book is not
  36. specially typeset because every example has been tested, and they didn't
  37. want to introduce any errors.
  38.   
  39. On p6 they write "all programs in this book follow the rules of ANSI C".
  40. The first example is on p7, facing this claim, and it contains an OBVIOUS
  41. violation of the ANSI standard, and a known portability problem (which
  42. X3J11 invented a new macro for the express purpose of fixing), and calls
  43. an operation which may fail without checking whether it succeeded.  The
  44. last example in the book has a type error, and the authors' only comment
  45. is to say that the compiler's error message can be ignored.
  46.  
  47. In my posting in comp.lang.c I described (with page numbers) several other
  48. mistakes.  My personal favourite is one which appears to reveal a fairly
  49. basic misunderstanding about C scope rules. There are others which should
  50. never have been accepted by any C compiler, although they are legal C++.
  51.  
  52. Many of the problems are potentially serious.  As it happens, with the
  53. exception of the scope problem, GCC or an ANSI lint _would_ catch all of
  54. them.  But Professors X, Y, and Z "tested" their programs under an awesome
  55. total of two compilers, which evidently did _not_ catch these errors.
  56.  
  57. I can never quite remember the line in "Life, the Universe, and Everything."
  58. "Don't worry, Arthur Dent ............... be very very frightened."
  59.  
  60. You see, I had been talking with a publisher's representative, and had
  61. complained about another publisher's recent book which had about one
  62. factual error every two pages.  The publisher's representative said, "well,
  63. OURS are checked.  I'll send you one I think you'll be able to use."
  64. Well, no, I can't.  I think my students are better off being shown how to
  65. write CORRECT C code for a smaller variety of data structures than
  66. INCORRECT C code for an impressive range of data structures.  I also think
  67. that a textbook that TALKS so much about abstract data types should teach
  68. students to DO it, but although it is easy to define a stack type in C
  69. so that a program using it has no clue about the implementation, the code
  70. in this book just isn't like that.  The authors never even mention how to
  71. use header files to get modular code.
  72.  
  73. Am I worried about C, when experienced people who are managing huge
  74. amounts of money (once upon I time I paid US taxes, some of that was
  75. my money) manifestly don't understand C, even though they imagine they
  76. think they understand it well enough to instruct others?
  77. Worried?  No.
  78.  
  79. I'm very very frightened.
  80.  
  81. I believe that Ada is a bigger language than C.  Both languages have "dark
  82. corners".  But there seems to be a tradition of Ada compilers being picky
  83. and C compilers letting it all hang out.  With all due respect to "The
  84. Emperor's New Clothes", which I loved when it came out, I am now _more_
  85. frightened about critical software being written in C or C++ than in Ada.
  86.  
  87. This is actually an important point.  A programming language is more than
  88. a standard.  There is also a tradition, a way of approaching the language.
  89. (It's something I have observed about Prolog:  if you plug into the
  90. Edinburgh _tradition_, Prolog is a simple, comprehensible, and powerful
  91. tool, but if you just look at a manual, most people never learn how to
  92. use it effectively, and that most especially applies to the authors of
  93. textbooks about it.)  It would be perfectly possible to have an "Ada"
  94. compiler which was as sloppy as a C compiler, and it is possible to have
  95. C systems which are very strict.
  96.  
  97. My current impression is that Ada textbooks tend to be more accurate in
  98. the claims they make about what is or is not valid Ada, and tend to have
  99. a higher level view of the software process, than C books.  Is this an
  100. illusion, due to my knowing C relatively better than I know Ada?
  101.  
  102.