A gentle critque..

James Pelcis jpelcis at gmail.com
Sun May 14 18:13:42 PDT 2006



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.



More information about the Digitalmars-d mailing list