On Thursday, 25 September 2014 at 22:48:12 UTC, Andrei Alexandrescu 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

BTW, I already have somebody who's sharing my feelings, not looking further.

On Thursday, 25 September 2014 at 22:48:12 UTC, Andrei Alexandrescu 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

The serious question is at what cost does this un-sharing come. The cost of the always-niche (aka "nice try") language?

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

-- 
Кто везде - тот нигде.

On 9/25/14, 4:07 PM, Brian Rogoff wrote:
> On Thursday, 25 September 2014 at 13:49:00 UTC, Andrei Alexandrescu wrote:
>> I've recently used Rust a bit and the curse of D users as of 6-7 years
>> ago reached me: most code I download online doesn't compile for
>> obscure reasons, it's nigh impossible to figure out what the fix is
>> from the compiler error message, searching online finds outdated
>> documentation that tells me the code should work, and often it's
>> random name changes (from_iterator to from_iter and such, or names are
>> moved from one namespace to another).
>
> That's more than a bit unfair.

This is not about fairness. -- Andrei

On Thu, 25 Sep 2014 21:37:17 +0000
eles via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> I find it too inconsitent. I doubt even Python programmers migrating to D love that...
> 
> And, just: std.uni->std.unicode
> 
> And I cannot believe that the language-defined complex types are still there (since the D1 days...). Either in the library, either in the language, but, please, pick *one* kind.
it's too late to change it. at least that's what i've been told. imaginary future users will be scared.

On Thu, 25 Sep 2014 16:11:57 -0700
"H. S. Teoh via Digitalmars-d" <digitalmars-d@puremagic.com> wrote:

> Nah, they should be behead() and amputate().
i like it! this makes language much more expressive.

On Thu, 25 Sep 2014 15:48:11 -0700
Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com>
wrote:

> I'm not sharing that feeling at all. From that perspective all languages are in need of a "serious cleanup". -- Andrei
and they *are*. yet many languages can't be fixed due to huge amount of written code and user resistance. D is in winning position here: "most of D code yet to be written", yeah. and D users (even corporate users) are very welcome of breaking changes -- if they will make D more consistent and clean.

the situation is... weird now. users: "it's ok, we WANT that breaking changes!" language developers: "no, you don't. it's too late."

On 9/25/2014 2:47 PM, H. S. Teoh via Digitalmars-d wrote:
> Not a bad idea. If we do it right, we could (mostly) avoid user outrage.
> E.g., start with a "soft deprecation" (a compile-time message, but not
> an actual warning, to the effect that byCodeUnit / byCodePoint should be
> used with strings from now on), then a warning, then an actual
> deprecation, then remove autodecoding code from Phobos algorithms
> (leaving only byCodePoint for those who still want autodecoding).

Consider this PR:

https://github.com/D-Programming-Language/phobos/pull/2423

which is blocked because several people do not agree with using byCodeunit.

On 9/25/2014 8:11 PM, Walter Bright wrote:
> Consider this PR:
>
> https://github.com/D-Programming-Language/phobos/pull/2423
>
> which is blocked because several people do not agree with using byCodeunit.
>

I should add that this impasse has COMPLETELY stalled changes to Phobos to remove dependency on the GC.

On 9/25/14, 8:17 PM, Walter Bright wrote:
> On 9/25/2014 8:11 PM, Walter Bright wrote:
>> Consider this PR:
>>
>> https://github.com/D-Programming-Language/phobos/pull/2423
>>
>> which is blocked because several people do not agree with using
>> byCodeunit.
>>
>
> I should add that this impasse has COMPLETELY stalled changes to Phobos
> to remove dependency on the GC.

I think the way to break that stalemate is to add RC strings and reference counted exceptions. -- Andrei