| ▲ | dec0dedab0de 4 hours ago |
| Please do the opposite. Let all deprecation warnings last at least a decade, just include in the warning that it is not maintained. But more to the point, go out of your way to avoid breaking backwards compatibility. If it's possible to achieve the same functionality a different way, just modify the deprecated function to use the new function in the background. My biggest problem with the whole static typing trend is that it makes developers feel empowered to break backwards compatibility when it would be trivial to keep things working. edit:
Not that it is always trivial to avoid breaking backwards compatibility, but there are so many times that it would be. |
|
| ▲ | zahlman 30 minutes ago | parent | next [-] |
| > My biggest problem with the whole static typing trend is that it makes developers feel empowered to break backwards compatibility when it would be trivial to keep things working. I don't see the connection you're drawing here. |
| |
| ▲ | ljm 12 minutes ago | parent [-] | | Rather, static typing empowers backwards compatibility, right? Because it lays out the contract you have to meet on the interface. No contract? No enforced compatibility. |
|
|
| ▲ | jkubicek 4 hours ago | parent | prev | next [-] |
| > just include in the warning that it is not maintained. I'm convinced this isn't possible in practice. It doesn't matter how often you declare that something isn't maintained, the second it causes an issue with a [bigger|more important|business critical] team it suddenly needs become maintained again. |
| |
| ▲ | tux3 4 hours ago | parent | next [-] | | And here's where your business can contact me to talk about a support contract. If it's important, they'll pay. Often you find out it wasn't that important, and they're happy to figure it out. | | |
| ▲ | nisegami 3 hours ago | parent [-] | | It sounds like you're imagining open source whereas the comment you're replying to is imagining more intra-company dependencies. | | |
| ▲ | mbreese 39 minutes ago | parent [-] | | I think deprecation in intra-company code is a completely different beast. You either have a business case for the code or not. And if something is deprecated and a downstream project needs it, it should probably have the budget to support it (or code around the deprecation). In many ways, the decision is easier because it should be based on a business use case or budget reason. | | |
| ▲ | zamadatix 12 minutes ago | parent [-] | | The business case is the easy part, the quagmire is in getting the different teams to agree who should support the business case, why it's more important than the business cases they wanted to spend cycles on instead, and how much of the pie supporting it takes on the budget side. Less so when the place is small enough everyone knows everyone's name, more so when it's large enough they really don't care what your business case is much even though it'd be 10x easier to support from their side instead of another. |
|
|
| |
| ▲ | taeric 4 hours ago | parent | prev | next [-] | | I don't know that I see why/how this is a problem? You would do the same with any other thing in your life? More, in many things, we have actively decided not to do something anymore, and also highly suggest people not mess with older things that did use it. See asbestos. Removing it from a building is not cheap and can be very dangerous. | |
| ▲ | dietr1ch 3 hours ago | parent | prev [-] | | It also keeps slowing down development as getting a green global compile will make you still update "deprecated" functions that face breaking API changes. |
|
|
| ▲ | mxey 3 hours ago | parent | prev | next [-] |
| > Not that it is always trivial to avoid breaking backwards compatibility, but there are so many times that it would be. In this case it was 2 functions with 1 line of code each. https://github.com/urllib3/urllib3/pull/3732/files |
| |
| ▲ | Spivak an hour ago | parent [-] | | Wow. Why even remove it? It's just the thinnest wrapper around the dict and since the dict is now part of the public API these methods will work forever unmodified. |
|
|
| ▲ | shadowgovt an hour ago | parent | prev | next [-] |
| As with all things, this can be pushed too far. Microsoft was suffering a maintainability crisis before the transition to Windows XP; their years of bending the API to support customers (which, in the short run, did keep customers to their benefit) was making for a fairly unmaintainable mess of an API surface that then screamed under the strain when the Internet era hit and all those open, under-observed APIs became potential worm attack vectors. |
|
| ▲ | ryandrake 3 hours ago | parent | prev [-] |
| One thing I've always hated was this idea of "bitrot." That software just spontaneously stops working after time and loses backwards compatibility. Like it's some force of nature. It's not a force of nature. Bitrot is: many software developers deliberately choosing to break backward compatibility in very small ways over and over. Software written in 1995 should still work today. It's digital. It doesn't rot or fall apart. It doesn't degrade. The reason it doesn't work today is decisions that platforms and library maintainers deliberately made. Like OP. Deprecate like you mean it. That's a choice! If we want to solve bitrot, we need to stop making that choice. |
| |
| ▲ | jcalvinowens 3 hours ago | parent | next [-] | | Progress is often only possible by breaking things. It's not a choice, it's the only way forward. We have to optimize for the future being better, even if it makes the present a little worse occasionally. This is a huge reason why open source projects are often so much more successful than corporate clones: they actually iterate and innovate, something corporate america has forgotten how to do. | | |
| ▲ | cortesoft a minute ago | parent | next [-] | | Some deprecations are required to make progress. Many others aren't, and those are the most frustrating. For example, ruby deprecated the `File.exists?`, and changed it to `File.exist?`, because enough people felt that the version with the `s` didn't make sense grammatically (which I disagree with, but that is not germane to my point). For a long time, you would get warning that `exists?` was deprecated and should be replaced by `exist?`.... but why? Why couldn't they just leave `exists?` as an alias to `exist?`? There was not cost, the functions are literally identical except for one letter. While the change was trivial to fix, it added annoyance for no reason. Although, luckily for me, with Ruby I can just make exists? an alias myself, but why make me do that?!? What is the point of removing the method that has been there forever just because you think the s is wrong? | |
| ▲ | ryandrake 3 hours ago | parent | prev | next [-] | | It's absolutely a choice. All software can progress while preserving backward compatibility for existing users. It's not always easy, but it's never impossible. | | |
| ▲ | jcalvinowens 3 hours ago | parent [-] | | > All software can progress while preserving backward compatibility for existing users That's an incredibly ignorant claim. Just run "git log" in glibc, it won't take you very long to prove yourself wrong. | | |
| ▲ | mxey 3 hours ago | parent [-] | | glibc, which has had ABI compatibility for decades? | | |
| ▲ | jcalvinowens 3 hours ago | parent [-] | | There have been plenty of build breaking changes over the past couple decades, generally they happen for very good reasons and only affect niche usecases. | | |
|
|
| |
| ▲ | mxey 3 hours ago | parent | prev [-] | | Actually this is the reason why Win32 is the stable ABI for Linux. https://blog.hiler.eu/win32-the-only-stable-abi/ | | |
| |
| ▲ | shadowgovt an hour ago | parent | prev [-] | | God, would I hate to be programming now the way I had to program in 1995. Granted, modern coroutines do bring up some nostalgic feel for the days I had to support cooperative multitasking... |
|
