| What's wrong with ada is that it seems to be extraordinarily difficult to
implement which is witnessed by the current absence of a good implementation
(to my knowlege, there aren't any).
Given this difficulty, if the DoD needs ada compilers targeted for a large
variety of machines, they're either going to have to pay through the nose
for them (more tax dollars), or the ada effort has cut itself off at the knees.
But to answer your question: ada is great language. But so is English.
But we can't seem to produce compilers very easily for either. I think
ada is an example of the PL/I design approach ("often referred to as the
kitchen sink approach") taken to a new extreme.
Given:
1) the long startup time to produce an ada compiler, 2) the cost of doing #1,
3) the expense of having to train ada programmers, 4) the complexity of the
language, 5) the probable unavailabilty of the language because of #1 and #2,
6) the probable low quality of the compilers that will be available because
of #1 and #2, 7) the probable limited supply of top notch ada programmers
because of #3 and #4,
I think ada is a singularly spectacular failure at addressing the
needs of the DoD. But this is what we have come to expect from the military.
I think a far more sensible approach is the VAX/VMS approach of using the
language that is most appropriate for the component you are concerned with
and then combining the components in the multi-language environment.
One mans opinion.
db
|
| I myself, am an ADA advocate. And, I will attempt to justify it when possible.
Granted, ADA in and of itself, may be hard to implement, train programmers,
etc as mentioned in .2; However, to "defend" DoD's choice, one of the reasons
it was designed for (I understand) was that DoD had about 230 different
languages that they wrote software in (or was that for 230 different
architectures?), was for transportability across a wide variety of of
hardware. Try taking any program written in a language on the VAX and
move it somewhere else, and 1) have that language available there, 2)
have the exact same variant of it there, and 3) have it compile and work
correctly.
Yes, it will take awhile for ADA to become popular, and wide spread, but
when it does (if it does?), I think DoD will be better off.
I believe ADA will allow you to design and code any application that
can be coded in BLISS, as the language gives you access to all the
nitty gritty details you may need, while not getting bogged down like
BLISS does with the dots, the ugly field structure stuff, parameter
passings, ref this, bind that, etc.
And, it gives you all the power and flexiblity and structure you want in
a higher level language, with type checking, parameter checking, etc.
I actually like BLISS as a language too, and code heavily in it; however
if I had a choice, I would write in ADA any day. And, there is no reason
why an ADA compiler cant write as good or better optimized code as
BLISS. I dont mean to imply that ADA and BLISS are at the same level; just
that ADA can address many (I think all) of the concerns of people who
feel they should write in BLISS, or C, or PASCAL, or whatever.
|
| (1) Credentials,
I am working on the DEC, VAX Ada compiler project. It is public knowlege
that DEC is working on an Ada compiler for VAX/VMS.
(2) What is Wrong With Ada,
as with any language, there are trade off's being made. Some are
. Implementation complexity
. Power, Range of use
. Ease of use
. Ease of learning
. Politics
Implementation Complexity...
Partly caused by the GOAL (very powerful language).
Partly caused by the fact the language was designed before implemented,
hence some (very few) surprises.
It was not a goal to make it easy to implement. Implementation cost is
paid (essentially) once.
Power, Range of use...
Adds to implementation and learning time BUT Ada is very subsettable (ie
you need only teach small portions at a time).
Ease of Use...
Ease of Learning...
Cross-compilation checking seems to be the thing this affects most. These
are NOT that difficult to implement.
Ada was designed to be READ, not WRITTEN, and this shows up in some areas,
eg it is a little more verbous than Pascal. This does not appear to affect
compiler complexity.
Politics...
To get Ada standardised before any implementation was completed was a major
POLITICAL achievement. It means that Ada WILL BE probably the most standard
language in the industry, even across rival companies where in the past
there has been a tendency to 'lock you customers in' with non-standard
goodies.
The cost of this has been that some aspects of the language could be
designed better but wont be (at least for a while) because that would
require re-doing the politics.
Okay - so is WRONG with Ada.
() Procedures, Functions, Packages AREN'T objects/values so you can't
have a dispatch table which is an array of procedures for example.
() It still has far too many 'implementation defined' features, such as
order of evaluation of parameters.
() The PRIVATE mechanism complicates the implementation because it allows
'forward' types in strange ways. This complicates things somewhat.
package P is
type T is private;
type R is record C : T; end record;
private
type T is array(1..10) of R;
end package;
is an example of a circular type that needs special compiler support
to detect.
A better scheme would have been
package P is
type T is private array(1..10) of INTEGER;
type R is record C : T; end record;
end package;
() Overloading complicates the implementation, BUT IS AN ESSENTIAL feature
of the language. All languages have it 'somewhere' - Ada makes it
user-useable.
Why aren't there Ada compiler's out there?
1. There are - NYU-Ada/ED, ROLM/Data General, Western Digital, maybe
Telesoft (still in midst of validation)
2. The language is LARGE - hence it takes longer
3. The language only just truely stabilised. Ada '82 is VERY different
'inside' to Ada '80, and still has some unresolved issues
4. Lack of experience - until its been done a few times IN THE LITERATURE
implementors are 'feeling' their way forward. Often you need to go back
and rethink earlier decisions as you come across the next feature of the
language that, surprise, cuts across earlier design decisions
5. The language has concepts (dynamic sized objects, tasks, generics) that
are not in other languages - hence often OPERATING SYSTEM support is
needed, existing code generators are inadequate, etc.
In short - it is complicated...
/Bevin
PS: It is not clear that 'being a trivial language to implement' has done either
C or Pascal any favours - it has encouraged a wide range of poor and
inconsistent implementations.
|
| Of the available compilers you mentioned, how many are considered to be
production quality? In my note I made that distinction. All of the ones you
mentioned that I've heard of have nearly unusable compilation speed and do
little or nothing in the way of optimization.
Anyway, I'm not going to compare ada to APL (APLs and oranges), but I can't
resist stating that APL is probably the most consistent language accross
systems even in the absence of an APL standard. The reason is that the
functions which make up the whole of APL were "standardized" by the Greek
mathematicians. Nearly of all the functions are directly taken from
mathematical, logic, array and set theory. Of course, extensions may differ,
but you can write nearly any non-standard APL program in what is considered to
be "standard" APL.
db
|
|
NYU-Ada/ED - barely useable as a teaching tool
ROLM/Data General - good enough to charge $80,000 for and is selling DG
machines for them. True its optimizing compiler, and only 10 users
swamp the equiv. of a 780.
Western Digital - serious limitations on the size of programs, probably will
be removed in the near future. There has been a tie up with Tartan
Labs that may produce a high quality compiler sooner or later
Telesoft - don't know much about quality
/Bevin
|