DMD 0.149 release - What is missing from D?

[Charles Hixson]

MicroWizard wrote:

>>My general experience with people who say "D is a great language, but I
>>won't use it because of <minor nitpick> because <minor nitpick> is the
>>most important thing in the world" is that they won't use it anyway, and
>>are just looking for an excuse.
> 
> Absolutely agree.
> I have told to many "friends" to check D site and tell me their opinions.
> Most of them had excuses: no IDE, no GUI, no ... bla-bla-bla
> And they use Visual Studio with Intellisense and such crap.
> 
> (I use DMD as regular compiler for small inhouse projects for two years.
> And I really like it.)
> 
> D is not for every "code writer", it is for developers.
> 
> Tamas Nagy
The "no GUI" really *IS* a valid reason, not just an excuse.  It depends on
what your project is.  I currently have two projects in mind.  For one of
them I may choose D, for the other...no stable GUI is a project killer.

N.B.:  This is not unique to D.  Every new language comes to this problem,
which may be condensed into a simple word:  LIBRARIES!!!  This is why a
GOOD connection to C is so important to D.  (And it's why an automated
build tool that can add C code and D code together is important.)  In the
early days I remember a comment where Walter was looking at adding an
automatic conversion of C header files into D files ... and decided that it
was too difficult a job to do in a general way.  (He also pointed at his C
or C++ [I forget which] compiler, and showed how to use it as a
preprocessor...which didn't help me as I'm using Linux, but demonstrated
that he DID understand the problem.)

Actually, a version of this is why I've chosen Python over Ruby for some
projects.  I think that Ruby is a much better language, but Python started
earlier, so Python has the libraries.

This is a serious problem, and I don't know any way to solve it.  It can
"sort of" be handled by just continuing on, and developing libraries in
passing.  Over time the most critical libraries will be added.  But note
that Ruby is STILL severely behind Python.  This is not a problem that can
be handled quickly in this way.   A solution would dissolve the problem by
allowing transparent access to, e.g., C libraries.  (Even this wouldn't be
a total solution, because then there will be the problem of
documentation...where the documentation for the libraries will all be
directed at users of the original language.)  This is probably a problem
that we must be satisfied with handling rather than solving.  Over time it
will decrease in importance.  Currently, while the GUI and database
libraries are missing/primitive/fragile ... well, a lot of the time D won't
be the correct language, even though as a language it would be the correct
choice.

-- 
Work in progress