From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: * X-Spam-Status: No, score=1.8 required=3.0 tests=BAYES_50,TO_NO_BRKTS_PCNT autolearn=no autolearn_force=no version=3.4.5-pre1 Date: 21 May 93 18:54:29 GMT From: eachus@mitre-bedford.arpa (Robert I. Eachus) Subject: Re: Further Ted Holden ranting... Message-ID: List-Id: I feel I should apologize for wasting bandwidth by responding publicly to HTE. However, there are some issues here which seem to be of great interest to the wider group... In article <1078@fedfil.UUCP> news@fedfil.UUCP (news) writes: > I do know that the entire software development community of the > United States has irrevocably standardized on C and C++, and that > they've also basically taken one look at Ada, and said "You've got > to be kidding!" The first part of that statement is a contradiction on its face, so I won't bother with it. The second part is a real issue which will not go away for years. About ten years ago, when I was at Honeywell, three of us went all out to teach Ada and software engineering to a more or less random sample of "Software Engineers" from our division. This group, and others like it later broke into about 70% successes, 30% failures. The majority liked Ada, found the software engineering we taught as part of the course to be a great help, and follow-up showed that they were much more productive in Ada than in assembler, FORTRAN, C, or whatever thay had been using. The 30% could not convince the Ada compiler to let them do what they wanted. Most of them could not even complete simple assignments on the order of list sorting or summing a list of numbers. "Can't teach an old dog new tricks?" No, age was not a major factor, nor was assembler usage. It was mostly temperament. Some programmers couldn't live with the restrictions that Ada imposed, and were not willing to think about the problem, and let the compiler worry about the bits. The thing that Ted Holden doesn't seem to understand, is that this "problem" is not unique to Ada. We had a C project which applied software engineering discipline to developing a database with exactly the same results, and a lot of good code from the progammers who could live with the discipline. I've worked on several similar PL/I projects. The same thing is happening today with C++. If you want the software engineering advantages, then you have to live with the discipline, and some poeple can't. (There are also programmers who can live with the discipline, but don't like Ada, or PL/I, or Pascal, or... This is a very different issue.) Ten years from now, those who can't work in a disciplined fashion will be gone from the software field, but right now there is a surplus. (And some of those people are people I count as friends, and haven't been able to find jobs for months or years. A lot more show up in the stacks of resumes we get for each available opening. Ted--or anyone--if you know of openings for such people, I'll direct them to you. > I know that such complex software items as the varied flavors of > UNIX, the commercial databases, the commercial wordprocessors, > Windows NT, etc. etc. ad infinitum are all being written in > C/C++. They all work. Riiight! Some versions of Unix work better than others, but that is not a language issue. I don't know how to quantify the languages used for commercial databases, but I think you will find that most "industrial strenth" database management systems are still assembler, and of those that aren't a substantial fraction are in Ada. Commercial wordprocessors and Windows NT do not belong in the same paragraph with "They all work." > I know for sure that it is always safer to simply use something > which is known to work than to reinvent it. You think the DoD doesn't know this? It is just that they have, of necessity, a much higher standard of "known to work." In many cases this requires developing test plans that can verify that the software will operate correctly in circumstances which cannot be tested in the laboratory. The military has a term for people who discover bugs in weapons software--casualties. You can't just send most of this stuff to beta testers and hope they will discover the problems. > Aside from all of that, history is full of examples of resources > being used wisely and well by the winning side: the victory ship > and the escort carrier from WW-II are two such examples. If you study the history of that late unpleasantness, and I do, the Victory ship and the escort carrier are perfect examples of just the opposite. The United States could, and did, count on being able to outproduce the Axis. This means producing lots of what you know how to build quickly today, rather than the best equipment for the job. Escort carriers were pre-war designs that were unsuitable for fleet actions, but the construction details had all been worked out. (Incidently, I'm currently reading _Heisenberg's_War_ by Thomas Powers. Very good book about atomic research in Germany during the war, and how the Allies reacted to what they knew. I highly recommend it.) -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is...