3 ms·

And then you have a possibly confusing situation where you have two programs that do essentially the same thing, but one is faster, and the other one is possibl

by jraph 4y ago

And then you have a possibly confusing situation where you have two programs that do essentially the same thing, but one is faster, and the other one is possibly not provided by default. As a user, in cases it matters, you'd have to know the issue and bother installing the new program. This is worse. As developers, I think it's our duty to make life of users simpler, even if it makes our lives a bit more complicated. I'd argue that's what we are here for. I guess there's no ideal solution. But I think the "new" program does what the first one did better, and does not do anything worse. We are talking about a program that still under 1000 lines of code and that's not getting new features every month, or at all anyway, so maintainability does not seem to be a big issue? I see the reasoning but I don't see any actual practical drawback to have improved the original program directly in this specific case. I don't see any advantages of keeping "yes" dead simple neither. The new version is still pretty much readable and the extra time it takes to read it and modifying without doing mistakes seems worth the advantages.

dncornholio 4y ago
> And then you have a possibly confusing situation where you have two programs that do essentially the same thing My point is, I'd never thought of using yes for this purpose. So in this case, you could make a command called 'outputsomethingfast' and you could make a command called yes, that internally calls 'outputsomethingfast --output=yes' or something like that. To me this is way more logical, and more in line with the Linux philosophy, right?
- jraph 4y ago
  I guess. I don't like the name "yes" and I think we would have been better off with a more general name since the command is general, but now it's there, so… However, this is independent from this optimization, "yes" already had this feature of outputting anything, I think? But I expect this kind of accident to happen in any working system that has been long enough. This seems unavoidable. So we'd better put up with this kind of mess probably.

by jraph 4y ago

dncornholio 4y ago

> And then you have a possibly confusing situation where you have two programs that do essentially the same thing My point is, I'd never thought of using yes for this purpose. So in this case, you could make a command called 'outputsomethingfast' and you could make a command called yes, that internally calls 'outputsomethingfast --output=yes' or something like that. To me this is way more logical, and more in line with the Linux philosophy, right?

jraph 4y ago
I guess. I don't like the name "yes" and I think we would have been better off with a more general name since the command is general, but now it's there, so… However, this is independent from this optimization, "yes" already had this feature of outputting anything, I think? But I expect this kind of accident to happen in any working system that has been long enough. This seems unavoidable. So we'd better put up with this kind of mess probably.