What's wrong with stability, LTS, and not fixing bugs for "compatibility".

[Vladimir Panteleev]

On Thursday, 8 October 2020 at 10:37:22 UTC, FeepingCreature 
wrote:
> Sure, deprecations are good if you can get them,
> but it should never happen that a bug is unfixed because code 
> depends on it.

I assume you're talking about 
https://github.com/dlang/phobos/pull/6716.

Now, it took me a bit of time to figure out what it was that you 
were referring to, exactly. At first, I was just going from the 
description that you provided, which at face value, does seem 
quite wrong, and generally does not describe the way we do things.

But, it's not just "some code" that would be broken by fixing the 
bug there. For a lot of projects, Vibe.d is a dependency that's 
just as important as the standard library.

So, to put those alongside each other, would we ever release a 
version of D which contained a bugfix in the compiler that caused 
the standard library to fail to compile? No, of course not, 
that's absurd. And, it's no different in the Vibe.d case. The 
solution here is to work as a community and fix Vibe.d first, 
which it seems like someone tried doing, though unsuccessfully.

> This is the core point - we don't see our code as "in 
> maintenance mode". We want to write new code, add new features 
> - and nothing is more frustrating than spending days, paid for 
> by the company, to reduce a bug and find out it was 
> deliberately left unfixed, or that the D project left you to 
> sink weeks of effort into a barely-maintained semi-legacy part 
> of the language that you now have to refactor your way out of, 
> cough std.json cough.

I think it would definitely take less than a few days to fix the 
bug in Vibe.d and test that it was, in fact, fixed. Actually, I 
would like to recommend using Digger to make this task even 
easier: In Vibe.d's directory, you can run `digger run 
master+phobos#6716 -- dub --compiler=dmd test` to build and test 
Vibe.d using the changes in your PR.

In any case, including the full details of your grievances would 
help understand your position better. Otherwise, in the spirit of 
game theory, one would be prudent to assume that you are 
exaggerating or misleading through omission, as doing so would 
benefit your case.

> D has *far too few* breaking changes.

This attitude works if you have a finite amount of code to 
maintain, and can take all the time you need to do so. The 
problem occurs as the amount of code you need to maintain grows.

An exaggerated illustration:

2010: you have 10000 lines of code, and it takes 10 hours to 
update.
2015: you have 100000 lines of code, and it takes 100 hours to 
update.
2020: you have 1000000 lines of code, and it takes 1000 hours to 
update.

At a certain point you need to give up on writing new projects, 
because you no longer have time to do so. That time has been 
eaten up by maintaining your existing projects.

Now, if you are in a situation where you maintain a fixed amount 
of code at a time, and are not under any time pressure that would 
disincentivize maintaining code quality, then I see how frequent 
iterations in the language would be welcome. I guess this would 
be the case for R&D or data science, where many programs are 
written, executed once, then deleted. An opposite case would be 
trying to maintain a large and ever-growing number of projects 
and services - not only is there the cost of actually maintaining 
the project, but also the cost of task switching, as each project 
has its own environment and requirements. (That's putting aside 
the adage that while a project is used then it will need to be 
maintained anyway - in my experience, a program really can be 
"finished", at least to some degrees where breaking language 
changes become a considerable nuisance.)

Now, so far D has been rather moderate as far as breaking changes 
go, and I'm very thankful for that (I've done my share of 
complaining to ensure it). If breaking changes were to come as 
often as some people would have liked, I probably would have 
stopped using the language a long time ago.

After all, what's the point of writing code in it if nobody will 
be able to run it in five years?

> And no, big separations between major revisions such as LTS 
> versions are not a solution, they'd be contributing to the 
> problem. You think getting people to upgrade *right now* is 
> hard? Just wait until they have a reasonable expectation to let 
> upgrades lie for actual years. "If something is painful, do it 
> more often"; this aphorism is driven by the experience that 
> doing it less often makes it *more* painful.

You seem to be working on the assumption that everyone writes and 
maintains code in the same manner than you do. This isn't true.

But, regardless of that, when maintaining many projects, it is 
definitely favorable to bulk small updates per project, because 
of the high cost of task switching. So, again, what you wrote is 
only true for your use case.

The rest of your post seems to be based on similar assumptions. 
Kindly consider that different users of D use D differently, and 
thus have different priorities and desires for how the language 
ought to evolve. I would hope that perhaps the tone of your 
future messages will take this into consideration.

> We risk ending up in the D1 (Python 2, Perl 5) case where 
> people don't update at all.

You can still run Python 2 code. I still can just install it and 
run it. Even as the Python foundation stopped maintaining it, 
third-party vendors continue to support it.

You certainly can still run Perl 5 code. I don't really know the 
situation with newer Perl versions, but as I understand a newer 
language version was not in as high demand, and the majority of 
Perl code probably has already been written.

You cannot still run D1 code, at least not easily. Even if you 
can get the compiler binary itself running on your system, odds 
are that the binaries that it will produce will not link or run. 
This, I think, is a silent tragedy: how much code have we 
rewritten in vain just because this time it's based on slightly 
newer technology, and how many times?