From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!watmath!clyde!att!rutgers!apple!bbn!inmet!ishmael!inmet!authorplaceholder From: ron@inmet.UUCP Newsgroups: comp.lang.ada Subject: Re: Collective response to := messa Message-ID: <124000026@inmet> Date: 7 Dec 88 15:22:00 GMT References: <812@quintus.UUCP> Nf-ID: #R:quintus.UUCP:-81200:inmet:124000026:000:1233 Nf-From: inmet.UUCP!ron Dec 7 10:22:00 1988 List-Id: Garbage collection certainly does not come for free, but it is extremely useful. It frees the programmer from the need to repeatedly write sophisticated ADT deallocate routines and to deal with the potentially massive book-keeping requirements for determining whether an object is in fact garbage. In general, lack of GC forces a programmer to invest a lot of effort addressing issues that are not fundamentally related to the problem domain. My experience has also shown that problems of "slow heap leakage" are among the hardest errors to correct. An earlier posting claimed that a programmer should know what is and isn't garbage, and that GC is therefore not needed. This argument would never be made by a programmer with experience writing serious applications using both GC'd and non-GC'd languages. It's quite possible that those without GC'd programming experience don't even recognize the additional burden for what it is. I am not saying that garbage collection should or shouldn't be added to Ada. I haven't really thought about all of the issues; there are clearly pros and cons. However, the argument against GC loses much of its credibility if it contains an outright denial of the many positive aspects of GC.