On Tue, Sep 6, 2011 at 12:48 PM, Andrei Alexandrescu <seewebsiteforem...@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.
