A gentle critque..

[Lars Ivar Igesund]

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.
> 
> Why not.  C and C++ compilers seem to be particularly common.  Digital
> Mars happens to have one, so does GCC, and it's even independently
> maintained.
> 
> It doesn't matter.  All proponents of marginal languages make similar
> arguments
> about the goalfor some sort of purity.  It seems like this is the common
> reason why marginal languages are created in the first place, but it's
> also the primary reason why they fail to become mainstream languages.

I don't see a single sign of D "failing", although a fairly low number of
active developers lead to a somewhat slow development of libraries and
such. And currently there is no single person in the D community feeling
that the need for such a tool is so great that they prioritize developing
it. If you feel different, I urge you to do something about the situation,
since I am quite sure it would be heartily welcomed (no sarcasm here,
really).

> 
> Think about this.. if C++ had followed the same path, it would also have
> failed. The utility of the "It just works" paradigm in C to C++
> integration and conversion made the success of C++ possible.

And this is one of the reasons for C++ getting into the mud in the first
place.

> 
> I would generally say that any successful competitor to C++ and C would:
> 
> 1. Need to directly parse C and C++ headers.

This would have been nice, but as is said is an almost impossible task
unless you are willing to spend a huge amount of time.

> 2. Need to integrate with C++ (ABI).

I don't see how this should be possible, the different C++ compilers don't
agree about the ABI!

> 3. Need to be able to be used in a mixed project (C/C++/D) and arbitrarily
> mix and match C, C++, and D objects.

This is possible as long as mangling and ABI otherwise match, but it
requires everything to be compiled with the same toolchain, plus quite a
lot of massaging for the C++ part.

> 
> My motivation for posting this critique is not to criticize D.. which I
> happen to really like, but to vent my frustration that as it stands I will
> never actually be able to use it.

Hmm, this must be the first time a critique was not meant to criticize ...

Seriously, have you tried to use D? What kind of libraries do you need? Are
you aware of the fact that Java libraries actually might be possible
convert to D with much less effort than whatever you try to do with C++?

And what about dynamic linking/loading? This is usually considered a good
practice, and it is eminently possible (just like in C and C++) to do in D.

D have it's issues, and not being able to link in C++ (or understand C++
source) is not one of them, IMO. As I try to mention from time to time, D
is already being used in several commercial projects, which in themselves
will lead to more commercial D development. The spiral is going upwards,
the speed it happens with is irrelevant.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi