4 ms·

But how can you really be sure you're not going to break something? There might be software that accidentally depends on timing, say, or the order of items in a

But how can you really be sure you're not going to break something? There might be software that accidentally depends on timing, say, or the order of items in a list or some other undefined behavior that you assume you're free to change but software authors didn't realize was unstable. A lot of programming is done by trial and error rather than reading the manual.

rwmj 6y ago
We're careful to specify what is defined behaviour (basically what we document) and the rest is not. Of course bugs exist both in our libraries and our callers, and we fix those, and work with callers if they had depended on the buggy behaviour, but that's a genuine case where the caller must fix their code. Fixing a bug is miles different from unnecessary breaks in APIs.
- exporectomy 6y ago
  Nothing wrong with having good intentions but if you fixing a bug breaks someone else's software then they still have to fix their software no matter who's fault it is. Repeat for all their other dependencies and they have an endless stream of annoying little new bugs to fix. I work on software that has dependencies probably over a decade old. They have that long history of proving themselves to be perfectly good so there's no upside to updating them and only a tedious bug-hunting downside. One of them was already abandoned when I started using it but it still had an active community of users who agreed that it was perfectly usable without any more updates despite having the odd minor bug or limitation. That's where I hope software can end up - "finished" then sit around being stable and useful until it becomes obsolete. Other than security, I think people have a psychological problem with knowing there won't be any more updates. They always hope the next update might fix the bug that bothers them or add the feature they want. But often that never happens and they're just being strung along on hope and dripfed a few treats every now and then.

rwmj 6y ago

We're careful to specify what is defined behaviour (basically what we document) and the rest is not. Of course bugs exist both in our libraries and our callers, and we fix those, and work with callers if they had depended on the buggy behaviour, but that's a genuine case where the caller must fix their code. Fixing a bug is miles different from unnecessary breaks in APIs.

exporectomy 6y ago
Nothing wrong with having good intentions but if you fixing a bug breaks someone else's software then they still have to fix their software no matter who's fault it is. Repeat for all their other dependencies and they have an endless stream of annoying little new bugs to fix. I work on software that has dependencies probably over a decade old. They have that long history of proving themselves to be perfectly good so there's no upside to updating them and only a tedious bug-hunting downside. One of them was already abandoned when I started using it but it still had an active community of users who agreed that it was perfectly usable without any more updates despite having the odd minor bug or limitation. That's where I hope software can end up - "finished" then sit around being stable and useful until it becomes obsolete. Other than security, I think people have a psychological problem with knowing there won't be any more updates. They always hope the next update might fix the bug that bothers them or add the feature they want. But often that never happens and they're just being strung along on hope and dripfed a few treats every now and then.