EBERARD@ADA20.ISI.EDU (Edward V. Berard) (12/26/86)
Until November of 1982, I was violently anti-Ada. I had heard the arguments of C.A.R. Hoare, and had agreed with them somewhat, but that was not the main reason for my objections to the introduction of the language. Since 1978, I have provided training and consulting to clients in the U.S., Canada, Europe, and Japan. These services were software engineering related, i.e., they covered topics from programming languages to structured methodologies to software engineering management to computer hardware. A great deal of my work required that I travel to the location of my clients. Since 1978, I have been to literally hundreds of different shops, and have talked to literally thousands of programmers and managers. What I saw had a profound impact on me. Before I began this work, I was under the false impression that there was little difference between the state-of-the-art and the state-of-the-practice in software engineering. I was very wrong. A majority of the people that I saw were very poorly trained -- managers *and* programmers. Those that had even a glimmer of an idea of what sound software engineering entailed were often (but not always) restricted by poor management, buyer indifference, contracting office stupidity, and a very entrenched "old guard." "Most programmers and managers can't get out of the way of their own two feet with languages like COBOL and FORTRAN.", I argued, "... and you're going to give them Ada? ... a language that makes PL/I look like BASIC!" What changed my mind was a presentation I attended given by Larry Druffel, then director of the Ada Joint Program Office. He said something that shocked me. The Department of Defense was not merely introducing a new programming language, he said. The DoD realized that it would be sound software engineering practice, *not the simple introduction of yet another programming language*,that would help alleviate the proverbial software crisis. The DoD was talking about items like STARS, the Software Engineering Institute, Ada Programming Support Environments, Educationman (now ASEET), Methodman, and others. The message was software engineering, not the syntax and semantics of Ada. In the four years since I heard Larry Druffel give that presentation things have changed dramatically. Yet there has been relatively little movement on the most important issue. Many people seem to think that the most important issue regarding Ada technology is the syntax and semantics of the language itself. Programs like STARS seem to be in trouble. Far too many managers and programmers think that all that is required is "a week or two of hands-on training in the syntax of the language." Contracting offices still fill requests for proposal with meaningless "buzzwords." Yes, I know the message is getting through very slowly. Eventually both the government and software practitioners will stop "shooting themselves in the foot" with such predictability. I also know that the vast majority of these people are not stupid, just horribly misguided. We all want to do the best job possible. What set me off on this tirade? An electronic mail message informed me today that the Ada Software Repository had accepted a contribution which would allow Ada programmers to mimic FORTRAN's common blocks. Almost two decades ago, IBM researchers (e.g., Larry Constantine) showed the damage that "global data" could do to a system. Without sound software engineering behind it, and the presence of an "Ada mindset," Ada is an accident looking to happen. Please do not try to duplicate the software engineering mistakes of FORTRAN, COBOL, C, Pascal, and assembly language in the Ada language. But not to worry. Ada compilers are inanimate objects. When the project blows up, you can always blame Ada. Now what was that about a poor workman blaming his or her tools? -- Ed Berard (301) 695-6960 -------
Makey@LOGICON.ARPA (Jeff Makey) (12/30/86)
>the Ada Software Repository had accepted a contribution >which would allow Ada programmers to mimic FORTRAN's common blocks. As the saying goes: "Real Programmers can write FORTRAN code in any language." :-) :: Jeff Makey Makey@LOGICON.ARPA