A gentle critque..

[Hasan Aljudy]

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