OSNews article about C++09 degenerates into C++ vs. D discussion

[Steve Horne]

On Sun, 19 Nov 2006 15:28:33 -0800, "John Reimer"
<terminal.node at gmail.com> wrote:

>On Sun, 19 Nov 2006 14:59:19 -0800, BCS <BCS at pathilink.com> wrote:
>
>> Mars wrote:
>>> http://www.osnews.com/comment.php?news_id=16526
>>
>>
>> One issue brought up is that of D "requiring" the use of a GC.
>> What would it take to prove that wrong by making a full blown standard  
>> lib that doesn't use a GC, and in fact doesn't have a GC?

I don't know. Personally, I am all in favour of having the choice -
but remember, it's not just a matter of creating that library.
Maintaining two standard libraries would mean a lot of ongoing
headaches.

>Note, however, that C++ users, many who have grown dependent on manual  
>memory management, are looking for a reason to fault D.  I've actually  
>heard cases where C++ users lambast GC based languages: use of a GC  
>apparently creates "bad programming practices" -- imagine the laziness of  
>not cleaning up after yourself!

I agree - but I also strongly disagree.

The problem is that memory management isn't just about allocating and
freeing memory. It is closely coupled with newing and deleting, with
constructors and destructors, and therefore with wider resource
management issues.

Two problems can arise...

1.  Garbage collection isn't immediate. Resources can stay locked long
    after they should have been freed, because the garbage collector
    hasn't got around to destroying those objects yet. This can be a
    problem if you are trying to acquire further locks or whatever.

2.  Reference cycles. Take Java. It can garbage collect when there are
    reference cycles, sure, but it cannot know what order to destroy
    those objects in. Calling destructors in the wrong order could
    cause big problems.

    Solution - don't call the destructors (sorry, finalisers) at all.
    Just free the memory, since it doesn't matter what order you do
    that in.

    So that's it - Java doesn't guarantee to call finalisers. I don't
    know for sure that this is why, but it is the only good reason I
    can think of.

    If you think reference cycles are a theoretical rather than real
    problem, well, I'm afraid many practical data structures have
    them - even the humble doubly-linked list.

Either of these problems is sufficient on its own to mean that the
garbage collector cannot be relied upon. As the programmer, you have
to take responsibility for ensuring that the cleaning up is done. And
that, according to black-and-white reasoning, defeats the whole point
of garbage collection.

But then these problems, even counted together, only create issues for
a minority of objects in most code.

Awkward persons might observe that the rate of problems tends to
increase in lower level code, and that this is why the
applications-oriented language Java has more problems than the
very-high-level languages that also do GC such as Python. And those
same awkward persons might then point out that D explicitly targets
systems level code, aiming its sights at a somewhat lower level than
Java.

But lets put that point to one side for a bit.

Someone intelligent enough to consider shades of grey might still
argue that it is a good idea to develop good habits early, and to
apply them consistently. It saves on having these problems arise as
surprise bugs, and perhaps as a result of third party libraries that
you don't have source for and cannot fix.

I have a lot of sympathy with this point of view, and don't think it
can be lightly dismissed. It isn't just a matter of taking sides and
rejecting the other side no matter what. It is a valid view of the
issue.

The trouble is that the non-GC way is also prone to surprise bugs.

So, as far as I can see, neither approach is a clear and absolute
winner. I know it can seem as if GC is the 'modern' way and that
non-GC is a dinosaur, but good and bad isn't decided by fashions or
bandwagons. Both GC and non-GC have problems.

Now to consider that point I put to one side. D is explicitly aimed at
systems level code. Well, that's true, but in the context of GC we
have a rather skewed sense of high-level vs low-level - low level
would tend to mean data structures and resource management rather than
bit twiddling and hardware access. D systems level programming is
probably roughly equally prone to GC problems as Java applications
level programming.

In any case, D is a systems level language in the sense of
down-to-and-including systems level. Most real world code has a mix of
high-level and low-level. So in a single app, there can be a whole
bunch of high-level code where GC is a near perfect approach, and a
whole bunch of low-level code in which GC cannot be relied upon and is
probably just an unwanted complication.

And when there are two equally valid approaches, each of which has its
own advantages and disadvantages, and both of which could be valuable
in the same application, which should the serious programmer demand?
Particularly the systems-level programmer?

Right - Both!

But does it make sense to demand a separate non-GC standard library?
That seems to suggest a world where an application is either all GC or
all non-GC.

GC seems pointless if it doesn't happen by default, so the approach of
opting out for specific classes when necessary seems, to me, to be as
close to ideal as you can get. And even then, there's the proviso that
you should stick to the default approach as much as possible and make
damned sure that when you opt out, it's clear what you are doing and
why. It's not a GC-is-superior thing, just a consistency thing -
minimising confusion and complexity.

In that case, with GC as the default and with opting out being
reserved for special cases, you're probably going to carry on using
the GC standard library anyway.

As for embedded platforms, if malloc and free would work, so would
garbage collection. If not, you probably can't use any conventional
standard library (and certainly not data structure library code), and
should be using a specialised embedded development library (probably
tailored for the specific platform).

In other words, the only benefit I can see to having a separate non-GC
library is marketing. And it seems that a better approach is to
educate people about the benefits of dropping the old either-or
thinking and choosing both.

AFAIK, there are two competitors in this having-both approach, and
they are both C++. Managed C++, and C++ with a GC library. And they
all get it wrong IMO - you have to opt in to GC, not opt out. If GC
isn't the default, you get new classes of bugs - the 'oh - I thought
that was GC, but apparently not' and 'damn - I forgot to specify GC
for this' bugs.

So there we are, D is not only already perfect, it is the only
language available that has achieved this amazing feat ;-)

-- 
Remove 'wants' and 'nospam' from e-mail.