3 ms·
Backward compatibility (although there's a spectrum here -- not every breaking change breaks a lot of codebases) is virtually always more important than any fea
by pron 7y ago
Backward compatibility (although there's a spectrum here -- not every breaking change breaks a lot of codebases) is virtually always more important than any feature you can think of. Breaking it might cost a lot of work, and you have to be fairly certain that the cost is more than offset by the benefits from the change, and over a relatively short time period. Given that the cost of breaking changes is easy to perceive, and it's been years if not decades since we've seen programming language features with substantial, tangible benefits, breaking compatibility is almost always the wrong decision.
- ATsch 7y agoThe important thing when breaking backwards compatability is that it can be: - automatically done - isolated within a module As long as these are true, the issues caused by breaking compatability are minimal. It's really the Python model where it's all-or-nothing and you de-facto need to remain compatible with two releases as everyone transitions that's the problem.
- htfy96 7y ago> - isolated within a module This only exists in fairy land. In practice, mixing code from different versions is always the root of subtle bugs and ABI/API mess. For me in front of a big chunk of legacy code, I'd rather wrap them in a separate process and communicate with the remaining part through RPCs if possible.