Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

Dmitry A. Kazakov wrote:
On Wed, 29 Jul 2009 07:38:53 -0400, Oxide Scrubber wrote:

learn2code@xxxxxxxxxxxx wrote:
["Followup-To:" header set to comp.lang.ada.]
Sorry, no can do. You write complete nonsense in four newsgroups, you get corrected in four newsgroups.

On 2009-07-29, Ray Blaak <rAYblaaK@xxxxxxxxxxxxxxxxxx> wrote:
fft1976 <fft1976@xxxxxxxxx> writes:
My problem with it is the lack of a garbage collection. That is just not
acceptable to me these days. If you manually allocate memory, then you
pretty much have memory bugs, it's as simple as that.
That is simply not true. If you don't know how to do resource management
properly, you're not ready to write commercial code in any environment.
What utter balderdash. You make GC sound like training wheels, when in fact it is very useful even for major production-code systems.

Consider memory management of an object that is shared and passed around at need among many related parts of a program. Keeping track of when it's no longer in use rapidly becomes nontrivial as the complexity of the code using it goes up. Eventually, you'll be reference counting or doing something else like that, and before long, you'll end up with an ad-hoc, informally specified, slow, bug-ridden implementation of half of a garbage collector. (This will probably in turn be a part of an ad-hoc, informally specified, slow, bug-ridden implementation of half of Common Lisp.)

This is good illustration of the point - GC is harmful.

Baloney.

There are relationships between the object and its clients around the
program which are far more complex and beyond "you die before me", the only
relationship maintained by GC.

The relationship maintained by GC is "you die only when no longer in use". The relationship maintained by such primitive mechanisms as C++ destructors is "you die before me".

That is why weak, strong references etc are introduced.

Those can help sometimes with certain infrequent situations, such as caches from which you want objects to sometimes expire. Of course, GC weak references have the benefit that when the object is deallocated, the weak references are set to null instead of simply becoming bad pointers the use of which will crash the program.

The result is a mess.

Bollocks.

The point is, relationships between objects is key a part of OO design. To
leave that to GC in hope that it will somehow sort out things is
irresponsible.

That's why we don't leave object relationships to the GC. Indeed, I don't know of any GC that decides method parameters and instance fields and suchlike for you. :)

Why not save yourself the trouble and use a real GC, then?

Sure, by using scoped objects whenever possible. That is 90% of all cases.

And for the other 10%, GC is a godsend. Neverminding the efficiency benefits.

There rest 10% are special cases, GC could not reasonable handle anyway.

What a crock.

To verify if it could is far more work than to analyze the case and to
maintain the relationships accordingly.

Really? But even if implementing a GC is more work than implementing manual memory management for a particular application, the GC only has to be implemented *once*, as a library or as part of a VM or other runtime, and manual memory management has to be implemented anew for *every new application* that doesn't use GC instead.

So what GC proponents do? They just do not care

Piffle.

and young programmer simply do not know that there could be
problems. Nobody told them...

Problems? Like?

Let's see, GC tends to be associated with exactly three classes of problems:
1. Packratting. The only way (short of not clearing a non-GC-able
resource) to leak with a GC. Solved by avoiding global variables,
basically, and making sure long-lived collections have either
weak references in them or some logic to weed out stale entries
from time to time. Java's LinkedHashMap has removeEldestEntry
to facilitate this sort of thing, and Java also has a WeakHashMap.
2. Pauses, which impair responsivity of interactive apps. Modern
concurrent generational collectors tend to produce very little in
the way of pauses.
3. General slowness. This is usually a result either of very large
amounts of memory being needed, or of packratting. When very large
amounts of memory are needed, the thing will get slow due to
paging no matter what, and packratting can be dealt with; see
above. Modern GCs are much faster than older ones, also. In the
typical case of few large, long-lived objects but tons of small
and short-lived ones, modern GCs spend less time collecting than
an equivalent manual-memory-management program spends in malloc
and free.

GC is harmful.

Hogwash.

Especially since a properly-used GC will actually improve execution speed.

I don't believe that.

Believe it or not, it's still true.

Where from a GC might learn that the objects can be
allocated, say, in an arena?

Does not compute.

In a concurrent environment GC, or with objects requiring
finalization GC is a sheer disaster.

Balloonjuice.

Concurrent GCs exist, nevermind GCs that play fairly nicely with concurrent application code (without necessarily being concurrent themselves).

As for objects requiring finalization, those tend to be few and far between. (It would be useful if the "needs finalization" flag could be canceled, e.g. when a stream object was closed explicitly. In an ideal world, the OS would also use garbage collection so things like window handles and file descriptors wouldn't be in finite supply; even leaving an OutputStream hanging would not be a problem assuming that after a certain amount of idle time it flushed itself and released any locks it held.)
.

Relevant Pages

  • Re: Article of interest: Python pros/cons for the enterprise
    ... from many articles and postings across the internet memory management ... There are other downsides to garbage collection, ... not the way it goes in practice nowadays, ...
    (comp.lang.python)
  • Re: C vs C++ in Embedded Systems?
    ... >>the garbage collection system be able to find every pointer that it needs ... >>ensuring that all pointer variables actually point to allocated memory. ... references, by definition, in these languages. ...
    (comp.arch.embedded)
  • Re: C++ Garbage Collector on VMS?
    ... Boehm GC, afaict, is very popular among such ... or how it relates to what you are doing in lisp. ... about the Boehm GC nor what triggers its doing a garbage collection ... definitions and pointers were given "memory" from a free area. ...
    (comp.os.vms)
  • Re: How does "new" work in a loop?
    ... garbage collection. ... memory that is not being used. ... It's not a matter of the reference being removed. ... Since it was a production system I used great ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: More on garbage collection
    ... but adding garbage collection is a disaster. ... on the memory layout. ... Please note that this is a theoretically soluble problem. ... All garbage collection languages that I know of fail ...
    (sci.crypt)
Loading