From: | ncohen@watson.ibm.com (Norman H. Cohen) |
Newsgroups: | comp.lang.java,comp.compilers,comp.lang.ada |
Date: | 29 Jan 1996 23:21:16 -0500 |
Organization: | IBM T.J. Watson Research Center |
References: | 96-01-037 96-01-085 96-01-097 96-01-100 |
Keywords: | translator, C++, Ada |
hbaker@netcom.com (Henry Baker) writes:
> Ada is by far the most frustrating language I have ever dealt with.
> Even after many programs and many, many hours with the reference
> manual, I would be loathe to attempt to predict that any of my
> programs would compile the first time.
That's a strange objection. When an Ada compiler rejects my source,
it is because compile-time consistency checks have caught me trying to
do something that does not make sense. I am grateful to have had the
mistake caught before I wasted hours debugging. I am far more
frustrated by C compilers that happily compile code containing the
kind of errors that an Ada compiler would have caught.
> There are far too many bizarre rules -- including some which no one
> can provide any comprehensible reason for.
There may be rules whose reasons you are unaware of, but not rules
without reasons.
> For many years, there ran in ACM Ada Letters a column called 'Dear
> Ada', which basically discussed (with unseemly relish, IMHO) all of
> these bizarre interactions of obscure rules.
I agree that this column sometimes focused too much on language
pathologies unlikely to arise in real programs. As a "language
lawyer", I enjoyed reading these columns, but some of them were not
appropriate tutorial material and created the false impression about
Ada that you have conveyed.
> Truly Ada is a worthy successor to PL/I in this regard.
No, the conversion and arithmetic-precision rules of PL/I led to nasty
surprises in run-time behavior. Pathological Ada programs might
sometimes surprise you by failing to compile, but they rarely have
surprising run-time effects.
> However, the single most important reason why Java is a _much_ better
> language than Ada-95 is the fact that Java does garbage collection and
> Ada does not. Twice now, the Ada language people have gone AWOL
> (absent without leave -- i.e., deserted) on the GC issue, and for no
> technically supportable reasons.
In fact, both Ada and Java allow, but do not require garbage
collection. It is impossible for a programming language to REQUIRE
garbage collection because, in the absence of an overspecified storage
model, it is impossible to define a semantic difference between the
presence and absence of garbage collection--it only affects how soon
you run out of storage. The Java language specification does express
the informal expectation that inaccessible storage will be reclaimed.
I agree that such behavior is desirable in many applications,
including web applets. However, Ada is designed to be used, among
other places, for time-critical and safety-critical applications, for
which garbage collection is undesirable.
The Ada language design was correct to make garbage collection
optional. It is regrettable that Ada implementers have not been eager
to provide this option, but I expect that to change in the future
because of market demands. In particular, the Ada compiler targeted
to the Java virtual machine (JVM) will have garbage collection on any
JVM implementation that provides it. Also, the free availability of
GNAT sources makes the addition of garbage collection to GNAT a very
tempting research topic for an ambitious graduate student.
Bottom line: Java programs do not contain any instructions
implementing garbage collection, but are targeted to run on
implementations of the Java virtual machine, and these implementations
provide garbage collection. Ada programs can also be targetted to run
on Java virtual machines, and when they are, they too enjoy the
benefits of garbage collection. The only platforms on which Ada
programs must run without garbage collection are those on which Java
programs do not run at all!
--
Norman H. Cohen ncohen@watson.ibm.com
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.