Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[jsa@alexandria (Jon S Anthony)]

In article <EACHUS.96Oct14215330@spectre.mitre.org> eachus@spectre.mitre.org (Robert I. Eachus) writes:

> In article <JSA.96Oct11152501@alexandria> jsa@alexandria (Jon S Anthony) writes: 
> 
>   > But *languages* don't have GC.  Implementations of them do.  Even
>   > Meyer says little about GC in ETL - just that all *implementations*
>   > are *expected* to have it.
> 
>    I think that the point that is getting lost in this discussion is
> that, if your compiler had a garbage collector, and a switch to turn
> it on or off, what switch position would you use?

On.  Aside from those involved in various real-time circumstances, who
in their right mind wouldn't?


>    For some languages the freedom from deallocation calls makes the
> answer a "no-brainer."  Smalltalk, Lisp, and even C++ are much more
> useable with garbage collection.  (It would also fix a LOT of C
> programs, but I digress.)
> 
>    However, in Ada, most cases where you have garbage problems in
> other languages simply don't exist.  In particular, a function can

I disagree with this completely.  Because most cases where a GC is
useful is in the context of _user defined_ types and these occur
pretty independent of language.


> function is completed, without explicit use of the heap.  As long as
> compilers don't generate garbage for function returns, most of the
> need for GC goes away.

Wrong.  There are many cases (boatloads of cases) where long lived
instances should be shared among users but when they all go away the
used object should also go away.  Another is keeping various lists
around while a controlling agent needs the objects.  When the
controlling agent (owner) goes away the lists should.  Finalization
helps, but not in the general case.  This is so common I can't
understand how you could ever make such a claim.

>  The other case I often see is the complex data
> structure case where GC, especially conservative GC, is not the best
> cure.

??? Disagree (well, agree about the conservative bit).


>  In Ada a well writen data structure such as a tree that cleans
> up after itself currently only has one drawback--the built-in cleanup
> still occurs at the end of the program.

But that drawback is the whole point.  Having the cleanup occur at
program end is next to worthless for the vast majority of cases.


>  The "extra" effort during
> implementation to get the garbage management correct is trivial.  The
> last such package I wrote was about 1K lines, and maybe five were
> concerned with the deallocation process.

Too bad it doesn't do anything about the actual problem.


>    So if I had an Ada compiler with a GC switch, I'd probably only
> turn it on for testing--of the compiler. ;-) Your milage may vary, but

Clearly, the type of programs you are writing are different from mine
and most people I've ever discussed the issue with.  Perhaps you are
in the "real-time" arena.


> later freed by the OS--if you did everything correctly.  The real-time
> world is exactly that forgiving, and GC is not really much help.
> (There are memory leaks which exist even if garbage is collected, so
> you need to be able to explicitly break reference chains.)

Ah.  So you are in the real-time world.  That's fine.  But most
programs aren't.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com