DMD 0.149 release - What is missing from D?

[MicroWizard]

Sorry, but I feel you missed the point.

No language was born _with_ libraries. Not M$ ones.
Who want to use D imediately he/she is a coder, not a developer,
who tries to use the possibilities.

In my professional life I have to work with M$ things. That place I am a coder
only. I satisfy customer's needs. I use RAD. I earn money. I often hate it.

In this community I can see the possibility to participate in some good new
things to create. It needs time to grow. No reason to hurry.

Tamas Nagy

In article <dv243r$1qa$1 at digitaldaemon.com>, Charles Hixson says...
>
>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