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

[Kyle Furlong]

John Reimer wrote:
> On Tue, 21 Nov 2006 21:51:35 -0800, Kyle Furlong <kylefurlong at gmail.com> 
> wrote:
> 
>> Steve Horne wrote:
>>> 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 ;-)
>>>
>>
>> Wow that was long, but good, make it an article, Walter?
> 
> 
> It was too long, but with good points.  If it were pared down, it would 
> read easier and the points might hit home even harder.
> 
> Concerning D and GC:
> 
> The problem is that most D apologists /DO/ advertise D as having the 
> best of both worlds when it comes to memory management, but C++ fans are 
> bound and determined to see D as practically a GC-only language: the GC 
> is one of the first points they always bring up.  They keep seeing it in 
> the same light as Java and other such languages.  It's unfair and 
> short-sited, but a typical response.
> 
> If you really take an honest look at OSNEWS posts and others, you will 
> realize that some of these people are literally annoyed at D and D 
> promoters for a reason deeper and unrelated to the language.  You can't 
> argue with that.  Some good considerations, like Steve's, just doesn't 
> hit home with those boys.
> 
> -JJR

I seriously think there is a sizable group of people who use C++ at 
their workplace, and for their hobbies, and maybe have written a 
convoluted something or other for Boost. These people have invested a 
huge ammount of time and effort to carve out something usable from the 
jungles that are the C++ lands.

These people fight D because they see how it will simply negate that 
time investment by making it irrelevant. When it comes down to it, 
someone who actually understands C++ in depth and can be productive in 
it is a very valuable person. If D becomes defacto, that skill set 
becomes much less valuable.

Thats not to say that someone who is at that level of understanding in 
C++ can easily adapt to D, but the psychology of it is that they have 
spent so much time into actually getting C++ to work for them that its 
an abhorrent idea for them to leave that behind.

Any reason they can grasp on to, they will. Any defect they can find, 
they'll point it out. Hopefully, over time, the smart ones will realize 
the dead end and move on to D.