Re: Why C# and Java have got it wrong

From: Alf P. Steinbach (alfps_at_start.no)
Date: 02/06/04 

Date: Fri, 06 Feb 2004 02:25:46 GMT

On Thu, 5 Feb 2004 12:21:51 +0200, "David Turner" <david@firepro.co.za> wrote:

>Article for your reading (and flaming) pleasure:
>
>http://www.turn.co.za/david/gcch.html

To be fair your C# examples should be using 'using'.

And to sum up, to possibly avoid knee-jerk reactions here, the
main problem with your article is that it assumes that C#/Java
(garbage collection) is in direct competition with e.g. C++ (RAII),
which as far as I know, after decades of programming, is not true.

But I agree that garbage collection in Java and C# is a problem:

  1) Garbage collection is inefficient in actual systems.
     It can be _very efficient_ in isolation, but in practice it
     soaks up virtual memory from a very willing provider, namely
     the operating system. And as is the case when one mindlessly
     accepts freebies from very willing providers, without proper
     protection, the cost may be a sickness. May God destroy all
     Java Swing-based applications.

  2) Garbage collection gives a false sense of security.
     Again, the Java Swing library is an example. The garbage
     collector cannot collect objects that still have references
     to them, although these references are long forgotten by the
     program. Probably installed in call-back 'manager' objects.

  3) Garbage collection requires meta invariants for classes.
     Meta-invariants are precisely what constructors are meant to
     get rid of: once you have successfully constructed an object,
     you have a working object that fulfills the direct invariant
     of its class. But to ensure that as the object is used, its
     logical destruction must be coupled to its deallocation. In
     C++, for example, that is the case; with GC as in Java and C#
     it is not the case, so you can easily encounter objects that
     have been cleaned up, logically destroyed, but still exist.

Having said that, though, these problems seem to a large extent to
be _acceptable_ given the simplification GC brings to the language
that is designed with GC in mind. And regarding point (1) it is
simply a Quality Of Implementation problem. The fact that it still
is a problem may indicate that it's simply not problematic enough...

For example, C++, which I love and hate, is not a language well
suited for the less experienced programmers who constitute the main
work force on almost any real-world project, and much of the reason
for that complexity is that C++ is not designed with GC in mind.

On the other hand, C++ and similar languages are needed for the things
that can only reasonably be implemented using such languages, so it's
not "use C#/Java always or else C++ always", it's "use C#/Java for
whatever these languages are well-suited for, use C++ for whatever C++
is well-suited for, and if more than one language can cut it, then
use other factors to decide, on a case-by-case basis".

Relevant Pages

  • Re: Garbage Collection - Stop Making Trash
    ... >> cases that require garbage collection. ... > figuring out why anyone would want to perturb a language like ... There are also many programmers who do not desire it. ... Reread and try again. ...
    (comp.lang.cpp)
  • Re: type checking
    ... >it's not far from your favourite SWIG-supported language. ... when its constructor raised an exception. ... It hasn't really been an issue so far, but I guess C# constructors ... This is one issue I already have with Java/C# style garbage collection ...
    (comp.lang.python)
  • Re: Optimizing simple calls in a dynamically typed language?
    ... GC (which is non-trivial due to polymorphism). ... collector in a polymorphically typed language is difficult in ways ... to perform type reconstruction during garbage collection and do not ... Polymorphic Type Reconstruction for Garbage Collection without ...
    (comp.compilers)
  • Re: Java equivalent of C++ Spirit or Boost Graph Library ?
    ... So I'm assuming that he wants his language to feature garbage collection too. ... have to consider /whether/ that property can be engineered into some design is ...
    (comp.lang.java.programmer)
  • Re: why kernel in C
    ... Your point above may very well be the reason. ... illustrate that you can do GC without them, while keeping the language ... However I tend to think that reference-counting is quite an affective ... do garbage collection, which is not the case, but they need to believe ...
    (comp.os.linux.development.system)