Walter Bright wrote:
> John Reimer wrote:
>>> Wow that was long, but good, make it an article, Walter?
> 
> I think it is good material for an article.
> 
>> 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.
> 
> 
> A common misconception that people have against D is that since D has core arrays, strings, and complex numbers, that therefore it is not possible to create user defined types in the library. They'll say things like "I prefer to use C++ because I can create my own types!" I patiently explain that this is not so, that there is nothing stopping one from creating their own user defined D types. And then they come back a week, a month later and repeat the same misinformation. Sigh.
> 
> 
>  > 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.
> 
> That's to be expected. Many people have bet their careers on C++ being the greatest ever, and nothing can change their mind. D is a personal affront to them. It doesn't really matter, though, because if you attend a C++ conference, take a look around. They're old (my age <g>). Someone once did a survey of the ages of D adopters, and found out they are dominated by much younger folks.
> 
> And that, my friends, is why D is the future.

Because I'm the future? :D (21 here)

Kyle Furlong wrote:
> John Reimer wrote:
>> On Tue, 21 Nov 2006 21:51:35 -0800, Kyle Furlong <kylefurlong@gmail.com> wrote:
>>
>>> Steve Horne wrote:
>>>> On Sun, 19 Nov 2006 15:28:33 -0800, "John Reimer"
>>>> <terminal.node@gmail.com> wrote:
>>>>
>>>>> On Sun, 19 Nov 2006 14:59:19 -0800, BCS <BCS@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.

Actually, I think that anyone who's put a lot of effort into Boost-style template code will have a huge list of C++ quirks that they wish would be fixed. My first impression of D was "there's loads of cool stuff in here that I wish was in C++, but the templates aren't good enough, because there's no IFTI". My second impression was there was enough interesting features (like mixins and static if) to give D a go despite the absence of IFTI.
Well, now that we have IFTI and tuples(!) I seriously don't think any template affectionado is likely to evaluate D negatively in that regard.
Once the word gets around, I think there'll be a lot of defections.

Kyle Furlong wrote:
> 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.

How true. And because it's on an emotional level, most may not even be aware of it, which makes it that much harder to handle, for us and for themselves.

> 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.

Here, as in so many other situations, we have to come out as winners (or at least not losers) from the arguments. These people will not be converted, but gradually many in the audience will convert. That's simply the dynamics of Public Debate, and it's been like that ever since talking was invented in the first place.

So, fighting with diehards is something that simply belongs to the current phase in D's history. And it's not about winning them over, it's about the bystanders, the audience, the silent masses.

Don Clugston wrote:

> Well, now that we have IFTI and tuples(!) I seriously don't think any template affectionado is likely to evaluate D negatively in that regard.
> Once the word gets around, I think there'll be a lot of defections.

Metaprogramming in C++ is OOP in C all over again.  Sure you can do it, but...  they definitely didn't have that in mind when they designed the language, so it ain't gonna be pretty.

--bb

Walter Bright wrote:
> John Reimer wrote:
>>> Wow that was long, but good, make it an article, Walter?
> 
> I think it is good material for an article.
> 
>> 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. 
> 
> A common misconception that people have against D is that since D has core arrays, strings, and complex numbers, that therefore it is not possible to create user defined types in the library. They'll say things like "I prefer to use C++ because I can create my own types!" I patiently explain that this is not so, that there is nothing stopping one from creating their own user defined D types. And then they come back a week, a month later and repeat the same misinformation. Sigh.

Shadows of c.l.c++.m? :-)  I think C++ does a fairly good job of allowing users to define pseudo-types, but am not convinced it is worth the consequences.  Implementing a type correctly in C++ is somewhat complicated, what with operators, various ctors, dtors, etc.  And this complexity spills over into how non-type objects must be defined, increasing the chance of bugs from a missed ctor or dtor.  Perhaps this sort of thing should be done in a meta-language rather than user code. As for D, I don't see the slippery slope that some C++ folks seem to. Floating point reals are a part of the language, so why not complex?  It seems a natural fit.  Same with dynamic arrays and maps.  With GC, there's no reason not to have such features in a language.  As you've said, if you don't want to use them there's no stopping you from creating a library version.

>  > 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.
> 
> That's to be expected. Many people have bet their careers on C++ being the greatest ever, and nothing can change their mind. D is a personal affront to them. It doesn't really matter, though, because if you attend a C++ conference, take a look around. They're old (my age <g>). Someone once did a survey of the ages of D adopters, and found out they are dominated by much younger folks.

I don't think conference attendance is completely representative of typical C++ users.  Conferences are viewed as "training" so attendees will typically be people who have been in the workplace for a while are are looking to improve their skills or learn new things.  Conferences are also expensive, so young employees are less likely to get corporate funding to attend.  That said, I do agree that C++ is an "older" language in terms of its users, and that D is much "younger" in this respect.  It makes perfect sense.  C++ has been around for a long time and D has not, and few professional programmers seem inclined to learn new things.  If anything, they're more likely to refine their existing skill set and stick to their "specialty."

One thing that struck me about SDWest is that few of the C++ conference attendees were what I'd consider "experts."  And the few that were, were all c.l.c++.m regulars and many were even involved in organizing things somehow.  I did meet a few young programmers--one was an electrical engineer with far more experience in C than C++ and wanted to learn more about the language, and the others were Bay Area locals from one particular company, somewhat more competent with C++, but looking to learn a bit as well.  I suppose this is to be expected with a conference, but for the C++ series I expected attendance to be a bit different.


Sean

Walter Bright (and assorted quoted people) wrote:
> >
> > [John Reimer] 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. [...] It's unfair and
> > short-sited, but a typical response.

It's not that unfair. D has good support for RAII now - possibly better than C++'s on balance, though with different strengths and weaknesses. But GC-less programming (as opposed to GC+manual) is ignored - no compiler checking, no standard library beyond C's unless you're willing to vet the source with a fine-toothed comb. The post John is applauding here states this assumption explicitly: that there's no need for or value in a GC-less library.

What scares the bejesus out of me is a future combination of:

1) a copying collector,
2) multiple threads and
3) raw pointers.

We talked about this about a year ago, and didn't come up with an obvious solution. (Though I may have missed one in between drive-by lurkings.) Manual pinning is waaay too easy to get wrong, IMHO.

>  > some of these people are literally annoyed at D and D
>  > promoters

Not all of those people are diehards, though. I like D, and I sometimes get annoyed by D promoters. There does seem to be an underlying attitude among some of the younger and more enthusiastic posters here that D is essentially perfect for everything, that anyone expressing reservations is automatically a closed-minded fogey, and that no amount of experience with other languages is relevant because D is a whole new paradigm.

> That's to be expected. Many people have bet their careers on C++ being the greatest ever, and nothing can change their mind.

Some may see it that way, but it's a bit of a non sequitur. Even if no new C++ projects were launched from now until the end of time, there's more than enough legacy code out there to keep a competent C++ programmer (un)comfortably employed maintaining it for the rest of their career, if that's really what they want to be working on. It's COBOL all over again. If anything, their knowledge becomes _more_ valuable if people coming onto the job market are learning D instead; basic supply and demand.

> It doesn't really matter, though, because if you attend
> a C++ conference, take a look around. They're old (my age <g>). Someone
> once did a survey of the ages of D adopters, and found out they are
> dominated by much younger folks.

Well, yes. Every new language is dominated by younger folks, whether it's eventually successful or not. Something about the combination of copious free time and unscarred optimism...

Mike Capp wrote:
> Walter Bright (and assorted quoted people) wrote:
>>> [John Reimer] 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. [...] It's unfair and
>>> short-sited, but a typical response.
> 
> It's not that unfair. D has good support for RAII now - possibly better than C++'s
> on balance, though with different strengths and weaknesses. But GC-less
> programming (as opposed to GC+manual) is ignored - no compiler checking, no
> standard library beyond C's unless you're willing to vet the source with a
> fine-toothed comb. The post John is applauding here states this assumption
> explicitly: that there's no need for or value in a GC-less library.
> 
> What scares the bejesus out of me is a future combination of:
> 
> 1) a copying collector,
> 2) multiple threads and
> 3) raw pointers.
> 
> We talked about this about a year ago, and didn't come up with an obvious
> solution. (Though I may have missed one in between drive-by lurkings.) Manual
> pinning is waaay too easy to get wrong, IMHO.
> 
>>  > some of these people are literally annoyed at D and D
>>  > promoters
> 
> Not all of those people are diehards, though. I like D, and I sometimes get
> annoyed by D promoters. There does seem to be an underlying attitude among some of
> the younger and more enthusiastic posters here that D is essentially perfect for
> everything, that anyone expressing reservations is automatically a closed-minded
> fogey, and that no amount of experience with other languages is relevant because D
> is a whole new paradigm.
> 

If this is talking about my first post in this thread, thats not what I said. I merely said that trying to apply the conventional wisdom of C++ to D is misguided.

Is that incorrect?

>> That's to be expected. Many people have bet their careers on C++ being
>> the greatest ever, and nothing can change their mind.
> 
> Some may see it that way, but it's a bit of a non sequitur. Even if no new C++
> projects were launched from now until the end of time, there's more than enough
> legacy code out there to keep a competent C++ programmer (un)comfortably employed
> maintaining it for the rest of their career, if that's really what they want to be
> working on. It's COBOL all over again. If anything, their knowledge becomes _more_
> valuable if people coming onto the job market are learning D instead; basic supply
> and demand.
> 
>> It doesn't really matter, though, because if you attend
>> a C++ conference, take a look around. They're old (my age <g>). Someone
>> once did a survey of the ages of D adopters, and found out they are
>> dominated by much younger folks.
> 
> Well, yes. Every new language is dominated by younger folks, whether it's
> eventually successful or not. Something about the combination of copious free time
> and unscarred optimism...

On Wed, 22 Nov 2006 11:10:36 -0800, Mike Capp <mike.capp@gmail.com> wrote:

> Walter Bright (and assorted quoted people) wrote:
>> >
>> > [John Reimer] 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. [...] It's unfair and
>> > short-sited, but a typical response.
>
> It's not that unfair. D has good support for RAII now - possibly better than C++'s


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.


> on balance, though with different strengths and weaknesses. But GC-less
> programming (as opposed to GC+manual) is ignored - no compiler checking, no
> standard library beyond C's unless you're willing to vet the source with a
> fine-toothed comb. The post John is applauding here states this assumption
> explicitly: that there's no need for or value in a GC-less library.
>


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?

Confused,

-JJR

Sean Kelly wrote:
> I don't think conference attendance is completely representative of typical C++ users.

You're right, it isn't, and it's surely unscientific to use them as a representative sample. On the other hand, I've been attending such conferences for 20 years, and the crowd seems to have gotten older with me.

Georg Wrede wrote:
> So, fighting with diehards is something that simply belongs to the current phase in D's history. And it's not about winning them over, it's about the bystanders, the audience, the silent masses.

That's right. I don't expect any of the career C++ people to ever use D. My purpose in engaging them is to:

1) correct misinformation

2) provide answers to important questions about D

3) discover where glaring weaknesses in D are so they can be dealt with

so that people who are evaluating which language to use will get the information they need.