Biggest Issue with D - Definition and Versioning

[Adam Wilson]

On Wed, 18 Jan 2012 15:13:19 -0800, Walter Bright  
<newshound2 at digitalmars.com> wrote:

> On 1/18/2012 2:15 PM, Adam Wilson wrote:
>> I would argue that what would have the most effect is a concerted  
>> effort to
>> stabilize the compiler. That means normalizing the differences between  
>> DMD/DRT,
>> the Spec, and TDPL. That means taking a break from anything new  
>> (regardless of
>> how badly we want them ... *COFF*COFF*), doing a thorough audit of the  
>> open
>> issues and prioritizing compiler issues first. Then dedicated a release  
>> or three
>> to doing nothing but fixing those issues. There are 2719 open issues in  
>> the
>> bugtracker; that number alone will scare off many potential users. And  
>> the
>> number of ICE's is much higher than it really should be to call DMD  
>> stable. In
>> open-source terms, DMD is beta. I'm leaving out Phobos here  
>> specifically because
>> it doesn't interact with the compiler nearly as much as the runtime  
>> does.
>
> Take a look at the changelog. I just don't see how anyone could conclude  
> that is not exactly what we are doing. Here's the current list for the  
> upcoming version of D2:
>

[snip]

I am not trying to devalue the work that you guys have done, it is frankly  
impressive. But D feels like it lacks any real direction, certain things  
get fixed while other languish. Bugs are fixed seemingly at random. To  
some people is says "to disorganized to work with" (no reasonable  
expectation my issue won't get forgotten in the hustle) to others it says  
"to many brush fires for the team to handle" (more critical issues than  
are acceptable, which means any blocking issues I may have will naturally  
fall down the list). I am not saying these are necessarily true, but D has  
a perception problem, and this perception is a large part of it.

I think what we are all trying to say that we need to know *when* things  
are going to get done ... and "sometime in the future" doesn't cut it.  
Then have those things actually GET done about when they were promised.  
People wouldn't feel like they had to get their issues addressed RIGHT  
NOW, if they had a reasonable expectation of when they will be addressed.

When large teams evaluate a language they care not only about what it can  
and can't do today, but also when it will be able to do what it was  
promised to do. As a project manager, I can work around the fact that  
something might not be working now, but will later, as long as I know  
roughly when it will start working. I'm not saying that we need a hard  
date, a window of a couple of months would be FANTASTICALLY useful in  
terms of planning a project, and I am sure that anyone else who has run a  
project would agree.

-- 
Adam Wilson
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/