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

[Richard Riehle <richard@adaworks.com>]

Kent Paul Dolan wrote:

> I merely lack the level of specific
> formal education in computer language
> design that make most of what the OP
> thinks of as "simple principles" look
> simple when reduced to standards-ese, or
> look simple when trying to convince
> other mid-level and junior programmers
> that Ada is an "easily understood
> language".

I suppose I should interpret that as a response to my
contention that Ada is not as hard to learn as many
have suggested.    In fact,  Ada, once some fundamental
ideas are understood, is not that difficult.   However,
in its early days, when those fundamental ideas were
new, even  revolutionary, they were difficult for even
experienced programmers to grasp.    Now, so many of
those ideas have been adopted in the design of other
programming languages, that, when one mentions one
of them in the context of Ada, the response is often, "So
what?  Language XYZ has that feature too."

True, not all of the ideas have been adopted.  The most
difficult  idea for many programmers to grasp is the set
of visibility rules in Ada.   In my experience, once those
are understood, everything else falls into place.  Some
Ada programmers spend years fighting the visibility
rules, and continue to raise questions, debate, and
engage in endless language lawyering in an attempt to
subvert, thwart, or whine about them.

> If that claim were true, the years of
> language lawyering that have filled and
> continue to fill comp.lang.ada would not
> have been necessary. In the case, Ada is
> conceptually an extremely difficult
> language to understand, and I'm not sure
> why that needed to be so.  Pascal [from
> which Ada mostly derives], at least in
> its early incarnations, is in contrast
> supremely easy to understand from the
> practicing programmer's viewpoint, which
> made it a splendid learning langauge and
> quite fair in practice as well.

I disagree.  Ada is not conceptually difficult to
learn or understand.  It does include some new
ideas, and new ideas are sometimes difficult to
grasp at first.  That is quite different.

Again, many people who were required to learn
Ada for their work were resentful of the mandate
and spent their time inventing reasons why they
believed they could not do something instead of
discovering how easily they could do it.

If a programmer wants to fight the visibility rules,
for example, he can do so, can grumble about them,
find reasons why writing a particular program is so
hard,  and so on.   This attitude reminds me of my
first experience on a part-time high-school job in
which I was required to use a floor-buffer.   The
standard floor-buffer uses a large circulating brush
which, as it polishes the floor, can exert a powerful
thrust vectored over its clockwise motion.   A human,
regardless of their strength, cannot overcome the force
of the brush using brute strength.   That same human,
learning to gently balance the rotating brush, can make
it go anywhere.  I became quite skilled at controlling
the buffer and could eventually command it using a
single finger.

The Ada visibility rules are a powerful force in the language
design.  The programmer can exert all kinds of energy in
complaints about it.  However, once one understands this
feature, takes charge of its inherent force, and incoporates it
into a design and corresponding source code, it makes the
Ada programming (and especially the maintenance) process
much more pleasant than one might find in competing programming
languages.

Most of Ada is pretty simple.   Besides the visibility rules,
there are two other parts of the language that are a bit
difficult for some newcomers:  accessibility rules (for
objects and access types) which prevent many of the pointer
related mistakes so common in many languages,  and tasking,
a feature designed to incorporate concurrency in the language.

Most of the other features of the language, such as type safety rules,
separate compilation,  type derivation,  object aggregates, abstract
data types,  control over defined scope,  generic templates,  exception
handling,  packaging of common entities,  information hiding,
encapsulation, etc;  these features that once seemed so strange to
programmers experienced in procedural abstractions, are now
commonplace throughout the programming language community.
When introduced in Ada, they seemed strange, even bizzare. Now
they are accepted practice.

Even so, Ada is not intended for one-person, single program, projects
where an individual programmer can grasp every detail of the program.
It is intended for large-scale projects where many programmers and
designers must interact over a set of complex requirements and integrate

those requirements into a single, well-functioning whole.  Ada makes
that kind of project easier to develop, easier than one might experience

in most other languages.

One can make the case that Ada is not the best choice for certain
classes
of software.  I still believe it is not appropriate, using the current
compiler
technology, for eight-bit microcontrollers (e.g., I-8051),  but a subset
of
Ada might be.   Smalltalk is still a better language for some kinds of
software, especially where one needs a lot of dynamic properties and
frequent modification of the code.  Smalltalk is, however, a terrible
choice for the kinds of software Ada is targeted to build.

There are other languages one can compare to Ada that also have serious
potential for embedded-real-time safety-critical software.   As I
examine
them, in some detail, I keep discovering that they simply fall short.
It is
said, "The Devil is in the details."    C++, for example, when I look at
it
closely, seems inappropriate for developing software of the kind I just
described.   Each time I look for a competing technology, when compared
to Ada, it simply falls short.

A better Ada could be designed.   There are things about the language
that could be improved.   I hope someone will eventually design a
language that is better than the current Ada design.  At this point,
though,
when I am looking for a language that has a high regard for reliability
and dependability,  Ada still has the edge.

Richad Riehle