Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[softeng3456@netscape.net (soft-eng)]

Dr Chaos <mbkennelSPAMBEGONE@NOSPAMyahoo.com> wrote in message news:<slrnbadndp.o8q.mbkennelSPAMBEGONE@lyapunov.ucsd.edu>...

> The choice of what goes in a library and what is "in a language" is
> important intellectually primarily to the more expert language
> designers and implementors.

Syntax is core to the language.  So it should not be
unnecessarily overloaded.  Libraries can be learned
in specialized variations, as needed.  But every
programmer needs to know the syntax.  (Should anyway;
if people are chunking the language syntax so
their programmers can get their heads around it,
I think the syntax is too complex.)

> Once both a base language and libraries are assumed the precise point
> of division has little substantial effect for typical programming tasks:
> you have to know a both. 
> 
> If the goal is truly a minimal "core" language, then C is only barely
> a contender (and C++ laughable)---Smalltalk and Lisp are the obvious
> endpoints there.  They're great languages, but in design very
> substantially different from C or C++ or Ada.  
> 
> What I find bizzare and remarkable is the consistent assumption by
> many others (especially those that don't use languages like Ada,
> Eiffel and post F77 Fortran) that "C" and "C++" are almost-by-default,
> the "correct" choice not just economically but in engineering quality.

It's the other way around.  Software engineering is a fake field
full of charltans, simply because it stands on a false premise -- you
can take anybody and turn them into good disciplined programmers by 
applications of certain principles.  The actual fact is, results
in software are to a *very* large part related to aptitude.  If you
can't hire well, the project is doomed no matter how many software
engineering principles you apply.  Once you have the right people,
engineering quality will appear; you just need to make sure
the design is good, the management is good (which
often means not getting in the way of good quality),
there is good quality assurance, and such less-than-flashy things.

So there are no "engineering quality" correct choices.
Some languages with straight-jacket mentalities make people
think they are rigorous, disciplined tools that will
make quality magically appear.  That is deluded thinking.

If Ada projects had actually succeeded in producing good quality
software, it would have been everywhere today.

The real solution -- for a language -- is on the opposite tack.
You just need to find the tools that will fit best
the "right aptitude" people.  And that was C's success.