On Tuesday, 26 January 2016 at 21:47:41 UTC, Ola Fosheim Grøstad
On Tuesday, 26 January 2016 at 21:03:01 UTC, tsbockman wrote:
Also, you skipped past the "uninterested" part - this is a
volunteer project, remember?
I didn't think it was a relevant argument as you can still
write libraries for distribution. Keep in mind that the
standard library has to be maintained and API's cannot easily
be redesigned because of backwards compatibility.
Even if C/C++ have small standard libraries they provide a
depressing amount of low quality functionality that one should
avoid. But it is kept in for backwards compatibility and
sometimes even updated and extended...
That not a good thing.
There are certainly disadvantages to the standard library model
of distribution and maintenance.
On the other hand:
1) The prospect of getting something into the standard library is
a huge motivator for (at least some) potential contributors.
Why? Because building a library that no one knows about/trusts is
wasted effort. Getting something into `std` is among the most
effective forms of marketing available, and requires little
non-programming-related skill or effort on the part of the
2) Standard libraries don't enforce backwards compatibility (and
high code quality in general) just for the sake of bureaucracy -
they do so because these are highly desirable characteristics for
basic infrastructure. People shouldn't have to rewrite their
entire stack every 6 months just because someone thought of a
better API for some low-level component.
Making it through D's formal review process typically raises code
quality quite a lot, and the knowledge that backwards
compatibility is a high priority makes outsiders much more likely
to invest in actually using a library module.
In short, while you make some valid points, your analysis seems
very lopsided; it completely glosses over all of the positives
associated with the status quo.