Hacker News Reader

Comment by cortesoft | Hacker News Reader

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?

View on HN

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.

It doesn’t matter which one you do, the methods are literally identical other than the extra s. You can’t pick the wrong one.

This sort of choice is very common in Ruby, you can have different style choices for the same functionality. You can have blocks made with {} or do and end. You can do conditionals in the form of “a if b” or “if b then a”. You can call methods with or without parentheses.

These are all Ruby style choices, and we already have a way to enforce a particular style for a particular project with formatters like rubocop.

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...

> 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.

Why? It's true. It's not even really that hard. My point is nobody is forcing them to accept it.

Because Ruby is nothing without the community around it. If they wanted to make Ruby and don’t care about the people using it, they should go private, shut down the project, or have someone else take over.

It’s wrong to shut down discussion like this with comments like “it’s their code”, “make your own fork”, etc. because Ruby is supposed to be part of the open source community, which implies collaboration, give and take, discussion of pros and cons, etc.

What you are doing is ignoring this major aspect of a programming language and taking this weird anti social stance on it.

I'm not shutting down any discussion, I'm simply stating my opinion. You're free to disagree.

I didn't say to fork it. Do you really not appreciate the difference between rebasing a trivial patch forever, and maintaining a wholesale fork forever?

Crowing on saying “it’s not your code, they can do what they want” is an attempt to do that.

Fork, patch, maintaining your private whatever, that’s not the point, and is a digression.

It's a perfectly valid point, you just disagree. I'm not the one shutting down discussion here.

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.

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.

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

> 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?

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?

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.

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!

When exists? was removed, it was roughly an order of magnitude more popular in Ruby code on Github than exist?. I don't think you can argue from the position of improved readability when, given the choice, it was what the majority of people expected, wrote, and had to change. This change in Ruby is pretty difficult to defend. It didn't really do much but break people without giving them anything in return. It didn't improve maintainability of Ruby itself, it didn't make maintaining Ruby code easier, it didn't advance any secondary goals to improve Ruby.

10 years is not an especially long time period for a software project to be maintained. There's a reason the Linux project is so emphatic that it never breaks user space.

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.

> 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.

Reply on news.ycombinator.com