A gentle critque..

[Jarrett Billingsley]

"Ben Cooley" <Ben_member at pathlink.com> wrote in message 
news:e48h8g$pk$1 at digitaldaemon.com...
> I'll just list them and note their importance.  Anything witha

Anything with a ..?

> The size, scale, and prevalence of C and C++ libraries and code make 
> writing
> wrappers for all of these libraries impractical.  That D can not just 
> easily
> include C and C++ headers "as is" gives it a serious and I would suggest 
> fatal
> disadvantage vs. C++.
> C++ out of the box could include C header files, meaning that even today I 
> have
> access to the largest possible body of third party libraries and code. 
> Binary
> compatibility with C only is just not good enough.

While I agree that converting C headers is a pain, it's a small price to pay 
for keeping the complexity of the D spec down.  In any case, using any 
language _except_ C/C++ means that you have to translate header files.

If anything, this doesn't reflect a weakness with languages other than 
C/C++, but rather, an outdated standard imposed on all languages by C/C++. 
A much better means of disseminating code would be a language-agnostic 
interface definition file, which could easily be supported by all 
programming languages.

> Incompatibility with C++ ABI...              Importance:    SHOW-STOPPER
> --------------------------------------------
>
> Even if you could include C++ headers, you could not interface with C++ 
> classes.
> C has abi compatibility with C++, and C++ has ABI compatibility with C.  C 
> and
> C++ have more or less abi compatibility with most other systems (including 
> COM,
> CORBA).  D intends to be used for system programming, but is icompatible 
> with
> the most prevalent existing ABI.

C++ doesn't have a unified ABI.  Different compilers, and even different 
versions of the same compiler, can produce incompatible binary code.

In addition, C does not have ABI compatibility with C++.  C++ can produce 
C-compatible code, just as D can, but C cannot natively communicate with C++ 
code.

> Inability to make D code work with C/C++    Importance:    SHOW-STOPPER
> ---------------------------------------------
>
> Likewise, if you write D code, your code exists only in the very small 
> world of
> D, and will not be useful to the world outside of the D programming 
> community.
> This makes any library or system you might create only marginally useful, 
> and is
> a strong disincentive for anybody to actually write code in D for general 
> public
> consumption.

Enough with the "D is not C++" argument already.  We've got it.

> No support for meta-programming or Macros   Importance:    SHOW-STOPPER
> ---------------------------------------------
> Correct me if I am wrong on this point, but the meta-programming offered 
> by
> macro code injection is just not easily replaced by mixins, templates or 
> other
> language features.

What exactly are you missing?

> Provides no additional support for safe programming vs. C/C++  Importance: 
> HIGH
> ---------------------------------------------
>
> C# and Java trade incompatibility and the inability to easily integrate 
> with
> C/C++ for the additional productivity and security.  D trades 
> incompatibility
> for.. incompatibility.  Programming in D is just as unsafe as programming 
> in C
> and C++, without the support of Microsoft and other 3rd parties to provide 
> huge
> quantities of high level libraries and a powerful integrated environment. 
> D is
> unsafe by design, just as C and C++ were, but the difference is that this 
> is
> 2006, and not the 70's, 80's, or 90's.
>
> The choice one is left with is to either program in a safe language and 
> accept
> the overhead of the JIT, or use C/C++ with it's large existing base of 
> tools and
> code other things in C# or Java.  One wonders why this is so, since C# has
> unsafe capabilities.. and CSecured offers safe C programming capabilities. 
> How
> long should we have to wait for a safe systems level language.. till 
> microsoft
> releases their Singularity project and their Bartok compiler?

Blah blah blah.

> The first two issues make much of the remaining critique irrelevant.  Once 
> you
> have a singel showstopper, additional issues don't really make any 
> difference.

Your first two showstoppers (or rather, your first three), are basically "D 
doesn't work with C++."

> - Inability to integrate with visual studio.  No good IDE.. Importance... 
> HIGH

No good IDE is a big problem, I'll agree with you.

> - No stable standard.  Importance...  MEDIUM

Considering the standard is _not even out of alpha yet_, I'm not sure how 
you can even consider this a "weakness."

> - Difficult to control what is garbage collected and what is not.  Garbage
> collection performance.  Garbage collection violates C++'s "zero overhead" 
> rule
> where any performance overhead is at the programmers explicit discression.
> Importance...   MEDIUM

A problem in any GCed language.  And in D, the GC can be turned off and 
custom memory allocators can be used for higher-performance code.

> - Not open source.    Importance... HIGH

Now you're just pulling stuff out of..... the air.  The front-end is 
completely open-source; the back end is not, as it's also used in a 
commercial product.  There is also GDC, a fully open-source implementation 
of D.

> - Very small library base.   Importance... HIGH

I'll definitely agree with you there, though the concerns about the library 
aren't exactly a new topic here.

>Likewise, the idea that C
> headers could simply be directly included in a C++ language file, and "it 
> just
> worked" allows any C code to be used in a C++ program.. a feature that all 
> C++
> programmers use today.

It's because C++ was designed, from the start, to be an extension of C.  D's 
mantra is entirely different - it says "how can C/C++ be redesigned knowing 
what we know today?"  Not "how much more crap can we add to an 
overly-bloated language and still manage not to break decades worth of 
legacy code?"

> Finally, C and C++ code code be easily mixed within a single project, 
> another
> feature of C++ that is used today.  Since C++ can consume any C header, 
> and in
> most cases C can understand the ABI of C++ with the extern "C" {} wrapper, 
> it's
> possible to go in both directions.

blah blah blah

> All this being said, I would really like to see a language like D succeed,
> because I need the features it has.  But I can't abandon my C and C++ 
> libraries,
> and I am not about to commit to coding wrappers for them, nor forgoing 
> using my
> current programming environment and debugging tools.  When I adopted C++ 
> 20
> years ago, I didn't need to do this.  C++ integrated well with my tools 
> and
> existing libs (the exception being the debugger of course).  But overall 
> it was
> a good citizen in the overall world of C/C++ code.. it played nicely.  The 
> same
> can not be said of D, C#, or Java, and D doesn't have the other benefits 
> of C#
> or Java.

So don't use D then.  Just stay with C++.

> Until D addresses these issues, it will be nothing more than a niche 
> language
> offering syntactic cleanliness and interesting features to a few faithful, 
> but
> largely ignored by the rest of the programming world.

And entirely in yor opinion.  Which seems to be _incredibly_ biased towards 
C++.