On Sunday, 30 August 2015 at 02:34:46 UTC, Ola Fosheim Grostad wrote:
> Then why are they trailing the main compiler if they represent an insignificant effort?

In some areas, they are ahead. gdc is directly responsible for the D debugging experience on Linux, for example.

But they also have fewer than 10% of the contributors.

On Sunday, 30 August 2015 at 03:04:28 UTC, Adam D. Ruppe wrote:
> On Sunday, 30 August 2015 at 02:34:46 UTC, Ola Fosheim Grostad wrote:
>> Then why are they trailing the main compiler if they represent an insignificant effort?
>
> In some areas, they are ahead. gdc is directly responsible for the D debugging experience on Linux, for example.
>
> But they also have fewer than 10% of the contributors.

Number of contributors does not say all that much. It is competence and tine that matters. For a project that is in perpetual beta leaders need to show their priorities. Here is a good list:

1. Complete the language specification (define semantics).
2. Implement and polish semantics.
3. Clean up syntax.
4. Tooling.
5. Performance.

As a leader you should create a frame for others to fill in. That means you cannot afford to focus you effort on point 5, it essentially means you resign the role as a project lead.

Enabling others to work at point 5 would be completely ok...

On Sunday, 30 August 2015 at 02:16:13 UTC, Adam D. Ruppe wrote:
> On Sunday, 30 August 2015 at 01:48:06 UTC, Ola Fosheim Grostad wrote:
>> When people work on FOUR compilers then you cannot complain about lack of resources. You then need to see if you can do something to unite efforts.
>
> They aren't really four compilers. It is more like 2.1. sdc is a separate project, but dmd, ldc, and gdc share like 90% of the effort, so it is more realistic to call them 1.1 compilers rather than 3...

And it's not like Walter could order the vast and well compensated GDC team to stop and go and work on DMD, even if that made sense.

To make the observation that someone unhappy with a state of affairs has the option to contribute the time to help move the world in the direction they think good is not quite the same thing as complaining about a lack of resources.   Morale is important in long term projects that don't pay off very quickly, and constant nagging and grumbling doesn't tend to help, even in the case when it is entirely well founded.

On 30 Aug 2015 4:45 am, "rsw0x via Digitalmars-d" < digitalmars-d@puremagic.com> wrote:
>
> On Sunday, 30 August 2015 at 02:13:59 UTC, Adam D. Ruppe wrote:
>>
>> On Saturday, 29 August 2015 at 23:10:29 UTC, Jonathan M Davis wrote:
>>>
>>> It's the reference compiler, so it's what folks are going to grab first
and what folks are most likely to compare with their C++ code.
>>
>>
>> Maybe we should rebrand it to be the "development preview compiler" and
make gdc the "stable production compiler". or something.
>
>
> Then people write code that works on dmd just to realize GDC is 2-3
versions behind and doesn't compile their code(no offense meant to the GDC
team)

I made a chart around 6 months back that tracks the timeline of gdc vs. dmd versions of D2.  And in it you can see a clear change of pattern from when it was just Walter maintaining and releasing to when dmd switched over to github and founded the core language team.

But someone else or I should make a few more, such as one that tracks code changes between releases, to get a wider picture of why it seems that other vendors appear to fall behind.

Iain.

On Sunday, 30 August 2015 at 06:07:25 UTC, Laeeth Isharc wrote:
> To make the observation that someone unhappy with a state of affairs has the option to contribute the time to help move the world in the direction they think good is not quite the same thing as complaining about a lack of resources.   Morale is important in long term projects that don't pay off very quickly, and constant nagging and grumbling doesn't tend to help, even in the case when it is entirely well founded.

Actually, it does help. There has been changes over time. Right now the most sensible thing to do is to focus on stability, refactor the codebase, document the codebase and track regressions. If you actually want others to contribute you need to leading by example... E.g. you need to get the boring stuff done first.

There is absolutely no point in helping out with a project that add features/optimizations faster than they are finished. Such projects are never finished. Even if you got 10 more people to work on it, the outcome would not be that it would be finished, you would end up getting more features, not more polish.

On Saturday, 29 August 2015 at 14:44:01 UTC, Casual D user wrote:
> D is advertised as a system's language, but most of the built-in language features require the GC so you might as well just use C if you can't use the GC.

Are you sure about C? https://news.ycombinator.com/item?id=10139423

On Tuesday, 1 September 2015 at 16:05:43 UTC, Kagamin wrote:
> On Saturday, 29 August 2015 at 14:44:01 UTC, Casual D user wrote:
>> D is advertised as a system's language, but most of the built-in language features require the GC so you might as well just use C if you can't use the GC.
>
> Are you sure about C? https://news.ycombinator.com/item?id=10139423

It's been mentioned before that there really isn't much point in using C when you can use D. Even if you completely avoid the GC and the standard library, you're _still_ ahead of where you'd be with C, and you can call C functions trivially. So, you can definitely use D as a better C; you just lose out on a lot of cool stuff that D has to offer beyond that. But D has a lot to offer over C even without using any of that stuff.

One of the first projects I used D for was back in college a number of years ago where I got sick of some of the issues I was having with C++ and went with D because it gave me stuff like array bounds checking. I was using very few of D's features (heck, D2 was quite young at that point, and I don't think that ranges had been introduced to Phobos yet at that point, so the standard library was seriously lacking anyway), but it was still easier to use D.

- Jonathan M Davis

On Tuesday, 1 September 2015 at 17:14:44 UTC, Jonathan M Davis wrote:
> One of the first projects I used D for was back in college a number of years ago where I got sick of some of the issues I was having with C++ and went with D because it gave me stuff like array bounds checking. I was using very few of D's

http://en.cppreference.com/w/cpp/container/array/at
http://en.cppreference.com/w/cpp/container/vector/at
https://github.com/google/sanitizers

On 8/29/2015 12:37 PM, Laeeth Isharc wrote:
> In my experience you can deliver
> everything people say they want, and then find it isn't that at all.

That's so true. My favorite anecdote on that was back in the 1990's. A friend of mine said that what he and the world really needs was a Java native compiler. It'd be worth a fortune!

I told him that I had that idea a while back, and had implemented one for Symantec. I could get him a copy that day.

He changed the subject.

I have many, many similar stories.

I also have many complementary stories - implementing things that people laugh at me for doing, that turn out to be crucial. We can start with the laundry list of D features that C++ is rushing to adopt :-)

On 8/29/2015 1:13 PM, Ola Fosheim Grostad wrote:
> But the net effect of maintaining 3 different backends is sending signals that
> the project lacks direction and priorities.

Back when there was only 1 compiler, people complained about that, saying it signaled lack of reliable support.

Having 3 D compilers is a big positive. Each has their strengths and weaknesses. It's all good.

People can and do interpret anything and everything about D as a negative. Or get involved and do something positive.