TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Roger Racine <[log in to unmask]>
Reply To:
Roger Racine <[log in to unmask]>
Date:
Thu, 18 Nov 2004 08:12:42 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (51 lines)
I have been at a number of meetings and conferences where people are
looking at languages other than Ada to use for avionics applications (my
area of interest).  Besides Java, there are also "Model-Based" approaches.

What does Java have that Ada doesn't?  Libraries.

What do "Model-Based" approaches have that Ada doesn't?  Two things:

1) Graphical approaches for flight control applications.  Controls
engineers have written their algorithms in diagrams since the 60s.  If
those diagrams can be automatically made into code, it saves a fair amount
of effort.  Thus, Simulink, Matlab, etc.

2) Libraries.  For guidance, navigation, and other applications that work
in floating point (science applications in general), Matlab is an excellent
example of an excellent design environment.  Why?  Because it has a large
number of tools available to analyze the data coming out of the
program.  It is essentially a great code completion editor, compiler, and
debugger in one integrated tool.  It completes code by adding data
declarations (I have never met a GN&C engineer who liked to declare their
variables. "They are all double precision floating point anyway; why can't
the system create them for me").  It takes the code ("M" files, in a
proprietary programming language) and compiles it.  And then the debugger
allows the code to be executed using all sorts of data analysis routines.

What is the result?

For flight controls applications, the graphical model can be used to create
code in a variety of languages (including Ada).  This is reasonable for
this application, so there is no need to change anything.

For the rest (guidance and navigation), what I see is the engineer creating
code using a proprietary language, with either an automatic code generator
performing the transformation to the final language or manual translation.

Here is my proposal:

I am not aware of any sufficient open-source equivalent to the commercial
products.  If someone (DARPA? NSF?) were to see the need for a more
available tool, and fund its development, it could very quickly get into
the academic world, and from there into mainstream use.  If the language
syntax happened to be Ada, I don't think anyone would care.  And if the
generated language was Ada, the algorithm designers would be better able to
look at it at integration time.

What do others think?  This is obviously a big job, but I think this is
already a niche that Ada is used in, and it would be a great shame if we
didn't at least fight to keep it.

Roger Racine

ATOM RSS1 RSS2