There are a few major problems with D that still prevent it from being practical for use in the real world.

I'll just list them and note their importance.  Anything witha

- Inability to access C/C++ include files...  Importance:   SHOW-STOPPER
--------------------------------------------

C++ can do this, D can not.

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.

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.

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.

No support for meta-programming or Macros   Importance:    SHOW-STOPPER
---------------------------------------------

Say what you will about the unclean use of macros in C and C++, they are critical for a large set of important functionality that C and C++ programmers take for granted.  There are many ways to provide hygenic macro replacesments, true meta programming, or generative programming.  D offers none of these, and no way to replace the functionality lost using macros.

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.

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?

------------

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. However I'll list them anyway.

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

- No stable standard.  Importance...  MEDIUM

- 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

- Not open source.    Importance... HIGH

- Very small library base.   Importance... HIGH

----------------------------------------------------------

A modest suggestion, were I to try to introduce a new language which I intended to be not only clean and simple, but "popular" and widely used as well would be to squarely address the first three issues above.

C++ provided a translator.  The original versions of C++ were able to output C code which would compile on any ordinary C compiler.  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.

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.

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.

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.

Ben Cooley wrote:

> - Inability to access C/C include files...  Importance:   SHOW-STOPPER
> --------------------------------------------
> 
> C can do this, D can not.
> 
> 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.

True.  This has been discussed before, but has been rejected intentionally.  We don't want every D compiler to end up being a C compiler, too.

> 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 classes, so I assume you mean C++.  While D does follow the C ABI, it doesn't follow the C++ one.  I'm also surprised that you mentioned COM, since D can use that, too.

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

Making a library using extern (C) should do that.

> No support for meta-programming or Macros   Importance:    SHOW-STOPPER
> ---------------------------------------------
> 
> Say what you will about the unclean use of macros in C and C, they are critical for a large set of important functionality that C and C programmers take for granted.  There are many ways to provide hygenic macro replacesments, true meta programming, or generative programming.  D offers none of these, and no way to replace the functionality lost using macros.
> 
> 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.

While there are a few things that can't be done, most can.  If you give us a specific problem, I'm sure something can be done about it.

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

D will let you do whatever unsafe actions you want, but that doesn't mean you need to use them.  For example, things like pointers and gotos still exist, but are not normally used.

The idea is to give the functionality to those who can use it, but try to keep everyone else (like me) from shooting themselves in the foot.

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

There was a project to integrate D with Visual Studio.  I'm not sure what the current status is, but you can probably find it if you look.

As for the "no good IDE," that's being worked on right now.  Try looking at http://www.dsource.org.

> - No stable standard.  Importance...  MEDIUM

There will be a stable standard as soon as we hit 1.0.

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

You can allocate memory the C way with malloc if you want to.   Anything allocated that way won't be garbage collected.

> - Not open source.    Importance... HIGH

The front end and the standard library are open source.  There is also a project that links it directly into GCC.  What more do you want?

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

You do have a point here, but that it being worked.  Once again, look at http://www.dsource.org

> A modest suggestion, were I to try to introduce a new language which I intended to be not only clean and simple, but "popular" and widely used as well would be to squarely address the first three issues above.
> 
> C provided a translator.  The original versions of C were able to output C code which would compile on any ordinary C compiler.  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.
> 
> 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.

Yes, and D can understand D code, too!  You don't even need an extern (D).

> 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.
> 
> 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.
> 
D may be a niche language right now, but it is far more popular than it used to be.  Take a look at the TIOBE ranking, for example.

- D is not C++ ... Importance: SIGH
- D cannot toast bread ... IMPORTANCE: SHOW-TOASTER
- D cannot prevent idiocy in programmers ... IMPORTANCE: FATAL

Charlie


Ben Cooley wrote:
> There are a few major problems with D that still prevent it from being practical
> for use in the real world.
> 
> I'll just list them and note their importance.  Anything witha
> 
> - Inability to access C/C++ include files...  Importance:   SHOW-STOPPER
> --------------------------------------------
> 
> C++ can do this, D can not.
> 
> 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.
> 
> 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. 
> 
> 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.
> 
> No support for meta-programming or Macros   Importance:    SHOW-STOPPER
> ---------------------------------------------
> 
> Say what you will about the unclean use of macros in C and C++, they are
> critical for a large set of important functionality that C and C++ programmers
> take for granted.  There are many ways to provide hygenic macro replacesments,
> true meta programming, or generative programming.  D offers none of these, and
> no way to replace the functionality lost using macros.
> 
> 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.
> 
> 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?
> 
> ------------
> 
> 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.
> However I'll list them anyway.
> 
> - Inability to integrate with visual studio.  No good IDE.. Importance...   HIGH
> 
> - No stable standard.  Importance...  MEDIUM
> 
> - 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
> 
> - Not open source.    Importance... HIGH
> 
> - Very small library base.   Importance... HIGH
> 
> ----------------------------------------------------------
> 
> A modest suggestion, were I to try to introduce a new language which I intended
> to be not only clean and simple, but "popular" and widely used as well would be
> to squarely address the first three issues above.
> 
> C++ provided a translator.  The original versions of C++ were able to output C
> code which would compile on any ordinary C compiler.  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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 

"Ben Cooley" <Ben_member@pathlink.com> wrote in message news:e48h8g$pk$1@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++.

On Mon, 15 May 2006 00:16:16 +0000 (UTC), Ben Cooley wrote:

> - Inability to access C/C++ include files...  Importance:   SHOW-STOPPER
> --------------------------------------------
> 
> C++ can do this, D can not.

What! You mean that C++ (a superset of C) can actually access both C and C++ include files? Who would have guessed that!?

I just did a quick google search and it appears that C#, VB.Net, COBOL, Fortran and Java can't use C/C++ includes either. I think the sky is falling.

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

But all joking aside, it just occurred to me that Digitalmars already has a tool that accesses C/C++ headers ... the DigitalMars C++ compiler! So I'm wondering if Walter could provide a new utility that can help us automate translation of C/C++ headers into D source code?


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

Prior C existing, programmers used other entrenched languages (of course) and yet C still managed to take root? So even though C could not access the source code of those entrenched languages, it become popular.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
15/05/2006 12:39:04 PM

James Pelcis wrote:
> 
> True.  This has been discussed before, but has been rejected intentionally.  We don't want every D compiler to end up being a C compiler, too.
> 

This has always been a sore spot with me and D.  There is A LOT of C/C++ code out there to leverage off of, and to me it is beyond inconvenient to require translation of all of those headers.  Also, rewriting all of the code with a handful of D developer seems like insanity to me.

That said, the two known D compilers are also C++ compilers (or at least share backends with C++ compilers).  What a handy coincidence.  I'd say that being able to link against C++ code shouldn't be part of the D spec, at least not permanently, but being able to link against C++ code should be supported by current D compilers just to get things moving for D.  Then maybe someday compiler writers will save some effort by ditching C++ support because no one will use C++ anymore.

I'm probably rehashing old arguments, but this matters to me.  Also, it would be nice to have some links to those old arguments.  Normally I'd find them myself, but this topic has proven itself a difficult search (at least with Thunderbird).

Oh and whatever happened to all of those C header to D translation projects?  Did people run into some sort of fundamental law of the universe that made it impossible, or was it just difficult enough to discourage everyone for a couple years?

Carlos wrote:
> - D is not C++ ... Importance: SIGH
> - D cannot toast bread ... IMPORTANCE: SHOW-TOASTER
> - D cannot prevent idiocy in programmers ... IMPORTANCE: FATAL
> 
> Charlie
> 
> 
> Ben Cooley wrote:
>> There are a few major problems with D that still prevent it from being practical
>> for use in the real world.
>>
>> I'll just list them and note their importance.  Anything witha
>>
>> - Inability to access C/C++ include files...  Importance:   SHOW-STOPPER
>> --------------------------------------------
>>
>> C++ can do this, D can not.
>>
>> 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.
>>
>> 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.
>> 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.
>>
>> No support for meta-programming or Macros   Importance:    SHOW-STOPPER
>> ---------------------------------------------
>>
>> Say what you will about the unclean use of macros in C and C++, they are
>> critical for a large set of important functionality that C and C++ programmers
>> take for granted.  There are many ways to provide hygenic macro replacesments,
>> true meta programming, or generative programming.  D offers none of these, and
>> no way to replace the functionality lost using macros.
>>
>> 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.
>>
>> 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?
>>
>> ------------
>>
>> 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.
>> However I'll list them anyway.
>>
>> - Inability to integrate with visual studio.  No good IDE.. Importance...   HIGH
>>
>> - No stable standard.  Importance...  MEDIUM
>>
>> - 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
>>
>> - Not open source.    Importance... HIGH
>>
>> - Very small library base.   Importance... HIGH
>>
>> ----------------------------------------------------------
>>
>> A modest suggestion, were I to try to introduce a new language which I intended
>> to be not only clean and simple, but "popular" and widely used as well would be
>> to squarely address the first three issues above.
>>
>> C++ provided a translator.  The original versions of C++ were able to output C
>> code which would compile on any ordinary C compiler.  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.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>

Dont be an ass. Ben, please don't be offended, most of us are nice people. ;-) ( I still love you Charlie )

-- 
Kyle Furlong // Physics Undergrad, UCSB

"D is going wherever the D community wants it to go." - Walter Bright

Technical alert: it seems that the (plus plus) disappears from your
post. hence C++ (see plus plus) appears as C (see).

It's specially funny with the comment:

>>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.
>
>
> Yes, and D can understand D code, too!  You don't even need an extern (D).
>
>

He's talking about C and C++ (see and see plus plus) not C and C (see
and see)!!!!

James Pelcis wrote:
> 
> Ben Cooley wrote:
> 
> 
>>- Inability to access C/C include files...  Importance:   SHOW-STOPPER
>>--------------------------------------------
>>
>>C can do this, D can not.
>>
>>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.
> 
> 
> True.  This has been discussed before, but has been rejected intentionally.  We don't want every D compiler to end up being a C compiler, too.
> 
> 
>>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 classes, so I assume you mean C.  While D does follow the C ABI, it doesn't follow the C one.  I'm also surprised that you mentioned COM, since D can use that, too.
> 
> 
>>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.
> 
> 
> Making a library using extern (C) should do that.
> 
> 
>>No support for meta-programming or Macros   Importance:    SHOW-STOPPER
>>---------------------------------------------
>>
>>Say what you will about the unclean use of macros in C and C, they are critical for a large set of important functionality that C and C programmers take for granted.  There are many ways to provide hygenic macro replacesments, true meta programming, or generative programming.  D offers none of these, and no way to replace the functionality lost using macros.
>>
>>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.
> 
> 
> While there are a few things that can't be done, most can.  If you give us a specific problem, I'm sure something can be done about it.
> 
> 
>>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?
> 
> 
> D will let you do whatever unsafe actions you want, but that doesn't mean you need to use them.  For example, things like pointers and gotos still exist, but are not normally used.
> 
> The idea is to give the functionality to those who can use it, but try to keep everyone else (like me) from shooting themselves in the foot.
> 
> 
>>- Inability to integrate with visual studio.  No good IDE.. Importance...   HIGH
> 
> 
> There was a project to integrate D with Visual Studio.  I'm not sure what the current status is, but you can probably find it if you look.
> 
> As for the "no good IDE," that's being worked on right now.  Try looking at http://www.dsource.org.
> 
> 
>>- No stable standard.  Importance...  MEDIUM
> 
> 
> There will be a stable standard as soon as we hit 1.0.
> 
> 
>>- 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
> 
> 
> You can allocate memory the C way with malloc if you want to.   Anything allocated that way won't be garbage collected.
> 
> 
>>- Not open source.    Importance... HIGH
> 
> 
> The front end and the standard library are open source.  There is also a project that links it directly into GCC.  What more do you want?
> 
> 
>>- Very small library base.   Importance... HIGH
> 
> 
> You do have a point here, but that it being worked.  Once again, look at http://www.dsource.org
> 
> 
>>A modest suggestion, were I to try to introduce a new language which I intended to be not only clean and simple, but "popular" and widely used as well would be to squarely address the first three issues above.
>>
>>C provided a translator.  The original versions of C were able to output C code which would compile on any ordinary C compiler.  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.
>>
>>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.
> 
> 
> Yes, and D can understand D code, too!  You don't even need an extern (D).
> 
> 
>>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.
>>
>>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.
>>
> 
> D may be a niche language right now, but it is far more popular than it used to be.  Take a look at the TIOBE ranking, for example.

I only agree with 2 points: the lack of a rich library, and the lack (so far) of an IDE, but the lattar is not part of the language per se.

Guess what, I came to D because I hated C++.
C++ has the worst set of libraries ever. If you compare what C++ has vs. what Java has, the Java libraries would win anyday!
Even if the same library was written for both Java and C++, the Java version would always win. (look at the ICU library for example).

Java and C# succeeded without dealing with any of the C++ crap; C++ wasn't a show stopper for them.
Infact, I bet C++'s stupidity was a recruitment tool for Java and C#. It can also be a recruitment tool for D.

The solution is to create a library similar to the Java api or the .NET framework.
This solution has not yet been realized, but there is some promice in dsource.org, specially the Mango project.


As for the IDE, well, there's "Posiedon". It's not perfect, but I think it's just fine. I always use it, and it's a big time saver.


Ben Cooley wrote:
> There are a few major problems with D that still prevent it from being practical
> for use in the real world.
> 
> I'll just list them and note their importance.  Anything witha
> 
> - Inability to access C/C++ include files...  Importance:   SHOW-STOPPER
> --------------------------------------------
> 
> C++ can do this, D can not.
> 
> 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.
> 
> 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. 
> 
> 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.
> 
> No support for meta-programming or Macros   Importance:    SHOW-STOPPER
> ---------------------------------------------
> 
> Say what you will about the unclean use of macros in C and C++, they are
> critical for a large set of important functionality that C and C++ programmers
> take for granted.  There are many ways to provide hygenic macro replacesments,
> true meta programming, or generative programming.  D offers none of these, and
> no way to replace the functionality lost using macros.
> 
> 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.
> 
> 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?
> 
> ------------
> 
> 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.
> However I'll list them anyway.
> 
> - Inability to integrate with visual studio.  No good IDE.. Importance...   HIGH
> 
> - No stable standard.  Importance...  MEDIUM
> 
> - 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
> 
> - Not open source.    Importance... HIGH
> 
> - Very small library base.   Importance... HIGH
> 
> ----------------------------------------------------------
> 
> A modest suggestion, were I to try to introduce a new language which I intended
> to be not only clean and simple, but "popular" and widely used as well would be
> to squarely address the first three issues above.
> 
> C++ provided a translator.  The original versions of C++ were able to output C
> code which would compile on any ordinary C compiler.  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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 

First of all Ben:

Welcome to the D community!

I would like to apologize for the less than optimal welcome you have received so far; they should know better. That being said, I do agree with them on a few points, specifically the comments regarding C++/C compatibility. The rest of my comments are embedded.

Ben Cooley wrote:
> There are a few major problems with D that still prevent it from being practical
> for use in the real world.
> 
> I'll just list them and note their importance.  Anything witha
> 
> - Inability to access C/C++ include files...  Importance:   SHOW-STOPPER
> --------------------------------------------
> 
> C++ can do this, D can not.
> 
> 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.
> 

http://www.digitalmars.com/d/htomodule.html is a helpful guide. However, its not an automated tool. Also, http://www.digitalmars.com/d/pretod.html is a good read.  An automated tool would be a very complex piece of software, and there have been multiple attempts by various members of the community. The fact remains that hand translation is faster than writing an automated translator.

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

The idea here is that C++ library code can be wrapped in a C interface. In that way, D and C++ can communicate. One does not need to recode the entire C++ library code base, and C libraries are a short days work of translating headers away. Have you tried to do this? It really doesnt take as long as I believe you are imagining. For example, I got a workable Cairo module translated in about two hours.

As regards COM: http://www.digitalmars.com/d/dll.html#com

In fact, D treats COM objects specially within the runtime/compiler. Its kinda magical, and maybe others who know better can inform you more completely.

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

See previous comment. D -> C -> C++ -> C -> D

> No support for meta-programming or Macros   Importance:    SHOW-STOPPER
> ---------------------------------------------
> 
> Say what you will about the unclean use of macros in C and C++, they are
> critical for a large set of important functionality that C and C++ programmers
> take for granted.  There are many ways to provide hygenic macro replacesments,
> true meta programming, or generative programming.  D offers none of these, and
> no way to replace the functionality lost using macros.
> 
> 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.
> 

Examples of things you have had trouble porting? We can help.

> 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

I'm sorry, did I miss an explanation? What incompatibility are you speaking of?

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

D is a practical language. Because of this, the user is offered easy access to low level features like pointers and inline assembly. However, if you look at most D library code, which by the way mostly resides at www.dsource.org, you will find that these features are rarely used. The idea is that the compiler will not decide for you how you want to program. If you want to code in a procedural manner, you are welcome to do so. If you would like to write in a very high level manner with Objects, Interfaces, Mixins, and Templating, you are also welcome to do so. With any style you choose you may also choose to subvert the type system, GC, and other language features by using pointers and/or assembly.

Whatever style you prefer, and even if you use the low level features, D offers two things which C/C++ doesn't. Unittesting and design by contract. These two tools, which are build into the spec and both compilers, enable one to safely write any code you like.* For more information on these two features:

http://www.digitalmars.com/d/dbc.html
http://www.digitalmars.com/d/cppdbc.html

http://www.digitalmars.com/d/class.html#unittest

I cant find the page for unit tests in general, but the syntax is valid at the module level as well. For example:

module bar;

int one()
{
   return 1;
}
unittest
{
    assert(one() == 1);
}

float square(float x)
{
	return x*x;
}
unittest
{
    assert(square(2) == 4);
}

These are run in the order they appear lexically.

Unit tests are turned on by sending the compiler the -unittest switch.

* Obviously if you choose to write code with pointers and assembly that is intentionally unsafe, you are doing so at your own risk. My point is that that is your choice. Its like we used to say in volleyball, the ball only goes where you tell it to, so its your fault if it goes somewhere you don't want.

> ------------
> 
> 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.
> However I'll list them anyway.
> 
> - Inability to integrate with visual studio.  No good IDE.. Importance...   HIGH
> 
> - No stable standard.  Importance...  MEDIUM
> 
> - 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
> 
> - Not open source.    Importance... HIGH
> 
> - Very small library base.   Importance... HIGH
> 

All except GC have been covered by others adequately.

You are simply mistaken as regards the GC. If you take a look here,

http://www.digitalmars.com/d/phobos/std_gc.html

you will find the API for controlling the builtin GC. As you can see there, it is possible to turn the GC on and off at arbitrary points in your code. I will leave you to explore the other aspects of the API.

> ----------------------------------------------------------
> 
> A modest suggestion, were I to try to introduce a new language which I intended
> to be not only clean and simple, but "popular" and widely used as well would be
> to squarely address the first three issues above.
> 
> C++ provided a translator.  The original versions of C++ were able to output C
> code which would compile on any ordinary C compiler.  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.
> 
> 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.
> 
> 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.
> 
> 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.
> 

Valid points for your situation. If you don't have the time or inclination to put in the effort to translate headers for library code, that is your prerogative. It is true for you that to gain the features you would like would take that effort. However, I think you are making the wrong conclusion because of some missing details.

D is not about any one or two features. It needs to be taken as a whole entity. I think that you will find if you code in D for any length of time that the language just feels "nice." It is well thought out, consistent, and efficient. You WILL save time debugging because of the unittesting and DbC features. You WILL save time not having to integrate those two features into the language from a third party library as you would with C/C++. You WILL save time because the compilation process of D is orders of magnitude faster than C/C++, especially for large projects. The combined weight of these and other efficiencies within the D domain will eclipse the time and effort put in to translate some headers for legacy code.

However, I obviously don't know how extensive your library base is. And maybe for you having a mature toolset is absolutely essential to being productive. In my experience though, by using a good programmers editor with macros and tools, coupled with the Build tool on www.dsource.org, as well as the builtin bug crushing features of D, I don't miss a RAD IDE.

Thanks for being candid, and I welcome you to join us in discussing the direction of D. I hope that I have helped you understand where we stand better. I also hope that you will stick around and contribute because I believe that D is the best bet for the majority of programming in the 21st century.

-- 
Kyle Furlong // Physics Undergrad, UCSB

"D is going wherever the D community wants it to go." - Walter Bright