A strong commitment to backwards compatibility means keeping your mistakes
1–10 of 62 posts
Re: A strong commitment to backwards compatibility means keeping your mistakes
#2IBM, on zSeries mainframes and z/OS, has even bigger commitment to backward compatibility than Microsoft.
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.
Unfortunately, end result of these policies is that nobody wants to develop for those systems anymore. So the (dharmic?) wheel is reinvented elsewhere.
Re: A strong commitment to backwards compatibility means keeping your mistakes
#3Idealism vs money and staving off legal issues. Heh.
Re: A strong commitment to backwards compatibility means keeping your mistakes
#4Yes.
That's the point.
No it's not a real problem.
Want to fix your mistakes? Make a fork and try harder next time.
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.
If you create work for me.
I will walk.
Re: A strong commitment to backwards compatibility means keeping your mistakes
#5IBM, on zSeries mainframes and z/OS, has even bigger commitment to backward compatibility than Microsoft. 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. Unfortunately, end result of these policies is that nobody wants to develop for those systems anymore. So the (dharmic?) wheel…
> Unfortunately, end result of these policies is that nobody wants to develop for those systems anymore.
Is that the main reason? I always assumed "I can't buy these machines for less than a year's salary" was the major difficulty onboarding.
Re: A strong commitment to backwards compatibility means keeping your mistakes
#6IBM, on zSeries mainframes and z/OS, has even bigger commitment to backward compatibility than Microsoft. 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. Unfortunately, end result of these policies is that nobody wants to develop for those systems anymore. So the (dharmic?) wheel…
> Unfortunately, end result of these policies is that nobody wants to develop for those systems anymore. Is that the main reason? I always assumed "I can't buy these machines for less than a year's salary" was the major difficulty onboarding.
That's an interesting question. In the late 90s, IBM had a competition in the same S/390 architecture, with Fujitsu and Hitachi mainframes. These could compete with IBM on price, so I don't think this would be a problem. It's hard to discern cause and effect here - maybe mainframes are expensive because IBM held to them and eventually became a monopoly.
But I think the claims "mainframes are legacy and complicated" came sooner than that, and that was the real cause why people wanted to avoid them.
Compare this with Unix in the early 90s, it had a very same problem, being somewhat expensive and inaccessible, even for home PCs. But this changed with Linux... and in general, home PCs changed the expectation of the onboarding, before that, the fact that you cannot buy a computer at home, didn't present a significant obstacle in employee training.
I am almost wondering if any complex enough system is long-term commercially viable. Closed-sourcing somewhat inevitably means bleeding mindshare.
Re: A strong commitment to backwards compatibility means keeping your mistakes
#7Earlier quoted context omitted.
> Unfortunately, end result of these policies is that nobody wants to develop for those systems anymore. Is that the main reason? I always assumed "I can't buy these machines for less than a year's salary" was the major difficulty onboarding.
That's an interesting question. In the late 90s, IBM had a competition in the same S/390 architecture, with Fujitsu and Hitachi mainframes. These could compete with IBM on price, so I don't think this would be a problem. It's hard to discern cause and effect here - maybe mainframes are expensive because IBM held to them and eventually became a monopoly. But I think the claims "mainframes are legacy and complicated" c…
> if any complex enough system is long-term commercially viable
I don't think you can determine this from first principles without taking the wider world into account. Things like the electricity grid or car manufacturing seem to have managed just fine over long periods of time, despite (almost) nobody having their own coal power plant or cylinder boring machinery. There are some niches in software that will survive just fine even as closed source software, SAP, Salesforce and industrial control systems spring to mind.
Re: A strong commitment to backwards compatibility means keeping your mistakes
#8lol, indeed. That's the point of engineering, to fence and mitigate errors - both current and future, isn't it?
The future part especially makes it a hard problem.
Re: A strong commitment to backwards compatibility means keeping your mistakes
#9Earlier quoted context omitted.
That's an interesting question. In the late 90s, IBM had a competition in the same S/390 architecture, with Fujitsu and Hitachi mainframes. These could compete with IBM on price, so I don't think this would be a problem. It's hard to discern cause and effect here - maybe mainframes are expensive because IBM held to them and eventually became a monopoly. But I think the claims "mainframes are legacy and complicated" c…
> if any complex enough system is long-term commercially viable I don't think you can determine this from first principles without taking the wider world into account. Things like the electricity grid or car manufacturing seem to have managed just fine over long periods of time, despite (almost) nobody having their own coal power plant or cylinder boring machinery. There are some niches in software that will survive…
>electricity grid or car manufacturing
electricity grid became a commodity (I believe arguably car manufacturing did as well), not sure if the theory isn't that any system that lasts over the long term will either become commoditised or cease to be commercially viable.
Re: A strong commitment to backwards compatibility means keeping your mistakes
#10I'd say nonsense.
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.
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.