On 2011-09-06 08:56, Jonathan M Davis wrote:
On Tuesday, September 06, 2011 08:42:14 Jacob Carlborg wrote:
On 2011-09-06 08:00, Walter Bright wrote:
On 9/5/2011 7:48 PM, 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.
I agree that the XML and JSON libraries need to be scrapped and
rewritten. But simply changing the names of otherwise successful APIs is
not worth while.
So we have to live with these naming conventions from C forever?
My take on it is that we need to figure out which pieces of Phobos need to be
reworked or renamed and get it done as soon as possible. That way, everything
follows the proper naming conventions (thus avoiding a mess like PHP) and is
of an appropriately high level of quality. Then we can have an appropriately
stable API which doesn't have to change often - if at all. I think that the
current problem with Phobos is primarily a combination of three things:
1. Older APIs which aren't in line with how D2 and Phobos have evolved (e.g.
they don't use ranges when they should).
2. Some older stuff didn't get a thorough enough peer review before making it
into Phobos and is not at a high enough level of quality, so it needs to be
revised or replaced.
3. Too much of what has been done in the past has been a hodgepodge of naming
conventions, making it very inconsistent in some places.
Once those have been sorted out (some of which can be done without breaking
any existing code and some of which requires breaking changes), then we can
have a stable API for Phobos which doesn't change much except where we're
adding new functionality which doesn't break existing code. So ultimately, we
_will_ have a stable API, but some breaking changes are required in the short
term to resolve issues with Phobos which would cause problems in the long run.
- Jonathan M Davis
Yes, thank you, I agree.
--
/Jacob Carlborg
