"Xavier" <x...@nospam.net> wrote in message 
news:j51p5q$2utg$1...@digitalmars.com...
>
> "Nick Sabalausky" <a@a.a> wrote in message 
> news:j51m0l$2prg$1...@digitalmars.com...
>>
>> In both this and your other post, you're conflating the notions of the 
>> "language quality" vs "implementation quality". The two are not the same.
>
> They are not necessarily orthogonal though either. Surely you are just 
> focusing on design and maybe semantics and maybe even syntax, but those 
> aren't the only criteria and of those things, C++ and D have more in 
> common than they have not in common. For instance, if implementation 
> quality is bad, maybe the language's implementability is bad. If so, then 
> it's a language "quality" issue. Now you can argue that C++ is much worse 
> in regards to implementability, but that doesn't really say anything more 
> than something like "D is better than the POS that C++ is". To be markedly 
> different from C++, D would have to be thought of as being in a different 
> category than "which is the better POS?", but of course it cannot, for it 
> comes from the same family, "one generation newer than C++".
>
>> Now, yes, D effectively has one implementation (the DMD frontend), but 
>> even considering that, the notions are still worth separating:
>>
>> For one thing, implementation quality is much easier to improve than 
>> language quality.
>
> That may be true if one had a language that indeed was at some superior 
> design level, but D is not at that level. It's at the same level as C++ 
> is, so there is major room for improvement (i.e., requires a different 
> language) in a number of areas.
>

What you're ultimately saying is that if a guitar has a crappy first and 
second string (and therefore sounds lousy), then you also have to replace 
the other four strings, the pickups, the head, the body, the amp, the neck 
and the carrying case to make it sound good again. Replacing the two crappy 
strings won't be enough to make it sound significantly better.

What you're missing is that a minority portion *can* ruin a whole. If you 
consider D and C++ to be mostly the same, then C++ is crappy because of, 
what you're perceiving to be, a minority subset of it's design. D cuts out 
the cancer and saves the whole.

Your notion that a big imporvement requires a big change is just plain 
false.


>> An implementation deficiency can always be fixed. But a language 
>> deficiency can usually only be fixed if it's an additive change, which: 
>> #1 Rules out all non-additive improvements, and #2 Often forces an 
>> inferior solution to be used, creating language cruft.
>>
>> Secondly, it *IS* possible, and not at all uncommon, for a language 
>> deficiency to be MORE severe than an implementation deficiency. For 
>> example, updating header files and keeping them in-sync with the 
>> implementation is far more time consuming than working around any of the 
>> bugs in D's module system. Another: Certain details about C++ *force* the 
>> language to be slow-to-compile. That CANNOT be improved. As a 
>> consequence, many C++ projects take hours to compile. Unless you shell 
>> out the $$$ for a distributed-compilation cluster. Either way, that's 
>> much more costly than dealing with any D bug I've come across in the last 
>> year (yes, there were some severe ones in the past, but those are now 
>> fixed).
>
> So large scale software development is the only concern? Seems rather 
> contrived point. C'mon now, a lot of software is NOT that.

You know perfectly well those were just examples.

> And notice too that for software development that is not that, 
> "intellisense" dramatically reduces the number of times a programmer hits 
> the compile button. That one thing is not as big an issue and certainly it 
> pales in comparison to other language design flaws, which C++ and D both 
> share.
>

1. IDE features are not substitutes for language improvement.

2. Such features don't end up in a IDE "for free". There's cost associated 
with actually putting them in there for a given language. You're not 
factoring that in. Additionally, this also implies that not everyone always 
has such features available.


>>
>> So no, it's NOT a contradiction that D can be a better language while 
>> still having implementation issues.
>
> Anyway, you can talk until you are blue in the face, but you can't 
> convince me that D and C++ aren't in the same category (as far as language 
> design goes). You can call C++ a POS, but then, to me, that means that at 
> best, D is just a better POS. But not to end this post on a bad note/word, 
> I admire C++ a little bit. I certainly don't hate it. I can deal with it's 
> shortcomings for now, so I could probably deal with D's also, but if I was 
> thinking about jumping ship, I'd be swimming toward an island and not 
> another ship.

Yes, because if one boat starts sinking, they're all about to start 
sinking...

And if you felt sick due to kidney failure, you'd insist that replacing the 
kidney will just make you slightly less sick. So you'd insist the doctor 
also replace your heart, your hip and your leg, fuse your spine, perform 
brain surgery, die your hair, and give you glasses, dentures and a 
facelift...


Reply via email to