On 2011-09-06 04:48, Andrei Alexandrescu wrote:
I agree with all of the above. However, as is often the case, there's
more than one side to the story.
Bad APIs have their costs too. We can't afford to have an XML library
that offers few and badly packaged features and comes at the tail of all
benchmarks. We also can't afford a JSON library that is poorly designed
and badly written. Ironically, the costs mostly manifest the same way:
people will decide not to use D because it "lacks good libraries" and
"is quirky to use". In many ways a language's standard library is a
showcase of the language, and to a newcomer an inconsistent and awkward
standard library affects the perception of the language's quality.
Stressing that breaking code has a cost and implying that keeping it
with flaws has no cost is as mistaken as worrying in chess about the
flank at the expense of the center.
The reality we need to face is, we are experiencing growth pains. What
we must do is NOT lament about breaking this or keeping that. We must:
a) devise good language features to cope with deprecation, of which
deprecation with message is one that I think we need to embrace and
extend (I have a few ideas I'll discuss separately);
b) supplement that with a good policy for deprecating APIs and
introducing new ones - in particular decide where to draw the line when
introducing a breaking change;
c) possibly create programs a la gofix that help migration.
Andrei
We don't want to have a standard library like the one in PHP where there
seems to be no naming conventions at all.
--
/Jacob Carlborg
