Re: Ada and Automotive Industry

[mheaney@ni.net (Matthew Heaney)]

In article <bb7cc$a135.248@marius>, ken@nrtt.demon.co.uk wrote:

>There's quite a lot in Ada that does indeed imply
>bad performance. Quite a few optimization techniques
>are disallowed because of the elaboration and
>evaluation rules (see papers by Mike Kamrad for
>examples).

Even if that's true, there are many instances when Ada is faster.  A
programmer can communicate more semantic information to the compiler
because of Ada's rich typing, and the compiler is therefore able to make
*more* optimizations than otherwise would be possible.

>> [code size issues snipped]

>You still miss the point. If Ada implementations costs
>20% more code space then that's a few cents per unit.
>But a few cents per unit added up over millions of
>units adds up to a lot of money.

But there's a hidden assumption here, an assumption I see over and over
again whenever there's criticism of Ada (or any other high-level language). 
It's that you assume you can actually do the job using some other language. 
For a complex system, what makes you so sure you can do the job at all? 
What makes you so sure you can maintain intellectual control of your
software solution to a complex problem, without using the facilities
proffered by a high-level language?  Do you realize how many software
projects fail?  Ever heard of the Therac-25?

As has been said, software engineering is really the process of finding
abstractions.  Or more to the point, it's finding the tools and techniques
that help *humans* write software.

Ada was designed with the philosophy that programming is a human activity. 
The Ada language is a tool that facilitates the construction of software
systems by human programmers.

Having software tools like Ada allows the same programmer - as any other
worker - to be more productive, and to construct a more complex system than
without the tools.

That Ada somehow inherently creates larger object code, or inherently
creates less efficient code, is a specious argument that is not supported
by facts.  Modern Ada compilers are at least as efficient in terms of code
size and execution speed, as has been demonstrated empirically.

Lest you think I make empty claims about Ada's efficacy as a software
engineering tool, then read the following articles:

<http://sw-eng.falls-church.va.us/AdaIC/docs/reports/cada/cada_art.html>
<http://www.acm.org/sigada/news/suny.html>

>> [Ada "complexity" issues snipped]

>It's not a red herring. Ada is hugely complex, and not
>well understood. If you think that Ada is elegant and
>consistent then you don't understand it very well. You
>only have to look at the "Dear Ada" column in ACM
>Ada Letters to see this (I really recommend you do
>read the column!).

Ada is not hugely complex.  It's very logical.  Just do what you think
makes sense, and all is well.

The trick is "thinking in Ada."  That's sometimes a problem because there
are many programmers who don't think in terms of abstractions, who don't
understand information hiding, and who don't know what the contract model
is.  But this is a programmer problem, not an Ada problem.

As I've said, Ada is a tool to help the software engineer.  For the
programmer who dismisses modern software engineering philosophy and
practice, Ada won't help, and may even seem like a hindrance.  As they say,
"garbage in, garbage out."

Perhaps the person who said that Ada is "Pascal for lawyers" was
intimidated by the Ada Reference Manaual (RM).  I myself am intimidated at
times.  However, that book is for compiler writers, not programmers.

You see, the compiler has to handle every case; it needs to have defined
behavior even for input that doesn't make any sense, for things Joe
Programmer would never do in practice.  Thus the seeming complexity. 
(Although I've heard that the C++ RM is even larger.)

When I program in Ada, I never need to consult the RM, except to look up
what exceptions get raised by a predefined library unit.   Usually, the
text I submit to the compiler compiles the first time.  So where's the
complexity, exactly?

Just do what seems right, and all is well.  You do not need to be a
language lawyer to program in Ada, in spite of claims to the contrary.

And yes, I do read the Dear Ada column.  And somehow I've come to a
different conclusion than you.

>
>Tony Hoare once said that one of the keys to success in language
>design was to make it so simple that there are obviously no
>deficiencies. The other way is to make it so complicated that
>there are no obvious deficiencies.

Interesting, because Ada's tasking model was heavily influenced by Hoare's CSP.

"No obvious deficiencies" sounds like the problem C++ is having right now;
it certainly doesn't apply to Ada.  If there were ever a language that
requires a lawyer, it's C++.  For a litany of its many trap doors, read
this critique by Ian Joyner:

<http://www.csd.uu.se/~alexb/study/cppv3.ps.gz>
<http://www.csd.uu.se/~alexb/study/cppv3.ps.Z>

>> [Ada tasking issues snipped]

>It is impossible. Ada 83 tasking cannot be used reliably for real-time
>(as the Boeing people above mentioned). Ada 95 tasking still leaves a big
>efficiency problem, which is crucial to the automotive industry,
>where a few cents on a control unit add up to millions over a product
>life.

My understanding is that Ada 95's protected types are just as efficient (or
more so) than the lower level but unsafe mechanisms used in other
languages.

While Ada tasks may seem relatively heavy, with the existence of protected
types, how many Ada tasks do you really need?

Once again, on what basis are you able to say that a correctly engineered
Ada program - even one with tasks - is less efficient than a comparable
system written in another language?

>The only role for Ada in the automotive industry is in areas where cost
>is not important, and where there is a significant improvement in
>reliability over existing languages.

Obviously, cost is always a factor in any engineered system.  But what is
the cost when someone dies because of a software error?  When a crisis like
that does occur in the automobile industry, then I bet no one will complain
about how much Ada "costs" (as if it were really more) if it can save
lives.

You know, you sound like someone who's afraid Ada will be used in the
automotive industry.  I think thou protest a bit too much.  What are you so
worried about?

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
mheaney@ni.net
(818) 985-1271