The reality is that you have to be sensible and balanced.<p>You can't keep BROKEN functions "because people rely on them", but you can't suddenly make a minor release (e.g.: from 2.3.4 to 2.3.5) completely changing the semantic of a feature you expose.<p>You need to:<p>- Avoid changing APIs just for the sake of change.<p>- Announce breaking changes.<p>- Document how users are intended to migrate from your old API to the new one.<p>Very large projects like Django do things like:<p>- v2.0: Adds a new API, but keeps the old one<p>- v3.0: Removes the old API.<p>This gives consumers of the API plenty of time and margin to experiment with both and move on.<p>If a single release changes too many things, it's very hard for a developer to upgrade, since they have a completely broken codebase, and need to fix multiple breakage at once.
I'd say nonsense.<p>Backwards compatibility is better than any other option. From time to time you need to provide new, clean versions of old APIs and that's it. Things get deprecated (as in "best not to use this unless you are aware of the consequences". Aggregate over time, don't replace. Garbage collect when not reachable. This works for APIs as weel as for functional programming data structures.<p>Clojure(script) approach is a good example of how this can work beautifully well in practice. Java also used to be reasonably good in this regard. Javascript (the language) is good. Javascript (the ecosystem) is criminally bad.
IBM, on zSeries mainframes and z/OS, has even bigger commitment to backward compatibility than Microsoft.<p>Yes, it might take a long time to fix some mistakes, but usually, you get another better API added that doesn't have the old flaws. Over time, system accrues a byzantine set of features.<p>Unfortunately, end result of these policies is that nobody wants to develop for those systems anymore. So the (dharmic?) wheel is reinvented elsewhere.
I'm reminded of a story told by Joel Sposky about Simcity on Windows 95.<p>The DOS/Win3.x version of SimCity had a bug where it used memory after freeing it, which worked fine on DOS since the memory didn't get reallocated. The Windows 95 team found that it was broken, and so they added code to <i>detect whether SimCity was running</i>, and if so ran the memory manager in a special mode that didn't release memory immediately.
Yeah this pushes developers of the platform between a rock and a hard place.<p>It's ok to keep backwards compatibility, but the API needs to also move forward and get the bugs ironed out. The worse case is when developers start to rely on the bugs for their workarounds (yes, please, do test your API before releasing)<p>Maybe shims are the way to go. Instead of keeping old functionality around you make a shim that only talks to the new API. And that will serve as a guide (because if you're taking functionality out that's usually not good). I've seen a couple of cases where the deprecated API was much more straight forward and easy to use than the new one. Not good.
It may be possible to create a programming language where you express your intent at enough of a high level that the code can be automatically refactored into using new APIs.
lol, indeed. That's the point of engineering, to fence and mitigate errors - both current and future, isn't it?<p>The future part especially makes it a hard problem.
Yes.<p>That's the point.<p>No it's not a real problem.<p>Want to fix your mistakes? Make a fork and try harder next time.<p>It's such a presumption to assume that I, as the user, gives a crap about what you think are your mistakes or not, or how important they are to you, or how much cleaner the code will be when you fix it.<p>If you create work for me.<p>I will walk.