There have been threads about what the biggest issues with D are, and about the top priorities for D are, but I don't think there has been a thread about what the best things are that the community can do to help D.

Should people try to spread the word about D? I'm not even sure this is a good idea. We all know that D2 is far from stable at the moment, and getting people to try D in its current state might actually put them off (first impressions are very important).

Should people try to help with dmd and Phobos? If so, what are the best ways to do that?

Should people work on other D compilers (gdc and ldc in particular)? Is this even possible without a formal language specification?

What else can we do to help? And what would we consider to be the *best* ways to help?

I think, you can write document for beginners with D2. Because D2's document is bad for beginners. And tpdl not for beginners.

On Sat, 23 Oct 2010 16:09:37 +0100, Peter Alexander <peter.alexander.au@gmail.com> wrote:
> thread about what the best things are that the community can do to 
help D.

And easy target would be to improve the documentation with better explanations for D outsiders and more examples. This way Walter et all could devote more time to coding.

D needs good docs. See for example this question http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learn&article_id=22405

On 23/10/10 6:27 PM, Kagamin wrote:
> D needs good docs. See for example this question
> http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learn&article_id=22405

I agree that better documentation would be nice, but really the documentation needs to be updated on the main page, and that's not something that the community at large can do (unless I'm mistaken).

Peter Alexander wrote:
> There have been threads about what the biggest issues with D are, and about the top priorities for D are, but I don't think there has been a thread about what the best things are that the community can do to help D.

Some things are (pick one that interests you):

Write articles about D and post them online in various forums

Go through bugzilla and submit patches for bugs

Provide D interfaces (.di files) to popular C libraries

Integrate D support for your favorite editor

Write convoluted code to try and break the compiler

Contribute to the GDC and LDC projects

Write library modules for an area that you know well

On 10/23/10 13:28 CDT, Peter Alexander wrote:
> On 23/10/10 6:27 PM, Kagamin wrote:
>> D needs good docs. See for example this question
>> http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learn&article_id=22405
>>
>
> I agree that better documentation would be nice, but really the
> documentation needs to be updated on the main page, and that's not
> something that the community at large can do (unless I'm mistaken).

You could definitely influence that. We're having sort of catch-22. Consider you know for a fact you could write a superb tutorial on D, good to be on the first page of d-programming-language.org. But you are deadlocked by the spectrum of working in vain, so you end up not writing it.

Regarding the original question, it all depends on the level at which one wants to engage. We have some simple things that keep on falling towards the tail of the to-do list. In my experience, a strong proponent is the best recipe for success.

1. Quality articles, blog entries, experience reports always help. There's a good amount of solid knowledge around this group and some posts here are of very good quality - almost good to plop in a compelling blog and close to a real article. When being comfortable and appreciated within the community, it's very easy to forget that the outreach of newsgroups posts is minuscule and ephemeral. I've noticed that there are blips in TDPL's Amazon's rating whenever something about D gets out there (reddit, article, popular blog etc.) There is no correlation with even very fruitful and interesting newsgroup activity. Statistically, nobody knows about this group :o).

2. Code (whole applications, library submissions). Nothing adds to a language's credibility more than code samples, libraries, entire applications. Strong proposals for Phobos are still rare, though the situation is improving considerably.


Thanks,

Andrei

On 23/10/10 7:30 PM, Walter Bright wrote:
> Peter Alexander wrote:
>> There have been threads about what the biggest issues with D are, and
>> about the top priorities for D are, but I don't think there has been a
>> thread about what the best things are that the community can do to
>> help D.
>
> Some things are (pick one that interests you):
>
> Go through bugzilla and submit patches for bugs
>
> Contribute to the GDC and LDC projects

These two a very difficult without a complete language spec. I just had a look through a bunch of bugs and I couldn't even tell if they are bugs or not because there's no spec to tell me.

For example, a recent bug regards the validity of:

void main()
{
  { static int x; }
  { static int x; }
}

It produces a linker error just now, but I don't know if that's correct behavior or not. The D website makes no mention of the correct behavior and TDPL doesn't go into that much detail either.

In fact, I don't think the website mentions static function scope variables at all (though TDPL does).

Even veteran D coders are confused about what's supposed to work and what's not: http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=120112

I don't mean to be negative, but it would really help the language if there was a complete spec. Until there is, people will be reluctant to fix bugs, nobody is going to attempt to write another compiler, and certainly no one can write better documentation if they don't know how things work.

On Sun, 24 Oct 2010 01:06:02 +0400, Peter Alexander <peter.alexander.au@gmail.com> wrote:

> On 23/10/10 7:30 PM, Walter Bright wrote:
>> Peter Alexander wrote:
>>> There have been threads about what the biggest issues with D are, and
>>> about the top priorities for D are, but I don't think there has been a
>>> thread about what the best things are that the community can do to
>>> help D.
>>
>> Some things are (pick one that interests you):
>>
>> Go through bugzilla and submit patches for bugs
>>
>> Contribute to the GDC and LDC projects
>
> These two a very difficult without a complete language spec. I just had a look through a bunch of bugs and I couldn't even tell if they are bugs or not because there's no spec to tell me.
>
> For example, a recent bug regards the validity of:
>
> void main()
> {
>    { static int x; }
>    { static int x; }
> }
>
> It produces a linker error just now, but I don't know if that's correct behavior or not. The D website makes no mention of the correct behavior and TDPL doesn't go into that much detail either.
>
> In fact, I don't think the website mentions static function scope variables at all (though TDPL does).
>
> Even veteran D coders are confused about what's supposed to work and what's not: http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=120112
>
> I don't mean to be negative, but it would really help the language if there was a complete spec. Until there is, people will be reluctant to fix bugs, nobody is going to attempt to write another compiler, and certainly no one can write better documentation if they don't know how things work.
>

FWIW, similar problem exists:

class Foo
{
    void foo1()
    {
        struct Bar {}
    }

    void foo2()
    {
        struct Bar { /* different set of fields and methods */ }
        // using Foo.foo2.Bar here
        // bang! linker errors
    }
}

Denis Koroskin:

> FWIW, similar problem exists:
> 
> class Foo
> {
>      void foo1()
>      {
>          struct Bar {}
>      }
> 
>      void foo2()
>      {
>          struct Bar { /* different set of fields and methods */ }
>          // using Foo.foo2.Bar here
>          // bang! linker errors
>      }
> }

I have tried this, with no errors:


class Foo {
    void foo1() {
        struct Bar { string s; }
    }

    void foo2() {
        struct Bar { int x;
            int spam() { return 1; }
        }
        Bar b = Bar(10);
        int y = b.spam();
    }
}

void main() {
    auto f = new Foo;
    f.foo2();
}


Are you able to show me code (or a bug report) that doesn't work?

Bye,
bearophile