From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,c4fcec3a6b59f7f7,start
X-Google-Attributes: gid103376,public
From: james@cdac.com (James Thiele)
Subject: Re: Ada and Automotive Industry
Date: 1996/11/12
Message-ID: <1996Nov12.004721.8454@ole.cdac.com>#1/1
X-Deja-AN: 195879427
sender: news@ole.cdac.com (Usenet News)
organization: Cascade Design Automation, Bellevue, WA
newsgroups: comp.lang.ada
Date: 1996-11-12T00:00:00+00:00
List-Id: <comp.lang.ada>


(Robert Dewar) writes:
>
>Ken Tindall says
>
>"I think we should have a little respect for the Boeing point-of-view.
>It doesn't help them to be continuously pushed by academics to
>adopting unsound techniques. They have to live with the consequences of
>screwing up big time."
>
>In any language you only use tools that are appopriate to the job. The use
>of Ada tasking, and various tasking constructs works well in some situations,
>and is inappropriate to others. 
>
>The important thing is to base the deisions on what tools to use on well
>founded technical judgment, and not vague (and quite misleading) generalities
>like "Ada tasking is too inefficient to use". 
>
>I was struck at one meeting I was at with project leaders from various
>avionics groups. One group mentioned that it was using Ada tasking for
>critical flight control functions, and one of the other groups reacted
>amazed. Turned out they had not even *considered* using Ada tasking?
>Why not? Because they had heard that it was too inefficient.
>
>You do not have to be an academic to object to this method of
>decision making.
>
>I would guess that the Boeing decision makes perfect sense in the context
>of their application, but to draw vague generalizations from it makes
>little sense. You have to carefuly evaluate in the context of your own
>project what tools should be used, and you will do a better job of this
>evaluation if you base it on technical facts and good technical understanding
>rather than rumours!

Since I contributed to this and brought in my work at Boeing I want
to clarify what *I* said: In the 86-88 time frame, we were unable
to find an Ada compiler which supported tasking well enough for
us to use it.  I also said that I felt that the tasking model in
Ada83 was too weak for autopilots, which require a rigid scheduling
regime.  I also said that all the groups we were in contact with
wrote their own schedulers.

DO NOT infer that I can talk about what Boeing does now.  Ada is
used almost everywhere on the 777.  No doubt the compilers are
better now.

The original thread was about the possibility of using Ada in
automotive systems.  IMHO Ada is a poor match to the *very* small
processors that are the majority of automotive systems.  IMHO
methodology is more important than language - I have seen a
wonderfully elegant, low-cost, low-power real-time system written
entirely in assembler, and I've seen a nearly unusable real-time
system written in Ada.  The difference was that the Ada team
was sloppy and didn't follow even the weakest software engineering
techniques.

My advice to the auto industry is to study real-time, highly
reliable systems and choose a methodology that has been
successful, then choose a language (Forth, C, Ada, Modula, ...)
and apply the methology religiously.

Wishing he'd shut up a long time ago,
James
--
James Thiele
james@cdac.com (work) or jet@eskimo.com (home)
http://www.eskimo.com/~jet