www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Paradox about D's popularity.

reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
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.
Sep 21 2011
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Sep 21 2011
parent Gor F. Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
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.
Sep 21 2011
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
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
Sep 21 2011
parent Peter Alexander <peter.alexander.au gmail.com> writes:
On 21/09/11 6:41 PM, bearophile wrote:

 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 agree with this. There are large and important parts of the language 
that simply haven't been implemented or barely work.

If everyone were to come and use D now, expecting a finished language, 
they would be disappointed. A single bad experience can put people off 
for years, or even a lifetime. Just look at how many people still 
complain about Tango vs. Phobos. It's not worth risking IMO.
Sep 22 2011
prev sibling parent reply Jesse Phillips <jessekphillips+D gmail.com> writes:
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.
Sep 21 2011
parent reply Gor F. Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
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.
Sep 21 2011
next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
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
Sep 21 2011
next sibling parent reply "Regan Heath" <regan netmail.co.nz> writes:
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/
Sep 22 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-09-22 11:47, Regan Heath wrote:

 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


I've done something similar using Clang: 
https://github.com/jacob-carlborg/clang

-- 
/Jacob Carlborg
Sep 22 2011
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Ideally, you also want to simply convert #ifdefs to static ifs as well. It's=
 details like this that have convinced me I can manually convert headers in l=
ess time than it takes me to manually post-process the result of an automati=
c translator. Sad.=20

Sent from my iPhone

On Sep 21, 2011, at 2:33 PM, 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 l=




iterally

 remove any need for binding.


=20
 Translating header file is a one-time job, as in
 sh-$: translate fancy.h fancy.di
=20
 Why would you need to do it at compile time, except because it's fancy :),=


 I don't quite get.

=20
 And, as much as I'm sorry to bring bad news, you'd have to make a C prepro=


cessor as well (or even in the first place). Then you'd have to struggle thr=
ough vendor extensions but that's doable.

=20
=20
=20
 --=20
 Dmitry Olshansky
Sep 22 2011
parent Adam D. Ruppe <destructionator gmail.com> writes:
I'm thinking the best way to translate C headers is to run it
through a string processor instead of a compiler.

There's some places where I want the compiler - especially figuring
out the values of some constants - but usually, when translating
C headers, I just copy/paste and find/replace.
Sep 22 2011
prev sibling parent reply maarten van damme <maartenvd1994 gmail.com> writes:
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

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 :)
Sep 21 2011
parent Adam Ruppe <destructionator gmail.com> writes:
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
Sep 21 2011