Unofficial wish list status.(Jul 2008)

[John Reimer]

Hello Sean,

> == Quote from bearophile (bearophileHUGS at lycos.co)'s article
> 
>> 4tuu4k002 at sneakemail.com:
>> 
>>> This is the monthly status for the unofficial d wish list:
>>> 
>> ...
>> It's curious to see that many or most of the top desired things don't
>> seem among the list of the next things
> planned as improvements/changes for the D/DMD. I don't know what this
> means. Are people asking for unimportant things? Are the D designers
> smarter? Are the two groups ignoring each other?
> 
> For better or worse, I don't personally feel that the D designers
> listen to the D community
> at all.  Certainly not since D 2.0 was started at any rate.  Or
> perhaps it's just that my goals
> with D simply diverged beginning with 2.0.
>> When I think about such matters I remember a quote, usually
>> attributed to Henry Ford: "If I'd asked people what
>> 
> they wanted, they would have said a faster horse."
> 
>> So maybe D programmers want faster horses, while D developers are
>> inventing/providing cars :-) I don't know.
>> 
> It's an interesting question, and one I've been mulling over for a few
> years now.  My
> understanding is that C++ was created as a very community-driven
> effort right from the
> start while D was designed based very much on what Walter thought
> would be good in a
> language.  As a result, C++ ended up bogged down with a lot of legacy
> C baggage that the
> community insisted was necessary for them to adopt C++, while D could
> change tracks on
> the designer's whim and no one could say otherwise.  Generally, I
> think the D approach works
> far better so long as the designer's goals match the interests of the
> community, but it's a
> pretty risky path to follow since the designer is basically betting
> the farm on the hope that the
> community will agree with his vision.  In the past I've been pretty
> free with my opinions about
> language features and I do this because I don't want to feel that I
> didn't try to make myself
> heard if I ever give up on D.  At least then I can feel that I did my
> best to communicate to the
> designers what's important to me as a user of the language.
> Sean
> 


Hi Sean,

I agree with much of what you say.  I have a few thoughts too (Dare I? :D).

D design has actually moved into a tightly controlled group, apparently motivated 
by the authors desire to avoid the C++ committe process: there is no way 
to say this is a wrong approach (yet, it's a reactive one), although there 
is often an apparent lack of communication from the D designers to the community 
at large (However, some might argue that the core designers did try to participate 
here only to be "tarred and feathered"  by the community). Whether this is 
better or worse (compared to C++) for the growth of the language is yet to 
be seen.  I don't expect this anti-committee style to work any better in 
the long run than a pro-committee roadmap.  But I could be wrong.  Whether 
benevolent dictatorship, oligarchy, or design-by-committee, the problems 
related to language growth and design probably lie outside any one methodology 
(although there's likely a pinch of truth in the reasonings against certain 
methods).  

The problem doesn't lie in just the language design, but perhaps also in 
the organization and management of develpment -- as others have suggested 
repeatedly -- in additon to various judgement calls on what will most benefit 
the language's advancement in popularity.  Should time be invested in pure 
language design or in updates to aging toolsets (eg let's ditch omf format 
and improve the win32 linker!), or in commitments to bug fixes?  Naturally 
a community is going to be very desirous of quality working toolsets and 
simple installation.  Meanwhile, a designer is going to be strongly tempted 
to "improve" language features.  Does the community know best in this regard?

This however is not the only problem: 

There a quasi effort from the designer(s) to show some magnanimity to alternative 
libraries (eg Tango) without any apparent commitment to what such support 
means for the future of D. The silence is deafening and tends to demotivate 
a community almost as fast as any pro-D article can pump up the language 
perception to the non-community public.  This is a foggy spot for D's future 
before the eyes of the community.  Is it really possible to promote a language 
based on two libraries with no evidence of interest, disinterest, or concern? 
 This has been somewhat of a puzzle to me as I've watched the divergent efforts 
of the two libraries progress with ever more apparent impossible reconciliation. 
 Why does this problem appear to continue to be ignored?  Do the designers 
believe that "what will happen will happen", and therefore, "waiting and 
silence" is the only and inevitable solution?  If so, it would at least be 
nice to have this stated plainly so all could understand the "why" of D's 
direction. 

Another problem is the original effort to make the language appear community 
driven;  whether it is or not really isn't as important as being clear about 
intentions to the community.  I think we would all agree that this language 
is not so community driven as we originally thought. Or, perhaps, it is better 
to say that it once was and now is not.  Some significant elements are community 
driven: like gdc and Tango and various libraries.  But these remain inextricably 
dependent on the D design timeline and bug fixes (as well as vexed by the 
same). And, even at that, Tango remains the most consistant community effort, 
while most other community efforts are prone to lag.

Tango remains a solid example of a community-contributed process.  This library 
was an attempt to turn D into a community project in direct response to a 
general Phobos' apathy (in terms of bug fixes and design progression).  One 
way to look at this is to realize that Tango might not have been here if 
it weren't for Phobos' failure.  On the other hand, perhaps we should consider 
what kind of library D would have engendered if Phobos had been more community 
driven from the start?  From what I can see of Tango, it has amply proved 
itself:  hosts of community contributions and testings with clear directions 
from a committed and talented core development team made Tango what it is 
today.  I think Tango found the right balance of receptiveness vs controls 
for project management.  (Tip of the hat to Kris, Lars, and Sean for managing 
to get it so far)

And then there's Walter... Walter's D language design and compiler are examples 
of incredible contribution and effort via a different style... what appears 
to be an incredibly single-handed, brute-force operative method (with dogged 
determination!).  If only such talents could merge to make a more organizationally 
sound process for D /and/ it's standard library.

But in the end, the design of the language just becomes yet another ideological 
struggle of one's opinion over another's. It's inevitably, mutually political 
and sacred with or without a committee and is made more so as ideas collide 
from our varied experience and perceptions of what feels right.  Walter's 
success with D is in largely due to his appeal to what we sense is wrong 
in other languages;  he has managed to excite us via our dissatisfaction 
over past experiences (eg. Java and C++)... and that's a powerful form of 
influence.  That is where the success of D has come whether or not we've 
agreed with his control structure along the way.  The lead D designer has 
chosen his oligarchy to advance that design, and the community acts as the 
samplers of it; we are the measurement of potential language feature popularity 
and usability.  And so the process continues with the next language that 
comes around.  Indeed, the miracle is that such contributions can somehow 
merge at all and that people /remain/ loyal to it.  

But then... perhaps it's not so surprising after all. ;)

-JJR