"Dave" <Dave_member@pathlink.com> wrote in message news:dni7a9$viu$1@digitaldaemon.com...
> After reading some of the threads, and seeing mention of D in there
basically
> just get ignored, it becomes apparent that one could come up with the
better
> mousetrap and still the very people who should take notice won't even acknowledge the existance of something that quite probably is not only
better
> but readily available.

There is some curious psychology going on with this. I've met many well known C++ experts who won't say anything positive about D in public, but in private to me they are quite enthusiastic about it. It's almost as if they fear censure or loss of face?

One thing D does is defy the conventional wisdom about C++. There are two
that you mention; some others are:
3) C++'s non-safety is necessary to get its power and flexibility
4) The solution to C++ programming language problem X is to educate the
programmers better


> So it seems D is stuck in the proverbial 'catch 22' situation here, where
the
> real merits of the language only become apparent after learning how to use
it,
> yet those who need to try it won't because of their (understandable)
> assumptions...
>
> How can D break out of this situation?

The biggest thing is to write articles about D and get them published. Present papers on D at conferences. Continue to bring up D in contexts where it is appropriate. Dave - an article about performance? Kris - an article about Mango? Don - an article about D templates? Thomas - an article about your automated testing system? David - an article about implementing GDC? Everyone else, too, who has made important contributions to D and this n.g. You guys all know your stuff and these would be important, interesting articles.

Me, I'll be presenting at Amazon's developer conference in January and in SDWest in March. But D can't succeed if it's just me writing articles and presenting.

Would it help if I offered a bounty for articles? <g>

"BCS" <BCS_member@pathlink.com> wrote in message news:dnicmc$1c07$1@digitaldaemon.com...
> How about a programming challenge? Develop a programming problem that
requires
> the contestant to program against a D language API.

I've thought about this from time to time, but a reasonable way to implement it always seemed to escape me.

"Walter Bright" <newshound@digitalmars.com> wrote
>
> Would it help if I offered a bounty for articles? <g>

People are often financially motivated when there's no other truly driving reason ;-)

The problem with articles is how do you "reject" contributions that are really poor? Ones which might actually cause more harm than good? It's tough to do that in an open-source environment without upset. Thus, a financial reward for articles deemed "worthy" might be something useful, but you'd probably have to make someone else "responsible" for such filtering :-)

Still, those would be nice problems to have!

On second thoughts, this is bullshit. Just ignore it.

I should have noted that "I'd be a bit upset if an article written by me were rejected". It wasn't meant to be the kind of poxy generalization it sounds like :-(


"Kris" <fu@bar.com> wrote in message news:dnif29$1h7k$1@digitaldaemon.com...
> "Walter Bright" <newshound@digitalmars.com> wrote
>>
>> Would it help if I offered a bounty for articles? <g>
>
> People are often financially motivated when there's no other truly driving reason ;-)
>
> The problem with articles is how do you "reject" contributions that are really poor? Ones which might actually cause more harm than good? It's tough to do that in an open-source environment without upset. Thus, a financial reward for articles deemed "worthy" might be something useful, but you'd probably have to make someone else "responsible" for such filtering :-)
>
> Still, those would be nice problems to have!
> 

Kris wrote:
> "Walter Bright" <newshound@digitalmars.com> wrote
>> Would it help if I offered a bounty for articles? <g>
> 
> People are often financially motivated when there's no other truly driving reason ;-)
> 
> The problem with articles is how do you "reject" contributions that are really poor? Ones which might actually cause more harm than good? It's tough to do that in an open-source environment without upset. Thus, a financial reward for articles deemed "worthy" might be something useful, but you'd probably have to make someone else "responsible" for such filtering :-)
> 
> Still, those would be nice problems to have! 
> 
> 

Kris,

Think more outside the box...  The bounty could be compiler/language features that you've been talking about in this NG.  Give an article, get some Walter love into DMD and the spec...

BA

On Sun, 11 Dec 2005 15:41:40 -0800, Walter Bright wrote:

> 
> "BCS" <BCS_member@pathlink.com> wrote in message news:dnicmc$1c07$1@digitaldaemon.com...
>> How about a programming challenge? Develop a programming problem that
> requires
>> the contestant to program against a D language API.
> 
> I've thought about this from time to time, but a reasonable way to implement it always seemed to escape me.

How about this.

The challenge is to write the module they like to see in the D std
lib (phobes,ares ?)

1) With a deadline after 3 month.
2) Then all the entries is published to criticism and suggestions from the
d community.
3) A month later there is a deadline for the final version.
4) Then the winners are found and they get there prizes.
5) Then the modules that have the quality and functionality need is add to
the std lib.

Knud

"Kris" <fu@bar.com> wrote in message news:dnif29$1h7k$1@digitaldaemon.com...
> "Walter Bright" <newshound@digitalmars.com> wrote
> >
> > Would it help if I offered a bounty for articles? <g>
>
> People are often financially motivated when there's no other truly driving reason ;-)
>
> The problem with articles is how do you "reject" contributions that are really poor? Ones which might actually cause more harm than good? It's
tough
> to do that in an open-source environment without upset. Thus, a financial reward for articles deemed "worthy" might be something useful, but you'd probably have to make someone else "responsible" for such filtering :-)
>
> Still, those would be nice problems to have!

I have thought of this from time to time, and that's primarilly why I haven't done it. More than once, a valuable contributor to D has left because they were upset that I didn't agree with a feature they wanted in. Sigh.

How about I pay the bounty if the article gets published in Dr. Dobb's or CUJ? Then, I'm not making the decision, the magazine editors are, and I have no influence over them <g>.

"Brad Anderson" <brad@dsource.dot.org> wrote
> Kris wrote:
>> Still, those would be nice problems to have!
>
> Kris,
>
> Think more outside the box...  The bounty could be compiler/language features that you've been talking about in this NG.  Give an article, get some Walter love into DMD and the spec...


I'll just pray that some don't write good articles :-D

To play Devils' advocate for the moment: I'm not at all sure that a potentially "wonderful" article from me on "how D array-slicing can notably reduce Google's cluster-expenses and utility-bills" is gonna' result in read-only arrays for the language ~ the things I want to see appear to be overly controversial :-)

This (above) is all very tongue-in-cheek though, and you certainly make a valid point :: my focus is too narrow.

> 
> How can D break out of this situation?
> 
> 

After a year or so of dabbling in D I've finally decided that I'm actually going to use it on a few production scale projects.

Here are some of the things that have helped out significantly in letting me do this:

1) I'm in a unique situation as Tech Overlord of my group so I can pretty much dictate what language we use and force people to learn it and make my customer accept it.  I have a particularly sharp, handpicked group that knows C++ and Java pretty well so that's helpful.

2) GDC becoming stable and having binary builds on multiple platforms (many hundreds of thanks to the GDC guys).  Having an open source implementation of the language is necessary on this front.  I can check in a copy of the GDC source and remove any fear of not having the language in the future.

3) I've started what I call D-Distilled which is essentially an in-house version of "D In a Nutshell". I'm using a Wiki to do this so its very easy for my team to cross link back and forth between the different sections.  Having programmer level (not specification level) documentation helps for those people that get intimidated by specifications. (I find most self taught programmers fall into this category)

My particular belief is that when people start seeing projects that are useful to them, that scratch their itch, that they will start using the language.  As I've seen in the government contracting circles I run in, the main motivator in choosing the language is which languages the developers want to use.  If I want to use Ruby to do scripting, I use it (which I did and it turned out great).  I now want to use D for my system level stuff so I'm going to use it.

I don't know if "Marketing campaigns" or anything targetted to managers helps in the environment I run in.  Getting stable compilers that are easy to install, convincing people that it will not go away, and developing software that people actually use are the three key things.

In article <dnif07$1h3a$1@digitaldaemon.com>, Walter Bright says...
>
>
>"BCS" <BCS_member@pathlink.com> wrote in message news:dnicmc$1c07$1@digitaldaemon.com...
>> How about a programming challenge? Develop a programming problem that
>requires
>> the contestant to program against a D language API.
>
>I've thought about this from time to time, but a reasonable way to implement it always seemed to escape me.
>

Would the opposite also apply?  Say a programming contest that is open to compiled languages and doesn't exclude D?  For example, take this speed-programming contest I stumbled onto today:

http://www.ludumdare.com/
(code a working game within 48 hours - use anything you want)

While not an outstanding example, it does demonstrate that there are other grass-roots niches out there that are *easily* within reach of D.

------------
Assuming that we don't have the manpower and resources to mount the kind of ad campaign that D needs, the best we can do is improve the product itself to make it *the* most obvious choice for its niche.  And it has to beat years of mindshare and momentum behind C++ and Java to do that.  This means writeups, tutorials, FAQs (we don't even have one for the NG), manuals, etc.  Lots of un-fun, non-paying, non-programming work.

Honestly, we're still building the toolchain, and assembling 1st tier applications (IDEs, shell utils, kernels, servers, daemons) that I think the current mode is about where I'd expect us to be.  Once D has something on par with JDK1.0, then marketing becomes easier; we're quite close to that now.

Once DMD manages to shed its Beta status, and the associated ABI's and documentation are finalized, continued development on the compiler and spec becomes a *selling point* rather than a fault.  It would allow all of us to say that D is "being actively improved" rather than left to languish with any faults it may have.

And not to beat a dead horse, but I still think there's more that can be done on the web front that is directly under the community's control.  There is a *huge* vacancy in the D community for press, publications, and editorials that could be available as a daily/weekly/monthly website.  The current crop of sites have the "what" and "where" but nothing has the "who" and most importantly "why".  The "how" is scattered about, which is fine, but there's no authoritative source to lend coherence to the community in this regard (IMO, the wiki isn't groomed enough to count).

- EricAnderton at yahoo