> From: Stephane Richard
>
> I would like to push this question to the following:
>
> If Ada does not have a garbage collection, does it need one?

From a marketing perspective, the answer may be "yes".

In the software industry overall, garbage collection is high on the "must
have" list for an implementation language.  Why?  Because memory leaks are
such a huge problem.  People can argue forever about *why* memory leaks are
in fact such a big problem, but in the eyes of many, managing the lifetimes
of dynamically allocated objects is just one more burden from which
programmers should be relieved.  Are they right about this?  Who cares,
because right now we are talking about the marketing perspective :-)

Open Source advocate Eric Raymond discusses languages in a chapter of his
book in progress, "The Art of Unix Programming".  The chapter is entitled
"To C or not to C?" and you can read it at
http://www.tuxedo.org/~esr/writings/taoup/chapter3.html.  Notice the primacy
given to automatic storage management as the distinguishing feature of
modern languages, or languages that have a future.  It practically trumps
all other considerations.  While I don't share this perspective, I would
guess that it represents the views of many.

So, if there are prospective users for whom GC is the make-or-break issue,
the availability of a GC Ada implementation might help them to at least
consider Ada.

But there are some problems with GC as well.  One problem is that you must
pay something for it in system overhead.  You also may have to sacrifice
schedulability as well, you're willing to pay in overhead: real-time
(deterministic) GC can be done, but it is slower.

In the culture of IT geekdom, there is really no point in asking whether the
penalties for GC are worth it, since it seems to really be the only cure for
the plague of memory leaks (but not the only treatment... in recognition of
the practice of periodically restarting application servers to preempt the
inevitable memory-leak-induced crash, the ASP.NET platform provides for --
automatic scheduled restarts!  LOL...).  If you ask, "but where will the
extra cycles come from?" the answer is, "From Intel."  That's what we have
Intel for, to crank out ever-faster machines to accomodate things like GC,
right?

Someone always objects with some statement like, "Oh yeah, but what about if
you have, like, an airplane, and the collision-avoidance alarm is about to
go off but then the system has to stop for the GC to run, and the planes
crash into one another and everybody perishes in a giant fireball...
"where's my Mommy, I want my Mommy!"  "Sorry, son, that's the price you pay
for GARBAGE COLLECTION... at least it wasn't a MEMORY LEAK..."

Except we're not talking about Ada in airplanes here.  It's already in
airplanes.  We're talking about getting Ada into the stuff people buy on
Egghead.co -- oops.  OK, the stuff people buy from Amazon.com and Office
Depot.  You know, the other 95% of software that doesn't care if the GC has
to run every so often.

The other problem is that there are other types of resource leaks besides
memory leaks.  Anything that has to be claimed and then released is a
potential source of leaks: synchronization objects like mutexes, file
descriptors, connections to session-based services, etc.

GC doesn't cure these problems; moreover, other problems arise around the
attempts to link finalization/destruction with garbage collection, which
always falls short and must be shored up with hacks, and even with the hacks
you end up with something that is not altogether satisfactory (e.g. Java,
.NET).

> or does it
> just manage it's objects by their scopes and global availability?

Something like that.  Ada gives you kind of a cocktail of features that work
together to help guard against memory leaks:

        1) When you declare an access type, a storage pool is created for
           that access type.  When the access type goes out of scope, the
           storage pool is freed.  This ensures that a dynamically allocated
           object can't live longer than the access type that was used to
           allocated it.

        2) Accessibility checks (such as for access parameters).  These
           close some loopholes that can otherwise result in dangling      pointers.

        3) Controlled types, which allow you to do things like
           reference-counted storage management, by specifying whatever
           needs to be done for initialization, assignment and finalization.

>
> By that I am asking is would it be an actual advantage to have a garbage
> collector in the language?
>

I would say, it would have just about as much actual "silver bullet factor"
as in any other language, which in turn is less than it's made out to be.

Mark Lundquist