Windows experience is atrocious

[Paolo Invernizzi]

On Monday, 24 July 2023 at 19:24:56 UTC, max haughton wrote:
> On Monday, 24 July 2023 at 18:43:02 UTC, Walter Bright wrote:
>> On 7/24/2023 12:22 AM, Paolo Invernizzi wrote:
>>> You know, I'm in the "deprecate and clean-up the language" 
>>> camp since forever ...
>>
>> I am, too, but it clearly does not work for us.
>
> Don't mistake the destination with the method of getting there 
> e.g. a few deprecations aren't actually stopping people from 
> using D, it's just discouraging having a violent torrent of 
> dip1000 deprecations which would (for us) require days or weeks 
> of engineering-time to get around (if even possible) because 
> the underlying model just isn't able to express the patterns 
> that make D productive (as opposed to merely expressive).
>
> For deprecations that are either syntactic or a direct 
> substitution, the compiler should just fix it for you - clang 
> and gcc (to a lesser extent) can both do this, e.g. the 
> body=>do change - regardless of the justification the compiler 
> should just parse it and fix it (or emit a diff, etc etc).

I agree that a tool like python 2to3 could be useful, but the 
python experience seems to point out that it was pretty a failure 
overall.

That remind me of the Phobos v2/v3 work about the removing of 
auto decoding: the party proposing an "let's go with copy/past" 
loose the race, but the party proposing "let's go with a cleaver 
super-engineered way of sharing code" stalled ... sometime the 
best way to move forward is just the simplest one.

I sympathize with you about the torrent of dip1000 deprecations, 
our code was also hit by them. But if dip1000 is an added value 
to the codebase, that engineering-time is a good spent time I 
guess. The point is, aren't the actual compiler switches enough 
to let you choose when to do the transition of the codebase? 
What's the problem about that?

We have much more difficulties in reading some "modern" D code, 
full of scope/ref/in/const/auto ... plus @live ... plus care if 
scope is before or after, plus yes here scope is doing nothing, 
etc etc. Maybe because we use python a lot also (you know, 
machine learning ....) but simplicity, and "explicit is better 
than implicit" is a value.

I understand your point, but to me the need to explain a 
programmer, "yes dude, 'in ref' was an ancient way of doing 'in', 
just keep ALSO that in mind" is a strategic error. Stepping back 
from the current deprecation mechanics is a pity.

/Paolo