A gentle critque..

[Kyle Furlong]

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