3 ms·

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 c

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.
  - jcalvinowens 11mo ago
    > Saying "but it's a trivial change" in response is irrelevant Of course it's relevant. It's a laughably trivial example compared to the other one in this thread.
- cortesoft 11mo ago
  > Your example could be fixed in your entire codebase with a single sed invocation I also have to hope all the dependencies I use did that, too. But my real question is why? Why make me do it at all?
  - jcalvinowens 11mo ago
    Because they wanted to, and it's their project. Part of being an adult is accepting you won't agree with every decision that affects you. You were free to show up and argue against it, as was anyone else. Did you?
    - cortesoft 11mo ago
      Ok, I think you are arguing against something I am not saying. I am not arguing that they don’t have the RIGHT to make the change, or that they owe me personally anything. I am not even THAT mad. I still love Ruby the most of any language, and generally think they make the right decisions. I am simply annoyed by this decision. And yes, I argued against this change when it was first proposed (as did many others). They obviously were not convinced. Again, I am not arguing that they should be FORCED to do what I want, or that they did something shady or nefarious by making this change. I am not asking for any remedy. I am simply saying I disagree with this type of change (changing a method name because some people feel the new name makes more grammatical sense, but not changing the method itself at all). The reason I commented was because this is not a “we have to deprecate things for progress” situation. They aren’t limited in any way by the current method, the syntax isn’t cumbersome (and isn’t changing), there is no other capability that is held back by having to maintain this method. It is literally just “I read it as asking ‘Does this file exist?’ rather than asking ‘This file exists?’” Again, they are obviously free to disagree with me, which they do. I am simply arguing that we shouldn’t break syntax just because you like the way it reads better without an s. And I am asking for someone who disagrees with me (you) to explain why it is worth making this type of change.
      - jcalvinowens 11mo ago
        It's important for code to be clean and free of old cruft, even if that means old code has to change. Readibility is one of the most important aspects of maintainable code. Arguably more important than testing, IMHO. This is another reason open source solutions so consistently win over corporate ones, the open source world understands this. Are there changes I disagree with? Of course. But I'd rather live in a world that moves forward and occasionally breaks me, than one where I have perfect compatibility but am stuck on code lacking the new innovations my competitors benefit from. The whole idea behind deprecating things is to give people time to make the changes before they become breaking. I went and looked: exists? was marked as deprecated in 2013 and removed in 2022. That's enormously generous, my previous comparison with the disttools debacle in python was inaccurate. You had a decade!
coryrc 11mo ago
Imagine I am new to Ruby. I go looking to figure out if a file exists. Or I get a list of available methods from the file object. Now I have to research both `exist?` and `exists?` to figure out if I should be choosing one or the other. Now multiply that by.... every past history of every API and it makes adopting something really difficult as a newcomer. aka Common Lisp.
- jcalvinowens 11mo ago
  I'm not defending the Ruby decision, I literally said I wouldn't have done it. It reminds me of the disttools removal from python, which was also not something I'd have done nearly so aggressively if it were up to me. Multiple distros have patched it back in. But it wasn't up to me. It's not my project. I'm using somebody else's project, and at the end of the day it's their decision, because they own it. Unless it's impossible to work around, I feel like I have to either respect that, or switch to an alternative. You're free to maintain a patch on top of Ruby to add the alias and run that on your machines, btw. It would probably be very simple, although certainly not as simple as aforementioned sed command...
  - cortesoft 11mo ago
    Of course it is their decision, and they don’t OWE me an explanation. But this is a discussion forum, and I am asking for people who agree with the decision to explain why they agree. Again, they don’t have to answer me if they don’t want to. I am just saying, “if anyone knows an argument for this type of change, I would love to hear it” Saying they don’t have to explain their reasoning is true but not really relevant to our conversation. I am not asking THEM, I am asking HN readers.
  - kelipso 11mo ago
    > You're free to maintain a patch on top of Ruby to add the alias and run that on your machines, btw. Comments like this are honestly just asshole-ish.
    - jcalvinowens 11mo ago

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.
- jcalvinowens 11mo ago
  > Saying "but it's a trivial change" in response is irrelevant Of course it's relevant. It's a laughably trivial example compared to the other one in this thread.
cortesoft 11mo ago
> Your example could be fixed in your entire codebase with a single sed invocation I also have to hope all the dependencies I use did that, too. But my real question is why? Why make me do it at all?
- jcalvinowens 11mo ago
  Because they wanted to, and it's their project. Part of being an adult is accepting you won't agree with every decision that affects you. You were free to show up and argue against it, as was anyone else. Did you?
  - cortesoft 11mo ago
    Ok, I think you are arguing against something I am not saying. I am not arguing that they don’t have the RIGHT to make the change, or that they owe me personally anything. I am not even THAT mad. I still love Ruby the most of any language, and generally think they make the right decisions. I am simply annoyed by this decision. And yes, I argued against this change when it was first proposed (as did many others). They obviously were not convinced. Again, I am not arguing that they should be FORCED to do what I want, or that they did something shady or nefarious by making this change. I am not asking for any remedy. I am simply saying I disagree with this type of change (changing a method name because some people feel the new name makes more grammatical sense, but not changing the method itself at all). The reason I commented was because this is not a “we have to deprecate things for progress” situation. They aren’t limited in any way by the current method, the syntax isn’t cumbersome (and isn’t changing), there is no other capability that is held back by having to maintain this method. It is literally just “I read it as asking ‘Does this file exist?’ rather than asking ‘This file exists?’” Again, they are obviously free to disagree with me, which they do. I am simply arguing that we shouldn’t break syntax just because you like the way it reads better without an s. And I am asking for someone who disagrees with me (you) to explain why it is worth making this type of change.
    - jcalvinowens 11mo ago
      It's important for code to be clean and free of old cruft, even if that means old code has to change. Readibility is one of the most important aspects of maintainable code. Arguably more important than testing, IMHO. This is another reason open source solutions so consistently win over corporate ones, the open source world understands this. Are there changes I disagree with? Of course. But I'd rather live in a world that moves forward and occasionally breaks me, than one where I have perfect compatibility but am stuck on code lacking the new innovations my competitors benefit from. The whole idea behind deprecating things is to give people time to make the changes before they become breaking. I went and looked: exists? was marked as deprecated in 2013 and removed in 2022. That's enormously generous, my previous comparison with the disttools debacle in python was inaccurate. You had a decade!

coryrc 11mo ago

Imagine I am new to Ruby. I go looking to figure out if a file exists. Or I get a list of available methods from the file object. Now I have to research both `exist?` and `exists?` to figure out if I should be choosing one or the other. Now multiply that by.... every past history of every API and it makes adopting something really difficult as a newcomer. aka Common Lisp.

jcalvinowens 11mo ago
I'm not defending the Ruby decision, I literally said I wouldn't have done it. It reminds me of the disttools removal from python, which was also not something I'd have done nearly so aggressively if it were up to me. Multiple distros have patched it back in. But it wasn't up to me. It's not my project. I'm using somebody else's project, and at the end of the day it's their decision, because they own it. Unless it's impossible to work around, I feel like I have to either respect that, or switch to an alternative. You're free to maintain a patch on top of Ruby to add the alias and run that on your machines, btw. It would probably be very simple, although certainly not as simple as aforementioned sed command...
- cortesoft 11mo ago
  Of course it is their decision, and they don’t OWE me an explanation. But this is a discussion forum, and I am asking for people who agree with the decision to explain why they agree. Again, they don’t have to answer me if they don’t want to. I am just saying, “if anyone knows an argument for this type of change, I would love to hear it” Saying they don’t have to explain their reasoning is true but not really relevant to our conversation. I am not asking THEM, I am asking HN readers.
- kelipso 11mo ago
  > You're free to maintain a patch on top of Ruby to add the alias and run that on your machines, btw. Comments like this are honestly just asshole-ish.
  - jcalvinowens 11mo ago