Biggest Issue with D - Definition and Versioning

[Adam Wilson]

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

> On 1/18/2012 1:27 PM, Patrick Stewart wrote:
>> How about putting equal effort in keeping existing D users? There is  
>> more
>> than one blogs online of ex D users with some pretty solid arguments  
>> why they
>> abandoned D. And those args are usually not some missing shiny feature  
>> X but
>> feature Y D already has but it is broken.
>
> I do attach far more importance to that than to reasons people who never  
> used D do not use D.
>
>
>> Just saying focusing on bright future is not excuse to forget about  
>> imperfect
>> now.
>
> I'm not saying it is.
>
> The point is, we have limited resources. We have to put those resources  
> where they will have the most effect.

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.

I would also argue that the above point is even more important in light of  
the fact that DMD has such limited resources. Accurate and efficient  
targeting of those resources is crucial to D's survival. New features,  
while exciting, only introduce the opportunity for new bugs and  
regressions. But without a stable compiler a language is just a theory and  
some mathematical proofs.

Once we have a stable compiler it gets much easier to build out libraries  
of code. These libraries are what really sell the language as they not  
only provide a preexisting toolbox for new developers, but also show that  
the language is mature enough to reliably handle complex bodies of code.  
Also once a stable compiler exists writing coherent documentation also  
gets much easier as the number of undefined and undocumented behaviors is  
significantly reduced. Ideally the documentation would have been written  
first but at this point I think it is way to much work for said limited  
resources to document and code at the same time.

To be honest, I think this is the end-goal that Andrei is shooting for in  
his "Planning Software?" thread...

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