How does D improve design practices over C++?

[Jesse Phillips]

On Sat, 08 Nov 2008 03:48:01 -0600, Tony wrote:

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

It seems I have misunderstood your purpose here. Carry on. :)