TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

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

Print Reply
"Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
Stanley Allen <[log in to unmask]>
Thu, 4 Dec 1997 02:01:06 -0600
text/plain; charset=us-ascii
Stanley Allen <[log in to unmask]>
text/plain (118 lines)
Mike Kamrad wrote:
> When asked whether he uses Ada for developing his
> software, he responded no.  The availability of COTS
> software components compelled him to choose
> otherwise ...[slice] ... [Ichbiah] concluded, "We
> are in a world where this availability of outside
> components is becoming a tremendous factor, much more
> important than the language."

Unfortunately as with so many of Ichbiah's observations,
this is all too true.  Programmers in the Windows
environment program less "in" C++ or Java than they
program "in" a component collection.  We even say now
that an application is programmed "in" X.  The collection
of components provides an extended "language" which is
used to express a considerable bulk of the application.
Note however that pre-built components can never *be* the

But Ichbiah's statement is also all too pessimistic.
It boils down to this: these "outside components" will
always be Ada-impenetrable, and thus we must implement
our application-unique logic using the ugly native
languages in which the component interfaces are expressed.

Obviously the lack of bindings was a big hold-up for
Ada83 use.  Not that good bindings would have made the
world's programmers stampede to Ada; there were simply
classes of applications that were not cost-effective to
consider because there were no bindings and it would have
taken too much effort to create them.  And now in the
Ada95 world we have binding generators, most of which
seem to be "experimental" or "toy" scripts which get
the job done "about 90% of the way", which is really
about as practical for the long-term as the handwriting
"recognition" of Apple's original Newton device.

This is not to denigrate that small set of bindings
which have been generated with these tools and have
proven useful.  But it always has taken quite a bit of
hand-work on the automatically-generated products to
make them usable and complete, much more so than is
practical if our goal is to have new Ada bindings
available to programmers within, say, a week of the
publication of a new API.  For example, the OpenMP
API is being introduced this year and C/C++ and
FORTRAN bindings are being created by some of the
committees (  Can we say that
the Ada programmer will have the means of using this
somewhat obscure API in his/her work within any
reasonable amount time?  The C or FORTRAN programmer

I am no syntax/semantic/code-generator expert, and so
I can't make the following argument without qualification,
but here goes.

It seems to me that "binding generators" are in the
same state that "compiler generators" were in the early
80's.  At that time lex/yacc and a few other toolsets
we good enough for simple work, but were not good enough
to build commercial-quality compilers, especially for the
code-gen/optimization phases.  Then the work done by
Wulf and his CMU team on "production quality compiler-
compilers" enabled the development of high quality
compilers generated from abstract specifications, and
led to the Tartan family of products (someone correct
me if my history is off here -- I'm piecing this
together from memory of different sources).  Something
similar could be said about the intellectual history
of compiler "intermediate languages" and the work
being done now by DDC-I with ANDF, and also of the DEC
FX32 technology (translation of machine code from
one CPU architecture to another).

The point is this: to automatically generate high-
quality, programmer-friendly bindings for Ada
from C/C++ or Java "specs" may be within our grasp
if some research & development was pointed in that
direction.  Already the seeds are there in the current
c2ada and java2ada tools, but to reach the next level
will require more focus.  Perhaps ATIP funding could
be organized along these lines.

I envision a tool which accepts as input 1) the "specs"
for some interface in another language, and 2) "rules"
(or perhaps "options") which tell the binding generator
how to make certain choices.  The programmer-at-work
could use such a tool to generate project-specific
bindings on the spot for obscure APIs needed for his/her
application.  The ARA could use such a tool to quickly
develop "standard" thin bindings for important new APIs
which are introduced by the industry.  Note that I
haven't said that the tool must or even should be free.

(I had hoped last year that CORBA's IDL would become the
basis for an industry-wide move to specify interfaces in a
language-neutral way [and in fact, there have been some
interfaces specified in IDL, e.g. DMSO's HLA RTI] so that
"bindings" for different languages could be automatically
created as necessary.  This of course was a pipe dream:
the general software world is not nearly mature enough for
that concept.)

"I pray daily that more of my fellow-programmers will find
the means of freeing themselves from the curse of
compatibility" -- Edsger Dijkstra, Turing Award 1972

Stanley Allen
mailto:[log in to unmask]
mailto:[log in to unmask]

(P.S. Now that C++ is an ISO standard, I hope there is
now an effort to create a standard Ada95 "Interfaces.CPP"