Earlier quoted context omitted.
Hear hear! I've had a sed book on my shelf for years and I've used it more than once, but 99% of the time I end up giving up on sed and using a GUI-based tool instead of trying to concoct the cryptic lines given above as examples. I absolutely would rather use the clean interface of replace, written in JavaScript or anything else, than to memorize that steaming pile of cruft.
Two reasons why it's better to memorize the cruft: 1. You can pipe find/sed/grep/cut/awk/whatever to other utils. Today you might be replacing, tomorrow you might be analyzing text logs, and the more core utils you learn the more things you can do with them. 2. When you're ssh'd into another box that doesn't have that spiffy replace utility, now you don't know how to do an inline replace.
Fair.
This boils down to an individual's needs. I think most people in a position to be making this choice are fairly well aware of what's possible with standard nix CLI tools, and can decide whether or not to invest the time to learn them.
In my experience the ROI for nix wizardry is fairly high at first, but begins tapering off. There are a half dozen or so command chains I use daily without which I could hardly see myself working, and the rest I may not touch for weeks or months on end. YMMV.
> 2. When you're ssh'd into another box that doesn't have that spiffy replace utility, now you don't know how to do an inline replace.
It doesn't make sense to optimize a workflow around an edge case. You don't often hear this brought up as an argument against dotfiles, key bindings, vim plugins or what have you.