From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,54889de51045a215 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-10-20 10:10:13 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!newsfeed.mathworks.com!wn13feed!wn11feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi.com!rwcrnsc54.POSTED!not-for-mail Message-ID: <3F9416D8.30001@comcast.net> From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: += in ada References: <1066224357.499523@master.nyc.kbcfp.com> <1066231159.711433@master.nyc.kbcfp.com> <1066311805.222491@master.nyc.kbcfp.com> <3F8F3077.60402@comcast.net> <3F900F35.50203@comcast.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit NNTP-Posting-Host: 24.34.139.183 X-Complaints-To: abuse@comcast.net X-Trace: rwcrnsc54 1066669812 24.34.139.183 (Mon, 20 Oct 2003 17:10:12 GMT) NNTP-Posting-Date: Mon, 20 Oct 2003 17:10:12 GMT Organization: Comcast Online Date: Mon, 20 Oct 2003 17:10:12 GMT Xref: archiver1.google.com comp.lang.ada:1212 Date: 2003-10-20T17:10:12+00:00 List-Id: Russ wrote: > At some point one must ask *why* Ada is so unpopular, despite the fact > that the DoD forced its use on a massive scale. Yes, the DoD mandate > created some resentment, but if Ada is really so good, those who > adopted it under duress should have eventually learned to appreciate > it. Many did, I realize, but why are so many of them now rushing to > throw off the yoke? I think that Robert Dewar hit the nail on the head many years ago. In one of his Computer Science classes he asked the students how many enjoyed debugging. A large majority raised their hands. That is the problem. I detest debugging. In fact detest is probably to mild a word. So I love Ada. When I was at Honeywell many years ago (1982), a couple of us taught a course in Ada programming, complete with access to our Ada/SIL compiler which was of course somewhere between Ada 80 and Ada 83 at the time (except for one addition we kept hoping that the ANSI standard effort would fix, a decent notation for Boolean array literals). We used the tapes from the Ichbiah, et. al. course that one of us had taken as well as three instructors who were pretty much constantly available to the students. All of the students had been programming OS software at Honeywell in various assembler languages for years, and the selection process for students was designed to get a representative sample of the current Honeywell Small Systems programming staff. The biggest and most shocking conclusion from the course was that we could easily pick out about 30% of the current programming staff who would NEVER be able to successfully program in Ada. The 30% number had pretty wide bounds at the time, but we (Honeywell) went further. We wrote a short questionaire that was given to all potential students before the course, and later used that questionaire before addtional sections of the Ada course, a Pascal course that I taught, and a C course. Since the students who did well in the Ada course went on to write several significant parts of the next OS release in Ada, some from the Pascal course to write a section in Pascal, and there were three C projects. (One which ended up using the C preprocessor to write very Ada-like code.) After all this validation, we could use the questionaire on applicants for jobs and a larger portion of the existing staff. The final conclusion was that, if you used Ada about 30% of the current staff were hopeless. With C, the number was closer to 5%, in Pascal somewhere in between. Ada showed more than a 100% cost benefit over using C, and a 350% benfit over assembler, on initial project costs, with Pascal somewhere in the middle. As for maintenance costs, maintaining C code cost around 50% less than maintaining assembler, and we had no cost data for fixing bugs in Ada code--even after MOD 400 Release 3.0 had been in beta test for more than a year, and in general release for six months after that. But there were some serious problems from a management point of view to using Ada. First, the training costs were well justified, but retraining everyone would bankrupt the division, whether we used internal or external training. So any switchover would need to be evolutionary. And Ada converts were just that. They might be willing to occasionally use a code insert, or C for some low-level driver, but they would quit rather than be put back to working full-time in assembler or C once thay had worked on an Ada project for long enough. Finally, the real bad news from an Ada perspective was using the survey on job applicants. Unlike the numbers for current staff, less than 30% tested high enough on Ada compatibility, but 90% were capable of working in C. And one of the biggest descriminators was that debugging question of Dewar's. If you checked "Strongly Agree" to "I enjoy debugging my own code," forget Ada. Even worse was the vote on "I enjoy debugging code written by others." Check "Somewhat Agree" and forget Ada. Oh, and the salery requirements were such that potential Ada programmers expected to make about 50% more than potential C programmers. So the "short-term" decision was to switch from assembler to C for most code, and Ada for the more difficult sections of the OS. I left the company before I found out what the long-term decision was, but I suspect that Ada was used less and less, not more and more. Oh, and I can't tell this story without adding one anecdote. A student in the class, Joe, called me up one morning and said he had found a bug in the Ada compiler. Since compiler bugs and teaching the class were both high-priority, I asked him to bring his problem up. He brought a listing with over sixty lines of declarations and about half-a-dozen statements all in one procedure. I spend about twenty minuted figuring out what he was doing, and scribbled one statement at the bottom of the page. "You can do THAT in Ada?" "Sure." "Okay, I'll go try it." "What about the compiler bug." "Let me try this instead, I'm not sure my code is right." "Okay." I marked two of lines of declarations. "You'll still need these lines, but the rest can go." Ten minutes later, he calls back. "It still generates the same code." "Bring up a listing with the assembler output." "Got one already." It only took me a minute or so to look at the generated code. There were exactly three one-word instructions for the procedure, and the last one was a return statement. Pretty slick I thought. "Looks okay to me." "But you can't do that in three instructions!" "Did you try running it?" "Of course not! It can't work." "Why not." "It needs four instructions." "No it doesn't look. This first instruction loads the value of the first parameter into R1, and post-increments the stack pointer. The second instruction indirects through the stack-pointer that now points at the second parameter, and indexed by R1. The third instruction pre-decrements the stack pointer and does the return. I'm going to have to complement Harlan on this particular peephole optimization." "But that's cheating!" I later found out that Joe had "invented" the way to write that expression in four instructions, and his real purpose in writing the example was to show how inefficient any compiled language was. Needless to say, Joe never turned in a completed assignment, and I think he stopped attending the course halfway through. -- Robert I. Eachus "Quality is the Buddha. Quality is scientific reality. Quality is the goal of Art. It remains to work these concepts into a practical, down-to-earth context, and for this there is nothing more practical or down-to-earth than what I have been talking about all along...the repair of an old motorcycle." -- from Zen and the Art of Motorcycle Maintenance by Robert Pirsig