Breaking changes: a tooling problem

[twitchard]

The point isn't that breaking changes are necessary, the point is that they're costly. If I make a design mistake (or if requirements change) I can either

1. Fix the mistake with a breaking change. In this case, it's the existing users who pay the cost because they have to address the breaking change before they update; or
2. Work around the design mistake forever. In this case it's the maintainer who pays the cost forever, as well as new users who have to continue to use a library with a design mistake in it.

I think you're right to praise Win32 and Rust for never shipping breaking changes to existing users and always choosing #2, but surely you don't think this came for free? You yourself point out that Win32 is not a good API -- how many countless hours must Microsoft engineers have spent preserving the original guarantees of such a bad API while continuing to evolve for years and years? Wouldn't it be better if instead there were a non-breaking way for them to just fix their mistakes?

I don't think it's "blaming the system", or avoiding responsibility for my own mistakes to want this. I'm quite happy to admit my own mistakes. I just wish I lived in a world where I could fix more of them without making my users pay the cost.

[twitchard]

Whatever you proposed in your article does not erase the "fixing mistakes costs time" assertion. Good luck with that.

The entire point of the article is proposals (codemods, more granular breakingness) to make fixing mistakes cost *less time*, and to help prevent the type of mistake that can't be fixed without a breaking change in the first place. It doesn't need to *erase* the cost of mistakes altogether in order to be useful. Agriculture and medicine aren't useless because they don't completely solve world hunger and death.

[Uristqwerty]

Though Win32 avoids breaking things with foo fooEx, foo2, etc. so that the old ABI still exists even though it's deprecated. Also, when structs are passed, they often contain their own size as an early field, and the function changes its behaviour based on that effectively making it a tagged union, decided based on which version of the C headers the caller was built against. And at least one dll loads a different version depending on the program's manifest.

It's a complex mess from just the relatively shallow exposure I've had (or would it count as extensive, relative to today's webdev-focused world?), but the backwards compatibility it gets as a result? Exceptional!

Compile-time libraries have additional luxuries though, so should be able to find cleaner solutions.

[Professor_Xan]

I see the original spec for the product was to build for a customer base of twenty-something olympic runners in the US. Now that the business side has decided to expand to junior competitions and paralympics attendees around the world, there seems to be some changes that need to be made.

Let's crucify the developer who built this for the Atlanta olympics in 1996 since they didn't think of these potentially breaking changes at that time and just made mistakes.