Preface:

Back when i didn't know about D's existence, C++ was my favorite language.
The reason for that was, that C++ allowed all the following simultaneously:
    * Allowed me to wrote very optimized and high-performance code (I'm a
run-time performance paranoiac).
    * Allowed me to avoid constant low-level shenanigans (what with
object-oriented and/or generic programming wrappers and all).
    * Allowed me to project my problem space into solution space relatively
easily.
And the complexity and downsides of C++ were essentially ignored because
"Well, i can cope with that, so what's the problem?".
The high-productivity alternatives to C++, like Java could never quench my
paranoid thirst for run-time performance, so i was basically stuck with C++.
Sometimes i realized, that having high-productivity and high run-time
performance simultaneously was impossible, which killed my passion for
programming.
Then D comes along...
I take a close look at it and I fell in love with it!
Not only does it perfectly satisfy my run-time performance paranoia, but it
looks so beautiful and it's so simple!
D re-ignited fires of passion to programming in me!
It objectively has no practical weakness against C++.

Main point:

I've conducted an experiment by promoting D to my colleagues. Every single
conversation ended up like "Well, i don't deny it's superiority, but we're
not gonna rewrite our code base anyway".
I further investigated  the "Why would you wanna spend lots of time and
money on maintaining old crotchety code, rather then re-investing the same
money in PARTIALLY rewriting the code base and forget about troubles
forever?".
It turns out, that people, who maintain mature commercial projects are
simply afraid to switch from their language.
Note, that they're not afraid to switch to D, their afraid to switch from
C++.
This is because they have 100% confidence in C++ in terms of it's support,
tools, libraries and general usability.
They KNOW, that they'll always have stable compiler, IDE, libraries and lots
of C++ experts to help them with language-related issues.

Currently, D has none of those things. D is, as i said earlier, an amazingly beautiful and powerful language, which nobody denies, but it has no stable compiler (DMD is full of bugs, GDC and LDC inherit DMD's bugs and all that stops me from using D to it's full extent), it has no satisfying IDEs (VisualD and DDT are the only ones and are also full of bugs) and library (All D has is a tiny little phobos and a couple of broken bindings for D1).

And above all, people gain confidence int a language if it's being actively breast-fed by a big fat company. Example: C++ is being taken care of by Microsoft in the form of active development of their compiler, public documentation about it and a whole lot of action going on around C++. And average Joe thinks "Toy can't miss with Microsoft!" and goes ahead and uses C++.

D is maintained by a group of volunteers (I've joined that group recently), with no commercial interest in it. Of course, that's good, but not too reassuring.

I call upon all fellow D developers to help me put together a reasonable
infrastructure for D and end this annoying popularity paradox once and for
all.
As well as try to spread awareness of D as much as possible using ads,
reviews, benchmarks and anything else that people tend to read once in a
while.

I'm ready to donate money to sponsor an ad campaign.

On 9/21/11 4:18 AM, Gor Gyolchanyan wrote:
[snip]
> D is maintained by a group of volunteers (I've joined that group
> recently), with no commercial interest in it. Of course, that's good,
> but not too reassuring.
>
> I call upon all fellow D developers to help me put together a reasonable
> infrastructure for D and end this annoying popularity paradox once and
> for all.
> As well as try to spread awareness of D as much as possible using ads,
> reviews, benchmarks and anything else that people tend to read once in a
> while.
>
> I'm ready to donate money to sponsor an ad campaign.

Nice, enthusiastic initiative. I think you started in the right vein by contributing to our github code base. Looking forward to more to come.

One simple thing that could improve D's PR would be mirroring the Shootout benchmarks for D. Right now D is not present on the Shootout site, but the benchmarks are open-sourced and their use is encouraged by the author.

Once we have a setup for the benchmarks, we'd have a good basis to kindly ask the site maintainer to add back D to the suite.


Andrei

Gor Gyolchanyan:

> I'm ready to donate money to sponsor an ad campaign.

Advertising has to be done at the right time and rhythm. Too little and no one knows you, too much and you risk wasting the single opportunity certain persons will give you. D doesn't need too much advertising now. There is not even a hash map in Phobos and there are some unfinished parts in the core language, like inout, const, modules, associative arrays, etc.

Bye,
bearophile

I'll look up any kind of programming language related sites and try to put D put there.

Another big downside, that i noticed in development of D and DMD is unpredictability. I think we should make schedules for regular releases of batches of bug-fixes and feature enhancements of DMD, so that people will be able to use yet-unimplemented features of they're certainly going to be implemented in the next release.

Also in the light of recent investigation, i think it would be very wise to turn
our attention to enhance D's compatibility with C++, since this is one of the
biggest problems, that companies will face if they decide to switch to D. If D
gains a good enough compatibility with C++ (i know, it's a really difficult job),
then the cost of switching to D will dramatically decrease, because less and less
C++ code will need to be rewritten. For those cases when direct access to C++ is
impossible (probably, with multiple inheritance involved), we could make D
libraries, that would interpret C++ headers at compile time and generate wrappers
around it (and such).
It'll take a lot of effort, but it's possible and given the current situation of
commercial non-usability of D it would be a good idea.

Gor F. Gyolchanyan Wrote:

> I'll look up any kind of programming language related sites and try to put D put there.

One problem we have is that there are many that have heard of D, but they either don't hear it enough to consider it any good or know of some problem that may have already been fixed or will be fixed and can't let it go.

> Another big downside, that i noticed in development of D and DMD is unpredictability. I think we should make schedules for regular releases of batches of bug-fixes and feature enhancements of DMD, so that people will be able to use yet-unimplemented features of they're certainly going to be implemented in the next release.

For the most part someone would need to take this role. As a body of volunteers people do what itches them the most. If someone maintained a list of bugs that should be fixed in the next X number of releases it would server as a good reference even if they are not all tackled. And it must take input from the volunteers on which they will be working on.

There is a general consensus on what type of reports get priority over others. DMD does get fairly regular releases and can't always stick to a tight schedule. Once a month has been the norm while 2-3 months may pass.

http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#Roadmap

> Also in the light of recent investigation, i think it would be very wise to turn our attention to enhance D's compatibility with C++, since this is one of the biggest problems, that companies will face if they decide to switch to D. If D gains a good enough compatibility with C++ (i know, it's a really difficult job),

To my understanding D does have good support for C++ now. The limitations come from multiple inheritance, like you said, and templates.

Multiple inheritance of C++ won't be supported as D doesn't have any mapping for it.

Templates are a problem because they must be compiled, and DMD will not include a C++ parser just to have access to templates.

> then the cost of switching to D will dramatically decrease, because less and less C++ code will need to be rewritten. For those cases when direct access to C++ is impossible (probably, with multiple inheritance involved), we could make D libraries, that would interpret C++ headers at compile time and generate wrappers around it (and such).

Wouldn't this basically be a C++ to C interfacing tool? Such a tool sounds kind of interesting, does one exist? Why doesn't one exist? Why do existing ones not get used?

> It'll take a lot of effort, but it's possible and given the current situation of commercial non-usability of D it would be a good idea.

Welcome and good luck promoting D. Please select something you wish to work on and I hope you'll find the support you need. Remember we are a small community and all have something we wish D was better at. And as Bearophile points out, we should be looking to advertise with the right information at the right time.

I had an idea of a D library for including C headers for a while now.
All i need is to make a compile-time C parser for that. This thing would literally
remove any need for binding. Doing the same for C++ would be much much harder, though.

On 22.09.2011 1:14, Gor F. Gyolchanyan wrote:
> I had an idea of a D library for including C headers for a while now.
> All i need is to make a compile-time C parser for that. This thing would literally
> remove any need for binding.

Translating header file is a one-time job, as in
sh-$: translate fancy.h fancy.di

Why would you need to do it at compile time, except because it's fancy :), I don't quite get.

And, as much as I'm sorry to bring bad news, you'd have to make a C preprocessor as well (or even in the first place). Then you'd have to struggle through vendor extensions but that's doable.



-- 
Dmitry Olshansky

about interfacing to d:
There was some kind of tool out there that is never mentioned on one of the
d websites called swig. If you can make it extremely easy and get the bugs
out of the way (maybe even write a decent tutorial on it which I really
need) linking to c++ would be a breeze.

as for promoting the d programming language I think you should start with
wikipedia. I stranded here because I was sick of java's tunnel-visioned
object-oriented too verbose syntax. c++ was just too damn ugly to look at so
I played a bit with scale/python/c#,... In my search to other languages I
looked up all languages with a similar style to java and saw a page about D
and thought by myself "yet another letter of the alphabet". I kept reading
though and saw the code examples. It looked beautiful.
But then I read a bit further and saw all it's shortcommings. still
interested I went to the digitalmars homepage and got lost somewhere over
there with D1 and D2. After that I went to dsource and saw dead forums and
outdated projects so I gave up on D.
A bit later though I read something about D which was prety recent with a
lot of great responses on so I went back to the digitalmars homepage and
tried the newsgroups. Luckely they were very vivid.

Next big step: learning the language. A lot was similar to java but I wanted to learn about those features getting promoted in debates against c++. I found some tutorials on D but they were not sufficient to learn from. Luckely alexandrescu's book was so complete, well writen and easy to follow.

I think to increase D's popularity one could
- increase ease of linking to c(++) (maybe through swig?)
- rewrite the wikipedia page (seriously)
- revamp dsource. It would be great to see news from the blog "the one with
d" apearing on the dsource homepage. A lot of dead projects should be
archived and one should mention in the forums that a better place to try is
the d newsgroup.
- write some tutorials (always helps)
- get D on some benchmark charts

Great to see someone so motivated joining, good luck :)

SWIG kinda scares me... doesn't it generate wrappers instead of direct calls into the C++? That could easily double the size of the library.

There's a bugzilla entry with a thing to allow calling into more of C++'s functions with extern(C++). I'd like to see that pulled into the tree if it passes Walter's eye.

http://d.puremagic.com/issues/show_bug.cgi?id=4620

On Wed, 21 Sep 2011 22:33:06 +0100, Dmitry Olshansky <dmitry.olsh@gmail.com> wrote:
> On 22.09.2011 1:14, Gor F. Gyolchanyan wrote:
>> I had an idea of a D library for including C headers for a while now.
>> All i need is to make a compile-time C parser for that. This thing would literally
>> remove any need for binding.
>
> Translating header file is a one-time job, as in
> sh-$: translate fancy.h fancy.di
>
> Why would you need to do it at compile time, except because it's fancy :), I don't quite get.
>
> And, as much as I'm sorry to bring bad news, you'd have to make a C preprocessor as well (or even in the first place). Then you'd have to struggle through vendor extensions but that's doable.

At one time (2+ years back) I started writing a C lexer, and then C preprocessor in D.  In part to learn about how compilers work and in part to convert C headers to D (there was no .di at that stage) so I could interface C.  The lexer was no trouble, I even managed to make it flexible by having it read a C grammar file but when I got to the preprocessor I lost steam/momentum and it all fell by the way side.

Something I discovered, which may help bootstrap your plans, is that most C compilers will preprocess source for you and give you the resulting stream of text, which you can then lex/parse/etc.  However, this results in the C compiler processing macros and following includes, which you often don't actually want it to do - as you're likely trying to replicate the file tree (so want to see includes) and trying to replace macros with CTFE or similar.

So, perhaps a combined approach, tame a compiler and have it preprocess a file at a time and then use that output, plus the original file to produce some D replacement code.. not sure if that would work but it might be worth investigating.

R


-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/