Why I (Still) Won't Use D

[Georg Wrede]

Michiel Helvensteijn wrote:
> By hard-coding certain behaviors in the core language, you've taken away the
> freedom of the programmer to choose these hirself. Like the growth-rate of
> dynamic arrays. Or the sorting algorithm used by the .sort property. Or the
> datastructure returned by the .keys property of associative arrays.

These could be parameterizable. (Like the growth-rate of dynamic arrays, 
etc.) At this stage of D, however, it may be more practical to have them 
chiseled in stone for the time being, letting us concentrate on more 
current and/or pressing issues.

Of course, later (when most of the more pressing issues are solved) one 
could be interested in parameterizing these. (Or simply tuning them to 
get them exactly right.)

And of course, nothing stands in the way of somebody writing a superior 
implementation of these, already today. Or the other (today-considered) 
basic data structures. Actually, if somebody does this, chances are 
they'd be incorporated into D.

We've seen plenty of examples of somebody writing an excellent module 
that's later been incorporated into Phobos. And there's a lot of room 
for potential writers: currently std.algorithm does not contain 
next_permutation or prev_permutation. Not to mention all the things one 
wouldn't guess off-hand. Or the things that really make a difference, 
like something fiercely usable, that we've simply ignored so far.

Additionally, since the front-end of D is public domain, you may read, 
copy, modify, and eventually even return the derived contributions to 
the community. In other words, if the datastructure returned by .keys is 
inadequate, copy it off of the library, and enhance it. When you're 
satisfied, simply send it to Walter, or publish it here to get some 
feedback.