home *** CD-ROM | disk | FTP | other *** search
/ Programmer's ROM - The Computer Language Library / programmersrom.iso / ada / educ / compools.doc < prev    next >
Encoding:
Internet Message Format  |  1988-05-03  |  6.6 KB
  1. Date: 26 Dec 1986 03:14:33 PST
  2. Subject: We're getting there - slowly
  3. From: Edward V. Berard <EBERARD@ADA20.ISI.EDU>
  4.  
  5.  
  6. Until November of 1982, I was violently anti-Ada. I had heard the
  7. arguments of C.A.R. Hoare, and had agreed with them somewhat, but that
  8. was not the main reason for my objections to the introduction of the
  9. language.
  10.  
  11. Since 1978, I have provided training and consulting to clients in the
  12. U.S., Canada, Europe, and Japan. These services were software
  13. engineering related, i.e., they covered topics from programming
  14. languages to structured methodologies to software engineering
  15. management to computer hardware. A great deal of my work required that
  16. I travel to the location of my clients. Since 1978, I have been to
  17. literally hundreds of different shops, and have talked to literally
  18. thousands of programmers and managers.
  19.  
  20. What I saw had a profound impact on me. Before I began this work, I
  21. was under the false impression that there was little difference
  22. between the state-of-the-art and the state-of-the-practice in software
  23. engineering. I was very wrong. A majority of the people that I saw
  24. were very poorly trained -- managers *and* programmers. Those that had
  25. even a glimmer of an idea of what sound software engineering entailed
  26. were often (but not always) restricted by poor management, buyer
  27. indifference, contracting office stupidity, and a very entrenched "old
  28. guard."
  29.  
  30. "Most programmers and managers can't get out of the way of their own
  31. two feet with languages like COBOL and FORTRAN.", I argued, "... and
  32. you're going to give them Ada? ... a language that makes PL/I look
  33. like BASIC!" 
  34.  
  35. What changed my mind was a presentation I attended given by Larry
  36. Druffel, then director of the Ada Joint Program Office. He said
  37. something that shocked me. The Department of Defense was not merely
  38. introducing a new programming language, he said. The DoD realized that
  39. it would be sound software engineering practice, *not the simple
  40. introduction of yet another programming language*,that would help
  41. alleviate the proverbial software crisis. The DoD was talking about
  42. items like STARS, the Software Engineering Institute, Ada Programming
  43. Support Environments, Educationman (now ASEET), Methodman, and others.
  44. The message was software engineering, not the syntax and semantics of
  45. Ada.
  46.  
  47. In the four years since I heard Larry Druffel give that presentation
  48. things have changed dramatically. Yet there has been relatively little
  49. movement on the most important issue. Many people seem to think that
  50. the most important issue regarding Ada technology is the syntax and
  51. semantics of the language itself. Programs like STARS seem to be in
  52. trouble. Far too many managers and programmers think that all that is
  53. required is "a week or two of hands-on training in the syntax of the
  54. language." Contracting offices still fill requests for proposal with
  55. meaningless "buzzwords."
  56.  
  57. Yes, I know the message is getting through very slowly. Eventually
  58. both the government and software practitioners will stop "shooting
  59. themselves in the foot" with such predictability. I also know that the
  60. vast majority of these people are not stupid, just horribly misguided.
  61. We all want to do the best job possible. 
  62.  
  63. What set me off on this tirade? An electronic mail message informed me
  64. today that the Ada Software Repository had accepted a contribution
  65. which would allow Ada programmers to mimic FORTRAN's common blocks.
  66. Almost two decades ago, IBM researchers (e.g., Larry Constantine)
  67. showed the damage that "global data" could do to a system.
  68.  
  69. Without sound software engineering behind it, and the presence of an
  70. "Ada mindset," Ada is an accident looking to happen. Please do not try
  71. to duplicate the software engineering mistakes of FORTRAN, COBOL, C,
  72. Pascal, and assembly language in the Ada language.
  73.  
  74. But not to worry. Ada compilers are inanimate objects. When the
  75. project blows up, you can always blame Ada. Now what was that about a
  76. poor workman blaming his or her tools?
  77.                 -- Ed Berard
  78.                    (301) 695-6960
  79. --------
  80. Date:    Tue, 30 Dec 86 01:50:48 PST
  81. From:     larry@Jpl-VLSI.ARPA
  82. Subject: Globals + Texts + Simplicity
  83.  
  84. GLOBAL DATA AND SW ENG  The only reason I can see for Ada versions of ForTran
  85.                         COMMON or HAL/S COMPOOLS is for quick one-for-one
  86. translations of code from ForTran or HAL/S to Ada.  If one needs global data
  87. there are better ways to do it.  Norm Cohen discusses this at length (with
  88. appropriate cautions) in his _Ada_as_a_Second_Language_.  See especially
  89. pages 293-7 and 370-3. 
  90.  
  91. There are times, of course, when global data is an optimal solution to a 
  92. problem.  It's the nature of any kind of engineering that trade-offs always 
  93. have to be made.  But the number of people with SW responsibilities who 
  94. don't have any SW engineering knowledge is a national disgrace shared 
  95. equally by education and industry.  I find it sourly ironic that the 
  96. military--supposedly the least foward-looking, "with-it" American 
  97. institution--is the biggest supporter of SW engineering.
  98.  
  99. BEGINNING TEXTS         Cohen's book has two notably useful features.  All 
  100.                         chapters have a Summary section; some of the more
  101. difficult ones have a Details section which can be skipped by those who need
  102. a less complete discussion of the topic.  Later one can make a second pass
  103. over the book, reading the details sections for a more complete understanding. 
  104.  
  105. Further, there's a lot of pragmatic advice about how to use language 
  106. features.   This makes for a book of 800+ pages, but the advice (and the 
  107. examples and clear writing) actually makes it easier to read than shorter 
  108. books, because it gives a context for the parts of Ada.
  109.  
  110. ADA A SIMPLE LANGUAGE?  Ed made a comment that reminded me of what I consider 
  111.                         a myth: Ada's complexity.  We always over-estimate
  112. the complexity of a familiar language and under-estimate the one(s) in which
  113. we're expert.  (The fish-in-water syndrome.) And until the last year or two
  114. there weren't very many validated compilers around for people to use.  So the
  115. viewpoint we got was that of the designers or implementors, which is very
  116. different from (what is becoming) the typical user. 
  117.  
  118. I suspect that in a few more years we'll be hearing a new cliche: that Ada
  119. is SIMPLER to use than previous languages.  For, after internalizing the Ada
  120. mind-set and developing a reflexive mastery of its syntax, the user can
  121. forget about bits, bytes, subprograms, and data (at least until it becomes
  122. time to do trade-offs and optimizations).  Instead, s/he'll write programs
  123. using elements in the problem domain. 
  124.                                             Larry @ jpl-vlsi.arpa
  125.  
  126.  
  127.