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 2 days ago | parent | next [-]

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

▲

cortesoft 2 days ago | parent | prev | next [-]

> 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 2 days ago | parent [-]

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 2 days ago | parent [-]

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 a day ago \| parent [-]
		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!

▲

bigstrat2003 2 days ago | parent | prev [-]

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 2 days ago \| parent [-]
		> 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.