DMD 0.149 release - What is missing from D?

[Don Clugston]

Charles Hixson wrote:
> 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.

I completely agree with this. I think the language is good enough now 
that future progress will be limited by the quality of the libraries.
The most severe symptom is that right now, D doesn't even have proper 
windows headers!
IMHO, it's not currently suitable for anything that involves I/O other 
than reading and writing files.

The 'implib' tool has done a lot to improve the situation with respect 
to C libraries -- now at least we can link to them. We just need a 
header file converter.

I've been trying to understand the 'problem space' for C -> D header 
conversion. It seems to me, that it is a solvable problem, once you 
accept that because of ambiguities in the C preprocessor, a fully 
automatic conversion is impossible. My proposed solution is to have a 
prepreprocessor, which modifies a C header into a format without 
ambiguities, which can then be converted automatically.
I think that if we had such a tool, D would be vastly more usable.
I think this issue is about to become 'mission critical' for D.