5 ms·

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 ma

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.

mxey 11mo ago
Actually this is the reason why Win32 is the stable ABI for Linux. https://blog.hiler.eu/win32-the-only-stable-abi/ https://blog.hiler.eu/win32-the-only-stable-abi/
- jcalvinowens 11mo ago
  While I certainly empathize with the author of that article and respect the work they put into debugging it, this is a better explanation of that whole thing: https://maskray.me/blog/2022-08-21-glibc-and-dt-gnu-hash https://maskray.me/blog/2022-08-21-glibc-and-dt-gnu-hash
ryandrake 11mo ago
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 11mo ago
  > 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 11mo ago
    glibc, which has had ABI compatibility for decades?
    - jcalvinowens 11mo ago
      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 11mo ago
        So existing binaries will keep working?
        jcalvinowens 11mo ago
        Not necessarily if you go back far enough to have nss problems :)
- lan321 11mo ago
  Not always without a performance cost which is a no go in projects with very expensive hardware (ahem Cisco).
cortesoft 11mo ago
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?
- jcalvinowens 11mo ago
  Your example could be fixed in your entire codebase with a single sed invocation. While yes, if it were up to me I'd probably just have left the alias, the annoyance for the end user does seem quite minimal... You get to use open source projects for free, and a lot of people do ongoing maintenance on them which you benefit from for free. In return, sometimes you are expected to modify your code which depends on those projects because it makes their maintainer's life easier. Personally, I see that as a very reasonable trade-off.
  - Ferret7446 11mo ago
    The third option is to use things that don't break themselves. One of the many joys of Go is that I can leave personal projects untouched for years and then go back and everything is still working
  - bigstrat2003 11mo ago
    You've moved the goal posts quite a bit from your previous post to this one. Originally, you said that "progress is often only possible by breaking things... it's the only way forward". But the Ruby example that cortesoft provided isn't necessary to make progress. The language would get by just fine without that deprecation (or even without making the change at all). Saying "but it's a trivial change" in response is irrelevant, because you weren't originally trying to justify changes on the basis that they were easy, but that they were necessary.
rustcleaner 11mo ago
>Progress is often only possible by breaking things. It's not a choice, it's the only way forward. See you think it's Progress, but it's actually Regress. It's not a moving forward, but backward. Do not break contract. Do not break API. Do not break muscle memory. Everytime you do, kittens die horribly. Just Say No!

mxey 11mo ago

Actually this is the reason why Win32 is the stable ABI for Linux. https://blog.hiler.eu/win32-the-only-stable-abi/ https://blog.hiler.eu/win32-the-only-stable-abi/

jcalvinowens 11mo ago
While I certainly empathize with the author of that article and respect the work they put into debugging it, this is a better explanation of that whole thing: https://maskray.me/blog/2022-08-21-glibc-and-dt-gnu-hash https://maskray.me/blog/2022-08-21-glibc-and-dt-gnu-hash

ryandrake 11mo ago

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 11mo ago
> 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 11mo ago
  glibc, which has had ABI compatibility for decades?
  - jcalvinowens 11mo ago
    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 11mo ago
      So existing binaries will keep working?
      - jcalvinowens 11mo ago
        Not necessarily if you go back far enough to have nss problems :)
lan321 11mo ago
Not always without a performance cost which is a no go in projects with very expensive hardware (ahem Cisco).

cortesoft 11mo ago

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?

jcalvinowens 11mo ago
Your example could be fixed in your entire codebase with a single sed invocation. While yes, if it were up to me I'd probably just have left the alias, the annoyance for the end user does seem quite minimal... You get to use open source projects for free, and a lot of people do ongoing maintenance on them which you benefit from for free. In return, sometimes you are expected to modify your code which depends on those projects because it makes their maintainer's life easier. Personally, I see that as a very reasonable trade-off.
- Ferret7446 11mo ago
  The third option is to use things that don't break themselves. One of the many joys of Go is that I can leave personal projects untouched for years and then go back and everything is still working
- bigstrat2003 11mo ago
  You've moved the goal posts quite a bit from your previous post to this one. Originally, you said that "progress is often only possible by breaking things... it's the only way forward". But the Ruby example that cortesoft provided isn't necessary to make progress. The language would get by just fine without that deprecation (or even without making the change at all). Saying "but it's a trivial change" in response is irrelevant, because you weren't originally trying to justify changes on the basis that they were easy, but that they were necessary.

rustcleaner 11mo ago

>Progress is often only possible by breaking things. It's not a choice, it's the only way forward. See you think it's Progress, but it's actually Regress. It's not a moving forward, but backward. Do not break contract. Do not break API. Do not break muscle memory. Everytime you do, kittens die horribly. Just Say No!