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

[John Reimer]

On Wed, 22 Nov 2006 14:17:26 -0800, Mike Capp <mike.capp at gmail.com> wrote:

> John Reimer wrote:
>
>> Huh?  I'm not following.  I said it's unfair that
>> C++ users frequently see D as GC-only.  Your
>> response seems to indicate that this is not unfair,
>> but I can't determine your line of reasoning.
>
> I may be being naive.
>
> There's a difference between "a D program CAN ONLY allocate memory on  
> the GC heap"
> and "a D program WILL allocate memory on the GC heap".
>
> The first statement is plain wrong, and once you point out that malloc  
> is still
> available there's not much to discuss, so I can't believe that this is  
> what C++
> users have a problem with.
>
> The second statement is technically wrong, but only if you carefully  
> avoid certain
> language features and don't use the standard library.
>

Avoid new/delete, dynamic arrays, array slice operations, and array  
concatenation.  I think that's it... Further, new/delete can be  
reimplemented to provide custom allocators.  You can use stack based  
variables if necessary (soon with scope attribute, I hope).  For those  
special cases, knowing how to do this would be important anyway: careful  
programming knowledge and practice is a requirement regardless.  It is  
clearly possible in D.  You do not need to use the GC, if you feel the  
situation warrants such avoidance.

What I find strange is that some C++ users, who do not use D, make  
complaints about D in this area, then fall into a debate about C++ verses  
D memory management (when you mention the possibility of malloc or  
otherwise); no the argument is not over; when you prove the point that D  
is flexible here, they then digress into a discussion on how they can  
improve on C++ default memory management by implementing a /custom/  
solution in there own C++ programs.  How is this different than in D?  I  
think D makes it even easier to do this.  These guys likely would be  
serious D wizards if they ever tried it out.

They do find much to discuss whatever point is made!  That's why I said  
that it's not all about D; it's more about being entrenched in something  
they are comfortable with.

> Hence, if you don't want GC (because of concerns about pausing, or  
> working-set
> footprint, or whatever) then you're not using the language as it was  
> intended to
> be used. GC and GC-less approaches are not on an equal footing.
>

D is used however someone wants to use it.  For D based kernels, you must  
avoid using a GC and interface with a custom memory management system of  
some sort.  Does that mean kernels should not be programmed in D, because  
they avoid using a GC (apparently an intended part of the D language)?   
It's no problem avoiding the GC, so that tells me that's part of the  
intended workings of D as well.  I believe D was /intended/ to work with  
in both situations (though it's not a language that was intended to work  
without a gc, /all the time/).

It takes a different mindset to learn how to do this -- when and when not  
to use a gc, even in different parts of a program.  D Developers working  
3D games/libraries seem to realize this (and have worked successfully with  
the gc).  Some C++ users seem to want to argue from there C++ experience  
only.  So what we have is two groups debating from different  
perspectives.  Neither side is necessarily wrong.  But the argument is  
rather lame.  And C++ users that don't use D don't have the perspective of  
a D user -- which, yes, makes there accusations unfair.

GC is indeed the preferred way to go. But as a systems language, D cannot  
promote that as the one and only way.  It wisely leaves room for other  
options.  I support that.  And D has so many powerful feature, that  
subracting a precious few features from it to accomodate non-gc based  
programming is hardly damaging to D's expressiveness.


>> I'm sorry, Mike.  What post are you saying I'm
>> applauding?  I can't see how relating my applauding
>> to the conclusion in that sentence makes any
>> sense.  Is there something implied or did you mean
>> to point something out?
>
> Steve Horne's post -
> http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=44644
> - which I thought you were agreeing with. If I misread or got muddled  
> about
> attribution, apologies.
>


I supported what I thought was his conclusion.  Maybe I was confused?  I  
supported that he thought D was optimal for it's support of both gc based  
memory management and manual memory management at the same time, that no  
one dimension should be force over another.  I agreed with that.


> My point was just this: regardless of whether GC-less D is a reasonable  
> thing to
> want, if you take the attitude that it's not worth supporting then it's  
> hard to
> see why a C++ users' perception of D as "GC whether you want it or not"  
> is unfair.

It appears my "unfair" statement is slowly being dragged into broader  
realms.  I'm not so sure it's maintaining its original application  
anymore.  The discussion about making a GC-less standard library was  
debated here as to whether it was worth supporting or not.  That was  
another discussion.  A standard non-gc based library is likely not going  
to meet with massive approval from those already in the community who have  
experienced D for themselves, especially merely to attract the attention  
of a skeptical C++ crowd (although I admitted that it would be an  
interesting experiment; and Walter seems to have stated that it wasn't  
even necessary).  I doubt that would work anyway.

If it is "unfair" for C++ skeptics to be told that there isn't support for  
a non-gc library given your expression of how they perceive the message  
("GC way or the highway"), I'd have to disagree.  C++ skeptics are still  
operating from a different perspective -- one they are quite committed  
to.  If they are spreading mis-information about how D works because they  
are unwilling to test a different perspective, then it's kind of hard to  
feel sorry for them if they don't get what they want from a language they  
have most certainly decided they will never use anyway.  Naturally, the  
result for the D apologist, is that he'll never conve the C++ skeptic. But  
as others have mentioned in other posts, that goal is futile anyway.  The  
positive side-effect of the debate does appear to be education of others  
that might be interested in D -- it's an opportunity to intercept  
mis-information.

In summary, the GC is there and available for use if you want it. But you  
don't have to use it.  A good mix of GC and manual-memory management is  
fully supported and recommended as the situation requires.  There is no  
reason to fear being stuck with the gc in D.

I do have my own mis-givings about some things in D, but, as you probably  
guessed, this is not one of them.  And for the  most part, D is a very  
enjoyable langauge to use. :)

-JJR