Re: Reasons for dropping Ada

[rsd@sei.cmu.edu (Richard S D'Ippolito)]

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
------------------------------------------------------------------------