Re: "Forced to Use Ada"

[raveling@vaxb.isi.edu (Paul Raveling)]

In article <163@csv.viccol.edu.au> dougcc@csv.viccol.edu.au (Douglas Miller) writes:
>
>In article <7682@venera.isi.edu>, raveling@vaxb.isi.edu (Paul Raveling) writes:
>
>> 	Suppose somone designed a language provably better than these --
>> 	if we mandate an existing standard, such as ADA or C, we risk
>> 	preserving a dinosaur at the expense of suffocating mammals.
>
>If ADA is already a dinosaur, what does that make COBOL, a diatom?

	Maybe a trilobite?  Languages that DOD has adopted as standards
	to my knowledge are COBOL, JOVIAL, and ADA.  Looking only at
	pre-ADA history, DOD's standards haven't exactly dominated
	the software engineering world on their own merits.

	I don't mean to pick on ADA specifically -- it's just that
	in my 26 years in computing people have kept learning how
	to do a better job at essentially EVERYTHING.  One year's
	state of the art can be the trailing edge of technology
	after a couple more years pass.  In the last 15 years or so
	though it's been MUCH harder to profit by that learning because
	the industry has had a heavy dose of standards.

	The bottom line is that I advocate "necessary and sufficient"
	standards, keeping them as limited as possible to enable
	reasonable software portability.  If standards are small,
	software using them can expand by adaptive radiation; if
	standards are too comprehensive, software will be ecologically
	specialized.  A currently important limit of specialization
	is the difficulty of building multi-process applications in a
	"standard" UNIX environment.

>
>> 	That's my usual comment about UNIX, but it also suits languages.
>
>An operating system is a fundamentally different thing to a programming
>language.  A programming language is much lower level --- this is where
>standards are really appropriate (analogy: no two models of motor car are
>(or should be) the same, yet many of the basic components conform to
>standards that enables a trained mechanic to do basic work on any car).

	This is an interesting case to consider -- As a former
	OS builder, I tend to think of it in the opposite sense,
	with the OS being at a lower level.  Typical OS interfaces
	semantically have a lot in common with abstract data types.

	In truth, it's something of a chicken-and-egg question
	and both views are correct in various ways.


----------------
Paul Raveling
Raveling@isi.edu