On Thu, Sep 25, 2014 at 03:48:11PM -0700, Andrei Alexandrescu via Digitalmars-d wrote: > On 9/25/14, 2:03 PM, eles wrote: > >On Tuesday, 23 September 2014 at 14:29:06 UTC, Sean Kelly wrote: > > > >>lack of attention paid to tightening up what we've already got and > >>deprecating old stuff that no one wants any more. And inconsistency > >>in how things work in the language. > > > >The feeling that I have is that if D2 does not get a serious cleanup > >at this stage, then D3 must follow quickly (and such move will be > >unstoppable), otherwise people will fall back to D1 or C++next. > > I'm not sharing that feeling at all. From that perspective all > languages are in need of a "serious cleanup". -- Andrei
I've been thinking that it might do us some good if we aren't as paranoid about breaking old code, as long as (1) it's to fix a language design flaw, (2) it exposes potentially (or outright) buggy user code, (3) users are warned well ahead of time, followed by a full deprecation cycle, and (4) optionally, there's a tool, either fully or partially automated, that can upgrade old codebases. I mean, enterprises use deprecation cycles with their products all the time, and we don't hear of customers quitting just because of that. Some of the more vocal customers will voice their unhappiness, but as long as you're willing to work with them and allow them sufficient time to migrate over nicely and phase out the old stuff, they're generally accepting of the process. We've already had offers from D-based organizations asking to please break their code(!) for the sake of fixing language design flaws -- this is already far more than what most enterprise customers are generally willing to put up with, IME. Yet we're doing far less than what enterprises do in order to keep their product up-to-date. We may need to use very long deprecation cycles to keep everyone happy (on the order of 2-3 years perhaps), but doing nothing will only result in absolutely zero improvement even after 10 years. T -- Кто везде - тот нигде.
