BCS wrote:
> Interesting, in both places snk_kid keeps harping on his claim that "D is a failed attempt to be truely better than C++ in *all aspects* which it isn't."

I've seen similar claims, and what they are are excuses to not use D regardless. It doesn't matter to these people what D can do that is utterly impractical in C++.

Another problem happens when people try to transliterate C++ code into D. That doesn't work very well - you have to rethink things a bit.

Nevertheless, I still regard D as a better C++. Not in terms of being a true superset, but in terms of being a better solution to the same types of problems that C++ is targetted at. Note that C++ isn't a true superset of C, either, although it is billed as a "better C".

Mike Parker wrote:
> clayasaurus wrote:
>> Jarrett Billingsley wrote:
>>> "David Medlock" <noone@nowhere.com> wrote in message news:e819r5$h8i$1@digitaldaemon.com...
>>>
>>>> Read my post on LTU and snk_kid's response:
>>>
>>> snk_kid is just another C++ fanboy.  I'm dealing with him on gamedev.net too.
>>>
>>
>> link?
> 
> Shame on you, Clay, for not keeping up with my blog!
> 
> http://www.gamedev.net/community/forums/topic.asp?topic_id=400729

aye, I've been busy lately :-P

Walter Bright wrote:
> 
> Another problem happens when people try to transliterate C++ code into D. That doesn't work very well - you have to rethink things a bit.

In my experience, transliterating C++ to D allows for a lot of code to simply be tossed out.  It's issues like this that aren't obvious from simply reading a spec.

> Nevertheless, I still regard D as a better C++. Not in terms of being a true superset, but in terms of being a better solution to the same types of problems that C++ is targetted at. Note that C++ isn't a true superset of C, either, although it is billed as a "better C".

I've yet to do the same level of work in D that I do in C++, but so far I'd have to agree.  And I'm looking forward to some more ambitious projects once the framework is sorted out sufficiently.

That said, I do think D's lack of any sort of const checking may be an issue for large projects (I haven't done this level of development in Java so I don't have a good non-C++ basis for comparison here).  I know the issue has been beaten to death in the past, but perhaps we could do with a constructive discussion before 1.0 appears on the horizon?  I've become convinced that the "default everything to const" method seems ideal, but this seems like something that should really be done before 1.0 if it's going to happen?


Sean

Sean Kelly wrote:
> I've become convinced that the "default everything to const" method seems ideal, but this seems like something that should really be done before 1.0 if it's going to happen?
> 
> 
> Sean

I agree. Walter posted somewhere in comp.lang.c++.moderated (I think it was there) that he thinks he should have made D like this from the start, but that it's too late now. With that, I disagree. We're not at 1.0 yet: it's not too late to break even every single line of D code out there.

Deewiant wrote:
> I agree. Walter posted somewhere in comp.lang.c++.moderated (I think it was
> there) that he thinks he should have made D like this from the start, but that
> it's too late now. With that, I disagree. We're not at 1.0 yet: it's not too
> late to break even every single line of D code out there.

And if it's going to be added post 1.0, there will be even more code that will have to be modified to use all the new cool features that D 2.0 will provide :>

Walter, if you think that it's too late because it might break a lot of code, why not let the community decide whether it would be very bad or not ?


-- 
Tomasz Stachowiak  /+ a.k.a. h3r3tic +/

Deewiant wrote:
> Sean Kelly wrote:
>> I've become convinced that the "default everything to const" method seems ideal, but this seems like something that should really be done before 1.0 if
>> it's going to happen?
> 
> I agree. Walter posted somewhere in comp.lang.c++.moderated (I think it was
> there) that he thinks he should have made D like this from the start, but that
> it's too late now. With that, I disagree. We're not at 1.0 yet: it's not too
> late to break even every single line of D code out there.

And there's nothing wrong with making it a warning for N releases, or allocating a new flag for experimental features, assuming it really is the correct approach.  Also, with discussion, we may even be able to prepare for upcoming changes or put off creating code-level hacks to mimic the same behavior.


Sean

Sean Kelly wrote:
> Walter Bright wrote:
> 
>>
>> Another problem happens when people try to transliterate C++ code into D. That doesn't work very well - you have to rethink things a bit.
> 
> 
> In my experience, transliterating C++ to D allows for a lot of code to simply be tossed out.  It's issues like this that aren't obvious from simply reading a spec.
> 
>> Nevertheless, I still regard D as a better C++. Not in terms of being a true superset, but in terms of being a better solution to the same types of problems that C++ is targetted at. Note that C++ isn't a true superset of C, either, although it is billed as a "better C".
> 
> 
> I've yet to do the same level of work in D that I do in C++, but so far I'd have to agree.  And I'm looking forward to some more ambitious projects once the framework is sorted out sufficiently.
> 
> That said, I do think D's lack of any sort of const checking may be an issue for large projects (I haven't done this level of development in Java so I don't have a good non-C++ basis for comparison here).  I know the issue has been beaten to death in the past, but perhaps we could do with a constructive discussion before 1.0 appears on the horizon?  I've become convinced that the "default everything to const" method seems ideal, but this seems like something that should really be done before 1.0 if it's going to happen?
> 
> 
> Sean

As someone with a substantial body of D code, I'd be happy to retrofit the whole darned thing to get const. I'd say "go for it" (as long as it supports returning an array as a const, without .dup being involved)

Deewiant wrote:
> Sean Kelly wrote:
>> I've become convinced that the "default everything to const" method seems ideal, but this seems like something that should really be done before 1.0 if it's going to happen?
>> 
>> Sean
> 
> I agree. Walter posted somewhere in comp.lang.c++.moderated (I think it was
> there) that he thinks he should have made D like this from the start, but
> that it's too late now. With that, I disagree. We're not at 1.0 yet: it's not
>  too late to break even every single line of D code out there.

I found the post in question, BTW. Here's the Google Groups link:

http://groups.google.com/group/comp.lang.c++.moderated/tree/browse_frm/thread/d6695737a74e1853/18dc841928a6eee3?rnum=131&_done=%2Fgroup%2Fcomp.lang.c%2B%2B.moderated%2Fbrowse_frm%2Fthread%2Fd6695737a74e1853%2F840b0deea2987ee5%3Flnk%3Dst%26rnum%3D1%26#doc_3ff8dedacef55e17

In summary:

Andrei Alexandrescu says "Why, then, didn't D make const the default? C++ had a good reason - C compatibility."

Walter responds: "I should have. Too much water under the bridge for that now."

In the same post Walter also acknowledges that "There has been some talk in the D newsgroups of doing that, but it has the potential to be extremely disruptive."

Deewiant wrote:
> Deewiant wrote:
>> Sean Kelly wrote:
>>> I've become convinced that the "default everything to const" method seems ideal, but this seems like something that should really be done before 1.0 if it's going to happen?
>>>
>>> Sean
>> I agree. Walter posted somewhere in comp.lang.c++.moderated (I think it was there) that he thinks he should have made D like this from the start, but that it's too late now. With that, I disagree. We're not at 1.0 yet: it's not
>>  too late to break even every single line of D code out there.
> 
> I found the post in question, BTW. Here's the Google Groups link:
> 
> http://groups.google.com/group/comp.lang.c++.moderated/tree/browse_frm/thread/d6695737a74e1853/18dc841928a6eee3?rnum=131&_done=%2Fgroup%2Fcomp.lang.c%2B%2B.moderated%2Fbrowse_frm%2Fthread%2Fd6695737a74e1853%2F840b0deea2987ee5%3Flnk%3Dst%26rnum%3D1%26#doc_3ff8dedacef55e17
> 
> In summary:
> 
> Andrei Alexandrescu says "Why, then, didn't D make const the default? C++ had a
> good reason - C compatibility."
> 
> Walter responds: "I should have. Too much water under the bridge for that now."
> 
> In the same post Walter also acknowledges that "There has been some talk in the
> D newsgroups of doing that, but it has the potential to be extremely disruptive."


Absolutely. we definitely need it.  Walter, I hope you will reconsider.  Many of us are more than willing to accept any of those potential disruptions.  Success often comes only with risk. :)

You've got this far with such an incredible language, why not take it all the way?

-JJR

kris wrote:

> Sean Kelly wrote:
>> Walter Bright wrote:
>> 
>>>
>>> Another problem happens when people try to transliterate C++ code into D. That doesn't work very well - you have to rethink things a bit.
>> 
>> 
>> In my experience, transliterating C++ to D allows for a lot of code to simply be tossed out.  It's issues like this that aren't obvious from simply reading a spec.
>> 
>>> Nevertheless, I still regard D as a better C++. Not in terms of being a true superset, but in terms of being a better solution to the same types of problems that C++ is targetted at. Note that C++ isn't a true superset of C, either, although it is billed as a "better C".
>> 
>> 
>> I've yet to do the same level of work in D that I do in C++, but so far I'd have to agree.  And I'm looking forward to some more ambitious projects once the framework is sorted out sufficiently.
>> 
>> That said, I do think D's lack of any sort of const checking may be an issue for large projects (I haven't done this level of development in Java so I don't have a good non-C++ basis for comparison here).  I know the issue has been beaten to death in the past, but perhaps we could do with a constructive discussion before 1.0 appears on the horizon?  I've become convinced that the "default everything to const" method seems ideal, but this seems like something that should really be done before 1.0 if it's going to happen?
>> 
>> 
>> Sean
> 
> As someone with a substantial body of D code, I'd be happy to retrofit the whole darned thing to get const. I'd say "go for it" (as long as it supports returning an array as a const, without .dup being involved)

As someone without a substantial body of D code, I'd be happy to retrofit other's code if necessary. In all other respects (on this particular matter), I just agree with Kris :)

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi