A gentle critque..

[Hasan Aljudy]

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.