ted@grebyn.com (Ted Holden) (02/21/90)
Sorry to be awhile getting back to comp.lang.ada; I've been pretty busy lately, and the crusade against Ada isn't really very high up on my list of hobbies right now. Actually, there are worse problems than Ada in the government: there is a procurement system which requires so much time to obtain any kind of thing that people choose computers with no other thought than "what contract is it on; how easy will it be to get my paws on..." There is the disengenious system of using huge numbers of contractors at real costs of over $100,000/year/person rather than just hiring these same people as government employees and paying them real salaries (even at $5000-$10000 more a year, the govt. would save more than double). There is the problem of companies which seem only to deal with the government; this is kind of like the problem they get in India when a tiger gets too old and run-down to kill its normal quarry and begins eating people. That kind of movie usually ends happily, as the white hunter bags the tiger with the 375. I don't really know how to make the other variant end happily except, maybe, to require that no more than X percent of any company's business be government related. And then, there's the Ada/Software-Engineering problem; if it isn't grandiose, it's not worth thinking about, much less doing. Not that there aren't grandiose success stories, such as UNIX or WordPerfect, around in the world. But wordPerfect started out as a simple little editor program written in PC assembler and added features every six months or so until it finally EVOLVED into something grandiose. If the same program were to be "designed" and written under DOD specs, then they would just be getting version 1.0 out the door now, after seven years of design, followed by two years of coding, at the end of which the entire package would be magically required to function properly, just like the Airbus control system, the Space Telescope, Stanfins, WIS, and all of your other great successes do. The truth as I see it is that anything which takes two or three years or more to do under present circumstances is going to bear no relationship to reality when fielded; if you can't get some kind of a first version of a product into users' hands within a year, you're doomed. Karl had requested some background info: for the purposes of USENET which, unfortunately, nobody else connected with any of my other endeavors is interested in, I represent only myself (HT Enterprises). My personal experience with Ada has been in connection with my work as a systems consultant with SofTech/EER of Vienna, Va. and involved writing Ada/C and Ada/4GL interfaces, typically 300 or fewer lines of code, and then watching Ada compilers take 30 minutes to compile those little programs into 400K executables. I have turned down offers to work on typical Ada/Software-engineering projects (design for a year while the thought police check computers for code, and then code for three months), because long experience has tought me that reasonable software cannot be developed that way and I do not wish to be a part of anything which I would regard as doomed apriori. Most of the horror stories I quote regarding Ada come from friends more involved with it, and mostly outside of SofTech or other think-tanks, although there are at least two or three people there who share my views. The people I've spoken to involved in Ada projects all have claimed to have to work around Ada, multiplying the level of work involved in doing anything at all by at least two, and this seems to be in line with most of what I read concerning Ada in journals. I speak numerous variants of computer languages, and two other human languages more or less, other than English. My only serious claim to fame as a programmer is the little polyphonic VMUSIC program on the PC BBS's, which was written in a combination of Turbo Pascal and assembler. Thank God. If that program had been written in Ada, the Bach pieces would sound like three dogs growling at eachother, and you'd be hearing the HIGH notes. Ada has problems which would be serious enough under any set of circumstances, but the biggest problem it has is simply the fact that it isn't C. When Cobol came out, industry had no better answer sitting around, and pounced on it. Nobody's pouncing now. The fact that C totally dominates the mini-micro world, something like 70 % of all usage last I heard, coupled with the increasingly obvious notion that the mini-micro (DOS/UNIX) world is just about the only one which counts anymore, says that C (or C++) is about the only rational choice of a major language any more, especially for any government agency. Under the best of circumstances, all you could hope to do with Ada would be to duplicate the C/UNIX world which is out there now at five+ times the cost. Which presents a problem. Beltway banditry and defense contracting are about to go bye-bye, and we're all going to be out there trying to actually make it in the world by competing the way the Japanese do. And, if we are to actually compete with other nations such as the Japanese, we're going to have to eliminate almost every form of waste and abuse in our whole society. When doctors earn $700,000 average in this country, that gets built into the price of everything we ever try to sell. Likewise, the machinations of Ivan Boesky get built into product prices, and on and on. If government agencies are to be required to spend five or more times the going rate for all their software needs, that will get built into prices as well. Hence, there is an incentive to simply drop Ada as a patriotic act; there is also an incentive from the point of view of personal survival. I am hearing that Ada 9-x will probably only include fixes for present bugs and woes; nothing at all about object-oriented features. You want to be a software engineer in the future? Better start learning about one of the languages those people use (Eiffel, C++, etc.) But then, I have it on good authority that the inventors of C/UNIX fill out the occupation slot on their tax returns with "programmer". Kind of makes you wonder just a little bit, doesn't it. Ted Holden HTE
rsd@sei.cmu.edu (Richard S D'Ippolito) (02/21/90)
In article <19409@grebyn.com> ted@grebyn.com (Ted Holden) writes: >And then, there's the Ada/Software-Engineering problem; if it isn't >grandiose, it's not worth thinking about, much less doing. Not that >there aren't grandiose success stories, such as UNIX or WordPerfect, >around in the world. But wordPerfect started out as a simple little >editor program written in PC assembler and added features every six >months or so until it finally EVOLVED into something grandiose. If the >same program were to be "designed" and written under DOD specs, then >they would just be getting version 1.0 out the door now, after seven >years of design, followed by two years of coding, at the end of which >the entire package would be magically required to function properly, >just like the Airbus control system, the Space Telescope, Stanfins, WIS, >and all of your other great successes do. You have cited UNIX and WordPerfect before as "success" stories, and had been asked several months ago by another reader to provide supporting data. I have not seen your reply. Have you made it? I would suggest that the number of users of a product is not a direct measure of quality or of engineering prowess. (Horses were widespread until displaced by autos.) If you haven't cited numbers to demonstrate productivity and quality of those products, will you please do so now? I will accept either number of source lines of code per person-month and number of errors per KLOC, or other results based on your own definitions. I understand that a version of WordPerfect was rewritten from scratch in C. This might be a good one for you to comment on as to the amount of design, implementation, and integration times spent and how close the company came to meeting the targeted release date. I have a UNIX system here that still has numerous errors, some of which are listed rather triumphantly, if not belligerently in the manuals. Let me quote a sample of them: BBEMACS(1) I tinker too much, so occasionally I mess up and it don't work no good. But then I fix it, hooray. DAB(!1) There is a mysterious bug causing occasional core dumps... ...just send mail to the author. FILE(1) It often makes mistakes. JOBS(3J) There is no excuse for the "getwd" routine to be in the jobs library. There is even less reason for this routine not to have been documented by the author(s) at Berkeley. PARSEDATE(3) The grammar is incomplete and always will be. PUTC(3) Errors can occur long after the call to 'putc'. SCANF(3S) The success of literal matches and suppressed assignments is not directly determinable. SIN(3M) The value of 'tan' for arguments greater than about 2**31 is garbage. CTAGS(1) ...if you have two Pascal procedures in different blocks with the same name, you lose. EMACS(1) Not bloody likely. TC(1) The aspect ratio option is unbelievable. UNITS(1) Don't base your financial plans on the currency conversions. Now, your system may have different texts for some of these, but I have several sets of manuals spanning years which contain some of the same texts (DEC substitutes the word 'unreliable' for the original 'garbage'). As I said, these kinds of messages aren't universal, but there enough of them spanning a large enough sample of years and programmers to cause me to question the kind of attitude of the folks you continually hold up as model programmers. There is a more fundamental question, however, that we can save for another time, having to do with the suitability of the current software models implied by the systems and languages you support for large-scale projects. It makes no sense to touch it when there is such an obvious disconnect. Rich -- Hitting baseballs and writing software are two professions where you can become a millionare with a 75% performance failure rate. rsd@sei.cmu.edu ------------------------------------------------------------------------
schweige@cs.nps.navy.mil (Jeffrey M. Schweiger) (02/21/90)
In article <19409@grebyn.com> ted@grebyn.com (Ted Holden) writes: > > [ much stuff deleted ...] > >... My personal experience with Ada has been in connection >with my work as a systems consultant with SofTech/EER of Vienna, Va. and >involved writing Ada/C and Ada/4GL interfaces, typically 300 or fewer lines >of code, and then watching Ada compilers take 30 minutes to compile those >little programs into 400K executables. ... > Ted - If you think that the above numbers are typical of Ada, you are much mistaken. If they are an exageration that you are using to make a point, it isn't very credible, and using such exagerations totally buries any valid points you might have. For what it's worth, last summer I wrote a 1000+ lines of code Ada program in about 3 weeks. It compiles in about 2 1/2 minutes and generates an executable of less than 85K in size (BTW, it does work). This was written using the IntegrAda compiler on a 386/20 machine. Jeff Schweiger -- ******************************************************************************* Jeff Schweiger CompuServe: 74236,1645 Standard Disclaimer ARPAnet (Defense Data Network): schweige@cs.nps.navy.mil *******************************************************************************
Loren@cup.portal.com (Loren Louis Hart) (02/22/90)
I would say the best way to deal with Ted Holden is not to post any responses, but to mail your responses to him. This will cut down the amount of junk we all have to read, and will also allow anyone who wants to, to respond. Frankly, I don't think his opinions are worth posting any responses to. The only reason I am posting this response is to try to help keep the useless trafic down. Loren L. Hart loren@cup.portal.com San Jose, California
mike@cs.arizona.edu (Mike Coffin) (02/23/90)
[Speaking of Tom Holden] From article <27187@cup.portal.com> (Loren Louis Hart): > Frankly, I don't think his opinions are worth posting any responses to. > The only reason I am posting this response is to try to help keep the useless > trafic down. Actually, I thought his last article had an interesting arguement--- not against the quality of Ada, but against the idea that Ada will ever become popular. The fact that Unix seems to be taking over the world certainly seems to give C and C++ a *big* leg up. Not only are all the Unix tools built for, and based on, C, but the operating system itself is optimized for running C programs. Given that many contracts in the future will specify Unix, there will be a considerable tendency to also specify C or C++. -- Mike Coffin mike@arizona.edu Univ. of Ariz. Dept. of Comp. Sci. {allegra,cmcl2}!arizona!mike Tucson, AZ 85721 (602)621-2858