[jongala]

To my (naive) eyes, your examples act as a compelling advertisement for her library.

The sed/xargs/etc. examples look increasingly like impossible-to-memorize line noise to me, while the --include, --exclude etc. options in `replace` are comprehensible and seem to follow standard command line argument practices.

Again, this is from a very entry-level unix tools perspective, but there it is.

It also seems to me that reimplementing things with the stated goal to make them easier to use has to be one of the best justifications around, no?

I hope I sound as respectful here as you did in your comment -- I certainly appreciated seeing a clear response to her library, so thanks for that.

[mrb]

Impossible to memorize? I wrote all these examples from memory. I tested them in a shell and had a single error (sed -ir needed to be changed to sed -ri because -i takes a glued "suffix" argument). I really don't think it is that hard to memorize the basic find/xargs options. You only have to memorize them once in your lifetime. They are a basic cornerstone of a Unix skillset. By comparison, I often forget the custom syntax of my custom scripts I wrote years ago.

[confluence]

I can write complex vector math in C from memory - doesn't mean everyone needs to be able to do it.

That replace library does what it's supposed to do - it replaces shit easily.

Don't like it - don't use it.

If people want to do more - then they'll figure it out for themselves. For everyone who already knows more - eat some humble cake.

[lobotryas]

>Don't like it - don't use it.

This is a false dilemma and completely misses the point. The replace library was written by a person who either never heard of or never learned how to use SED. Just because they created their own hack as a workaround doesn't mean it's the right thing to do.

[yusefnapora]

Why would you assume that, because they wrote an alternative to an existing tool, they don't know how to use it? Perhaps she just doesn't like sed, or would like to use the replace functionality in an environment where it's not clear ahead of time whether GNU or BSD sed are available. Or any of a number of reasons. Your assumption that she must be ignorant to have created her own solution is just as boorish as the original tweets, imo. Was tmux written by a person who had "either never heard of or never learned how to use" GNU screen? What about GNU itself? Why bother when UNIX already exists? People have lots of reasons for writing software, and deciding for them whether it's "the right thing to do" because some other software already exists is absurd.

[pekk]

Just because it does something that you like to do a different way, doesn't mean it is hurting anyone for someone to write it.

By this logic, there is no way for beginners to write much of anything since there are existing implementations of almost any idea, and it should be disallowed ever to make a new thing which could replace any old thing.

[barkingcat]

If you take a look at the readme, the first commit back in 2011 says this:

"It's similar to sed but there are a few differences:" and then goes along to list out the differences.

I would expect this person to 1) have heard of and 2) have learned to use sed in order to write a tool that is similar but has slight differences in syntax to sed.

[tsahyt]

There is no wrong thing to do when writing tools for personal productivity, as OP clearly stated. If it works, it works. If they decide to open source it, that's great. Maybe someone has use for it. The end.

[PeterisP]

If a program is nontrivial to learn and use (as the sed examples shown in mrb's post illustrate) then a good solution is to make a better, more easily usable tool tan sed.

As for editors - there is a niche for emacs and there is a niche for notepad. If a program is weaker on some aspects but clearly superior in another aspect, then it has a valid niche and making it really is the 'right thing to do'. Usability/discoverability is a very important aspect of software, and sed is a bit lacking there.

[Legion]

> Just because they created their own hack as a workaround doesn't mean it's the right thing to do.

Are you honestly at HackerNews posting that someone hacking together some code to scratch their own itch is not "the right thing to do"?

[confluence]

Right is arbitrary.

[chris_wot]

Please don't follow up a false dilemma with circular reasoning.

[chris_wot]

Guess you've never heard the KISS principle. So what if you can remember arcane commands? If there was a "replace" program, I'd be sure to use it. I understand all of these as well, trying to pipe them together or to use a "replace" command - I'd choose replace every time.

[te_chris]

It would appear they're the basic cornerstone of YOUR unix skill set. I spend all day in *nix, I didn't understand everything you wrote there.

[pretoriusB]

>Impossible to memorize? I wrote all these examples from memory.

Yes. And people can site Pi to the 10.000 digit. Doesn't make it any less useless.

[redbad]

The arguments to common UNIX commandline tools like sed or xargs are without doubt going to be longer-lived than the arguments to your helper script, likely even longer than the language your helper script was written in, and maybe even longer than the idioms and philosophies you had in mind when you were building your tool(s).

Calling the basic operation of these cornerstones "useless" speaks more about your disposition than the tools, I think.

[pretoriusB]

>The arguments to common UNIX commandline tools like sed or xargs are without doubt going to be longer-lived than the arguments to your helper script, likely even longer than the language your helper script was written in, and maybe even longer than the idioms and philosophies you had in mind when you were building your tool(s).

Yes. Sad isn't it?

It's not as if they were perfect when the were designed.