Andrej Mitrovic:

> It would really help out if we had some sort of semi-automated script that can do at least partial translation of code that uses old phobos functions to new ones. Maybe this wouldn't work 100% but at least it would help out. I'm thinking of something similar to what Python 2to3 does.

You mean like the standard tool gofix: http://blog.golang.org/2011/04/introducing-gofix.html

Bye,
bearophile

Jonathan M Davis:

> > Breaking std.stdio, which is used everywhere, this thoroughly needs a very high bar of justification.
> 
> Agreed.

The purpose of the gofix tool in the Go language library is to lower this bar significantly :-)

Bye,
bearophile

Count me as another who is sick and tired of the gratuitous breaking changes every damned month.

The worst part is there's still some new stuff I actually want each month, so I'm not doing my usual strategy of never, ever, ever updating software.

It's just pain. Trivial changes are easy enough to fix, but are a pain. More complex changes cost me time and money. (I'm still angry about the removal of std.date. But soft deprecation is even worse - I hate that so much the first thing I do when updating my dmd is to edit the source to get that useless annoying shit out of there)

On 09/05/2011 04:51 PM, Walter Bright wrote:
>> If the new std.path breaks existing code, I need to fix it before it is
>> released. Please let me know what problems you are experiencing.
>
> It prints out all the deprecation message. It means I'll have to go edit
> existing, working code to change the names.

I think it means it gives you time, on your own schedule with generous deadlines, to make the changes to your code.

> I know that the majority wants the name changes. I know the deprecation
> system gives people plenty of time to edit their code.
>
> But I think the cost of breaking existing code is much higher than many
> realize, and a lot of that cost will be hidden. It'll come in the form
> of people deciding not to use D because it is "not stable". It'll come
> in the form of invalidating existing libraries and modules unless
> someone is regularly maintaining them. It'll come in the form of
> invalidating the mass of books, articles, blog postings, and
> presentations about D, and those will never get updated. People will
> type in the code examples, they will fail to compile, and they'll get
> turned off about D.
>
> I'll again note that I know of know successful operating system or
> programming language that goes around breaking existing code unless it
> is really, really urgent.
>
> Camel-casing a name doesn't meet that standard. So, yes, I don't like it.

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

On Tue, Sep 6, 2011 at 12:48 PM, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> On 09/05/2011 04:51 PM, Walter Bright wrote:
>>>
>>> If the new std.path breaks existing code, I need to fix it before it is released. Please let me know what problems you are experiencing.
>>
>> It prints out all the deprecation message. It means I'll have to go edit existing, working code to change the names.
>
> I think it means it gives you time, on your own schedule with generous deadlines, to make the changes to your code.
>
>> I know that the majority wants the name changes. I know the deprecation system gives people plenty of time to edit their code.
>>
>> But I think the cost of breaking existing code is much higher than many realize, and a lot of that cost will be hidden. It'll come in the form of people deciding not to use D because it is "not stable". It'll come in the form of invalidating existing libraries and modules unless someone is regularly maintaining them. It'll come in the form of invalidating the mass of books, articles, blog postings, and presentations about D, and those will never get updated. People will type in the code examples, they will fail to compile, and they'll get turned off about D.
>>
>> I'll again note that I know of know successful operating system or programming language that goes around breaking existing code unless it is really, really urgent.
>>
>> Camel-casing a name doesn't meet that standard. So, yes, I don't like it.
>
> 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
>

My question is why do you even need a standard API for XML and JSON.

Trying to support everything out of the box to a high degree of quality and provide enough generality that it's useful for everybody is just too much work and all you achieve is to discourage alternative implementations better suited to specific needs.

== Quote from Andrei Alexandrescu (SeeWebsiteForEmail@erdani.org)'s article
> In many ways a language's standard library is a
> showcase of the language,

YES!!! I'm glad someone besides me finally realizes this.  For example, whenever someone asks me about why D metaprogramming is so great, I just point them to a few std lib modules that showcase this, e.g.:

http://stackoverflow.com/questions/7300298/metaprogramming-in-c-and-in-d/7300611#7300611

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.


> c) possibly create programs a la gofix that help migration.

gofix cannot fix books, articles, blogs, and presentations.

Furthermore, in order to work successfully, gofix needs to be a complete D front end, capable of handling both the old and the new stuff. Doing a perl script would be a disaster. It's a substantial project, has a high risk of inadequacy, and I suspect our resources are better spent elsewhere.

Considering also the problems people have running dmd and getting it to find their imports and libraries, add in having to run 'gofix' over their source code first, then patch up what gofix goofed up, seems a stretch.

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

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?

-- 
/Jacob Carlborg

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