🚀 go-pugleaf

I wrote:
>> Well how come ADA seems to be largely irrelevant outside of 
>> the defense sector?  

Bill Wolfe replies:
> That depends strongly on your definition of "largely irrelevant";
> there is a large and growing number of non-defense projects and 
> companies using Ada.  The new generation of highly optimizing 
> Ada compilers deserves at least some of the credit for this 
> substantial and accelerating growth.

OK, I'll clarify myself.  Undoubtedly there are companies moving to
Ada for non-defence work.  But there seem to be MORE companies 
moving to other languages such as C++ and (I hate to say it) C.
This is only my perception of what is going on.  Does anyone have 
any meaningful statistics on recent trends in programming language 
usage?

>> ADA 83 was 5 - 10 years out of date even before it was finalised.  Unless 
>> it gets a RADICAL overhaul, ADA 9x will be 10 - 15 years out of date.
>> Doubtless, the reasctionaries and religious zealots from the software 
>> engineering industry will make sure that much of the important work done 
>> by researchers over the last 15 years (like GC technology, functional
>> programming, designing languages to make formal verification possible) 
>> will be ignored ... just like they did for ADA 83.

> In fact, this is not correct. 

ADA 83 most certainly was 5 - 10 years out of date!  And given that the
ADA 9x will be going through the same long, drawn out process as 83,
I can't see why it should be any less out of date. 

> Ada 83 explicitly provides for garbage
> collection as an optional compiler service.

But they cocked it up.  Optional garbage collection is close to useless, 
since you can't depend on it being there ... unless you write code that
assumes a particular ADA compiler.  This particular lesson should have 
been learned from Algol-68.  Maybe some of the ADA design time knew this
.. but the reactionaries won the day.

> The rule that functions
> must not modify their parameters was probably a direct result of
> functional programming ideas.  

I doubt it very much.  It is more likely it was a result of bad
experiences with FORTRAN and PASCAL "VAR" parameters.

> Finally, formal verification is a
> major goal of the software engineering community, and Ada was designed
> to support it to as great an extent as possible.  For example, the
> use of the termination model of exception handling was (at least in
> part) motivated by formal verification considerations. 

Excuse me while I laugh ...

Verifying ADA 83 is a fundamentally intractible problem for any number
of reasons.  I don't believe anyone has even managed to formally define
the semantics of ADA 83!  Maybe some members of the ADA design team did 
have verification in their minds ... but others didn't, and the others
won the day.

>> Production language design should be an on-going evolutionary process.
>> ... A new language version every 2 years sounds about right to me.

> This is too frequent; five years might be reasonable, but not two.
> I don't think the compiler validation suites, etc., would be able to
> respond meaningfully to a revision cycle which was THAT frequent.

There is no reason why the revisions should not be pipelined.  And
what is wrong with some people using pre-validated compilers?  After
all that is how much of the rest of the computing industry works at
the moment.  It is often better to use a new, somewhat flakey compiler
now if it offers significant benefits.

> But another good reason to only revise no more 
> quickly than five years at a time is to give new ideas a chance to 
> mature.  Once a new idea has proven itself, and has become reasonably
> agreed upon to be a good thing that production languages should have,
> there should be a process by which production languages incorporate
> new developments in software engineering technology, and this is what
> should be accomplished by the Ada 9X scheduled revision process.

The time from a new idea being introduced, to its being mature is much 
less than 5 years.  Besides, new ideas are developed in parallel not 
serially.  The problem is that too many people in industry are too 
busy meeting project deadlines to keep up with research.  The result 
is that it takes far too long for mature ideas to be perceived as such, 
and hence to come into general use.

You would do well to consider the ongoing development of the Eiffel 
language and environment.  Currently, there seems to be a minor 
revision cycle of ~6 months and a major cycle of ~2 years.  Nobody
seems to be complaining ...

-- Steve