On Fri, 2004-11-19 at 03:56, Paul Colin Gloster wrote:
> On Thu, Nov 18, 2004 at 08:12:42AM -0500, Roger Racine wrote:
> "[..]
>
> What does Java have that Ada doesn't?  [..]"
>
> Inheritance anomalies. Nondeterminism. Incompatible attempts at JVMs
> implemented by Sun as reported in an attempt at a VHDL grammar with
> JavaCC.
>
And who cares?  It is still -thought to be- easier to create an
application when there are all those libraries of classes out there.
>
> 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."
>
> Hardware design matured from unwieldly CAD schematics to text-like VHDL
> and Verilog.
>

I won't argue with you, except to say that the controls engineers I work
with love their diagrams.

> "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.
>
> [..]"
>
> MATLAB is extremely weakly typed: I have seen someone with a doctorate who
> annually lectures the same material in digital signal processing
> accidentally let MATLAB (which provides no help in resolving the matter)
> perform a one dimensional Fast Fourier Transform on a two dimensional
> array which needed a 2D

Again, no argument except to say it is not keeping anyone from using
it.  What I proposed (an open-source alternative, based on Ada) could
easily be made to be strongly typed, at least with respect to cases
where the user defines the type (as in arrays).  Of course, when there
are overloaded functions, Ada will have the same problem as Matlab in
your example (if there are two FFT functions with the same name, one of
which can be given a one dimensional array and the other given a two
dimensional array, a mistake could be made).  But for non-overloaded
cases, the underlying Ada compiler would catch the problems.

Instead of finding fault with current practice, and attempting to talk
engineers into using Ada, I thought it might be better to work on giving
them what they want -and- what we want.  First, everyone must understand
that I consider GN&C engineers to be types of software engineers.  They
are not different (some people think they are systems engineers).  They
work, generally, at the highest levels of development of software
(requirements and design), and rarely get into the development of flight
code development (at least they typically don't like to worry about
things that matter at that level, like data protection, declarations of
variables, program structure, etc).  From other application areas, say
compilers, they would be like the person responsible for coming up with
optimization algorithms.  They might write code, but that is not their
primary job.  However, since they are likely to write code to test their
algorithms, it is quite reasonable to have them write the code in a way
that can simply be grabbed and incorporated into the compiler.

The reason Lisp, Prolog, etc. did not end up to be viable tools for
software development in their application areas was because it was not
easy to go from the algorithm development environment (Lisp, Prolog) to
the final product (Ada, C, . . .).  The cost of re-writing the
algorithms was too great, so those designers in those application areas
are using more common development tools.

On to GN&C designers.  They have tools that help them create their
algorithms.  In the case of Matlab, the M-file language is similar
enough to the final language that it is very easy to translate, so the
cost, while not trivial, is still thought to be less than having the
analyst use inadequate tools using the final language, even a language
with the benefits of Ada.

In the case of Simulink, the tool will automatically create source code
that implements the design.  The avionics developers have found that
this does save money over the manual translation method used in the
past.  One might make the case that initial development in Ada by the
algorithm engineer might save even more money, but that will not be
accepted by the engineers until the tools give them the capabilities
they currently have.

In the case of Matlab, on the other hand, the case can be made much
easier that M-file notation in Ada would be much easier to translate
(i.e. automatic), and be portable to other environments than the
proprietary (and expensive) development tool.  It would also have many
of the benefits of Ada (array protection, strong typing, . . .).

Unless this changes peoples' opinions, it appears that the status quo is
acceptable to everyone.  That is sad.

Roger Racine