How does D improve design practices over C++?

[Tony]

"Jesse Phillips" <jessekphillips at gmail.com> wrote in message 
news:gf2j4a$187s$1 at digitalmars.com...
> On Fri, 07 Nov 2008 16:09:58 -0600, Tony wrote:
>
>> "Janderson" <ask at me.com> wrote in message
>> news:gf0hf3$9nf$3 at digitalmars.com...
>>> Tony wrote:
>>>>> "Janderson" <ask at me.com> wrote in message
>>>>>> Also #defines really arn't a problem for cpu at compile time, your
>>>>>> right there.  I'm trying to point out that using #defines for const
>>>>>> is totally rediculus (sorry for being so harsh).  No C++ book or
>>>>>> expert would recommend it and it doesn't result in any run-time
>>>>>> optimisation what so ever.
>>>>>
>>>>> Obviously I take language feature "recommendation" with a grain of
>>>>> salt. I do #define because I've never had any problem with it (and
>>>>> look at the Windows header files sometime!) and #defines don't create
>>>>> a data object in memory. It's simply never been a problem. Now if one
>>>>> is "hell bent/anal" about "doing away with the preprocessor, power to
>>>>> them, "it ain't me" though. I don't want the template machinery
>>>>> taking over the capability of the preprocessor: I use it to mutate
>>>>> the language and experiment. I will probably implement a preprocessor
>>>>> to replace or add to what I have with C++ before I jump into compiler
>>>>> development for my language that is evolving.
>>>
>>>
>>>
>>> It seems you might need to think outside of the C++ box.
>>
>> That's an odd statement considering that I came here to investigate D
>> and am defining what to put into my own language (or one I wish someone
>> would implement) because of the issues I have with major "features" of
>> C++ (and D).
>
> It sounds to me that D is not the "improvement" over C++ you are looking
> for.

That's not to say that there is nothing interesting about D though, that's 
why I came in to investigate a bit.

> It sounds like you have done a lot of work in C++ and developed good
> coding practices for yourself and probably those you work with. I would
> guess that it has taken some time to develop the design habits you use.

Yep, to the point where the "everything including the kitchen sink" 
languages are getting kind of long in the tooth.

>
> It seems to me that the improvements D gives you have already worked out
> through convention in C++.

Probably some of them and there's always room for improvement.

> D presents a much clearer path on what
> conventions should be used in programming.

What I like about C++ is that it is more mechanism than policy.

> D provides other benefits,
> such as GC, that it appears you are not looking for.

Right.

>
> I say D is not for you because, from what I have read, you are looking to
> have features removed.

Not at all. I'm just creating a vision of what I'd like my ideal language to 
be. Given those things, I can assess if it's worth developing a new language 
or not. It's just research for the future when I may have more resources.

> I see complaint after complaint about D/C++ having
> something you don't want to use, but very little/none on what you
> actually want added to the language.

No complaints from me here: I'm not evaluating the language for usage 
anymore, but rather for elements that I'd put on my list of top language 
features and how they fit in or not with completely new features not in any 
language. Also, going "back and forth" with people on some of features 
solidifies in my mind what kind of capability and what kind of 
implementation I would do. So I don't want anything added to D since I'm not 
a D user. I'd like some things added to C++ though and some removed, but 
since that is like pulling teeth and the whole shebang is way more complex 
than necessary, a new language or a preprocessor to make it more palatable 
may be in order. What drew me to peek at D years ago was the comment that it 
was much easier to implement and the template implementation example. I 
looked at again lately because I had forgotten some things about it such as 
what the object model was like.

> Take GC for example, rather than
> saying, "I don't want it" you can go with, "I want total control of
> memory management"

I thought that was pretty much clear (both/either).

>  If you still don't want to learn how to manipulate the
> D GC, then D is not for you.

I pretty much knew that after my reread of the website. Reading responses in 
defense of the features though does prompt some deeper thoughts about them.

>
> I might suggest not commenting on something you find unimportant, if
> "stronger const" is insignificant, then ignore it and move on.

stronger const is good. It's just not one of those "deal maker/breaker" 
things like the object model for example (something I am still going to look 
more closely at in D).

Tony