On Wed, 18 Jan 2012 15:13:19 -0800, Walter Bright
<newshou...@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/
