4 ms·

The "I've used for 40 years" argument either amounts to (a) I don't want to learn something new, even if it's improved (which one can respect, but is not a gene

The "I've used for 40 years" argument either amounts to (a) I don't want to learn something new, even if it's improved (which one can respect, but is not a general argument, as others might want to learn something new), or (b) I think the existing versions are the global maxima of such tool design, or close enough not to matter. Because I want to write scripts with the minimal possible support overhead. That means striking a balance between the lowest common denominator, and productivity. Does (for example) ripgrep give me so much extra speed that it's worth committing to the overhead of installing it and keeping it patched up to date on thousands or tens of thousands of machines? With a dozen or more combinations of distro/version? What if the next guy has his own favourite grep replacement? What if we construct a suite of tools and all of them grep in a different way, and someone else a year or 5 years or 10 years later has to debug it? What if two or more of these tools decide that they are the one that gets to replace grep with a symlink to themselves? Having been there and done that it gets very messy, very quickly. Note I'm not saying that grep can't be improved - but I am saying that it would be better to PR those improvements into grep itself rather than creating a new and incompatible thing. Or fork grep and ensure that the improved version is fully backwards compatible.

coldtea 6y ago
>Because I want to write scripts with the minimal possible support overhead. That means striking a balance between the lowest common denominator, and productivity That's not a general argument against their use though. You can write your redistributable scripts in plain sh or bash, as you would, using grep or whatever classic tool. ripgrep and co can still serve for use on the command line, which is what people use them - and for many devs grepping something or find-ing something or ls-ing etc is many times more frequent in everyday cli use than writing some scripts they'll re-distribute. (That's why devs have adopted ZSH and co too -- that it wont be installed or be the default on some random system is not an issue. You still get utility out of it in your main driver machine(s) and/or servers you control) The argument some people make is not (a) "I'd rather stick to more popular POSIX/GNU variants for scripts I want to be redistributable", but, (which seems to me non-sensical) (b) "I'd rather not use something like that, even if it's better/faster/etc, because it wont be available at any random machine I might ocassional login to, or because I can't ALSO use it for when I want to write easily re-distridable scripts".
burntsushi 6y ago
ripgrep author here. > Note I'm not saying that grep can't be improved - but I am saying that it would be better to PR those improvements into grep itself rather than creating a new and incompatible thing. Or fork grep and ensure that the improved version is fully backwards compatible. This kind of thinking is just so incredibly myopic. Like, whoever said compatibility is the most important possible feature? What if "improvements" aren't possible without breaking compatibility? Then what do you do? Like, I get that it's fun to play the "old man yelling at clouds" role. But this takes it to another level. > Because I want to write scripts with the minimal possible support overhead. My goodness. Then just use plain old grep! ripgrep is not grep. It's like a grep. It cannot replace grep in every circumstance. It never will and it was never intended to. Just because someone suggests an alternative doesn't mean they are suggesting it as a replacement for literally every possible use case.

coldtea 6y ago

>Because I want to write scripts with the minimal possible support overhead. That means striking a balance between the lowest common denominator, and productivity That's not a general argument against their use though. You can write your redistributable scripts in plain sh or bash, as you would, using grep or whatever classic tool. ripgrep and co can still serve for use on the command line, which is what people use them - and for many devs grepping something or find-ing something or ls-ing etc is many times more frequent in everyday cli use than writing some scripts they'll re-distribute. (That's why devs have adopted ZSH and co too -- that it wont be installed or be the default on some random system is not an issue. You still get utility out of it in your main driver machine(s) and/or servers you control) The argument some people make is not (a) "I'd rather stick to more popular POSIX/GNU variants for scripts I want to be redistributable", but, (which seems to me non-sensical) (b) "I'd rather not use something like that, even if it's better/faster/etc, because it wont be available at any random machine I might ocassional login to, or because I can't ALSO use it for when I want to write easily re-distridable scripts".

burntsushi 6y ago

ripgrep author here. > Note I'm not saying that grep can't be improved - but I am saying that it would be better to PR those improvements into grep itself rather than creating a new and incompatible thing. Or fork grep and ensure that the improved version is fully backwards compatible. This kind of thinking is just so incredibly myopic. Like, whoever said compatibility is the most important possible feature? What if "improvements" aren't possible without breaking compatibility? Then what do you do? Like, I get that it's fun to play the "old man yelling at clouds" role. But this takes it to another level. > Because I want to write scripts with the minimal possible support overhead. My goodness. Then just use plain old grep! ripgrep is not grep. It's like a grep. It cannot replace grep in every circumstance. It never will and it was never intended to. Just because someone suggests an alternative doesn't mean they are suggesting it as a replacement for literally every possible use case.