D has become unbearable and it needs to stop
harakim
harakim at gmail.com
Wed Jul 5 09:50:55 UTC 2023
On Thursday, 8 June 2023 at 15:50:22 UTC, Steven Schveighoffer
wrote:
> On 6/8/23 11:21 AM, Adam D Ruppe wrote:
>> On Thursday, 8 June 2023 at 15:00:04 UTC, Steven Schveighoffer
>> wrote:
>>> In this case, `__traits(getAttributes)` was *wrong*, so a bug
>>> is being fixed. How do we fix bugs like this without using
>>> deprecations and eventual removal?
>>
>> The problem is that there is no easy migration path for the
>> cases where it actually did work just fine. The update
>> required an extra static if branch added to each use for a
>> generic loop.
>
> You mean, it happened to work because of the ordering of the
> overloads? This is the nature of things that do something
> incorrect in the face of ambiguity.
>
> This very much reminds me of the cycle detection problems I
> fixed. Cycles wouldn't get detected, because the algorithm was
> flawed. Fix the algorithm, and now "working" code breaks
> because there actually is a cycle. What do we do about it?
>
> The answer at the time was to introduce a ridiculous
> deprecation system, where I implemented both the correct
> algorithm and the incorrect algorithm, and ran *both*. Then if
> they disagreed, still allow it and print a deprecation message.
>
> In my estimation that is what is happening here -- you are
> relying on a faulty implementation, and that reliance is being
> deprecated.
>
This article has stuck with me over the years:
https://arstechnica.com/gadgets/2022/10/windows-95-went-the-extra-mile-to-ensure-compatibility-of-simcity-other-games/
That is what made Windows successful. It was what made .NET and
Java successful. You can write a program and then you have a
program.
If someone at my work removed a field that I was using from a
database or an optional field from an API, I would flip out. I
have never seen removing "useless" or "ambiguous" features as a
good thing if people are actually using them. If that's the case,
then you have to go out and talk to them and get them to agree
first because you're the one who screwed up. Otherwise, you leave
it as it is.
I see this has been brought up, but why not use compiler flags?
It's a win for everyone. You do have some extra code in the
compiler until the next major version, but refer back to my Sim
City example. That's the price of being a stable tool.
That's it for my reply, but I also have a few questions:
1. If I wanted to be a contributor and understand the dmd
codebase and be able to understand the core team's perspective,
how would I start?
2. How would I join the meeting with the core team where they go
over things?
3. Could the people who want a stable language theoretically
declare one version of it stable and maintain it themselves?
More information about the Digitalmars-d
mailing list