3 ms·
Rich Hickey has a great talk on this: https://www.youtube.com/watch?v=oyLBGkS5ICk https://www.youtube.com/watch?v=oyLBGkS5ICk Previously discussed: https://new
by Anderkent 10y ago
Rich Hickey has a great talk on this: https://www.youtube.com/watch?v=oyLBGkS5ICk https://www.youtube.com/watch?v=oyLBGkS5ICk
Previously discussed: https://news.ycombinator.com/item?id=13085952 https://news.ycombinator.com/item?id=13085952
- williamle8300 10y agoHe's making good points, but what alternative is he offering?
- qwtel 10y agoCame here to say the same thing. Also related: http://hintjens.com/blog:85 http://hintjens.com/blog:85 "The End of Software Versions"
- Anderkent 10y ago@williamle8300 >He's making good points, but what alternative is he offering? Your comment is dead, but to answer the question - the alternative proposed is to encode the contract of your library in itself, and never break it, only extend it. If you need to change the API, you don't change behaviour or signatures of your functions while preserving the names; you just add a completely new mainspace, while letting people use the old functions if they still have reason to. You don't have to keep actively supporting the old namespaces (i.e. no new bugfixes), but just need to not break the stuff that already worked. There's some scenarios where this is hard - for example it's a web api and supporting it is costing you $$. But for things like that devs are generally aware that what they're consuming might get shut down at some point; so doing a new api, in a new namespace, and shutting down the old one at some point is not completely out of the question.