4 ms·

Here's the Twitter discussion alluded to in the post: https://twitter.com/harthvader/status/293829635823792128 https://twitter.com/harthvader/status/2938296358

by luigi 14y ago

Here's the Twitter discussion alluded to in the post: https://twitter.com/harthvader/status/293829635823792128 https://twitter.com/harthvader/status/293829635823792128 Main justification is the nicer syntax. I agree it's nicer, but would approach it by wrapping sed, not re-implementing in Node.js from scratch. I don't think that excuses the ridicule, though.

tunesmith 14y ago
Me neither. It's not as if klabnik was asked to use it. Plain old rude, in the name of defending no principle in particular.
jjm 14y ago
The maximist point of view is to wrap sed, yes. But what also came to my mind was what if he/she just wanted to only learn, I can think of no better way than to try to write it 'yourself' in the language of your choice, if only as a learning exercise. All to often we in technology assume the maximist point of view, possibly completely discounting another dynamic point of view or some inspirational reasoning (of the originator). *edit: spelling
parfe 14y ago
How would you get sed to output the files and lines on which replacements happened?
- noste 14y ago
  How about using diff and sed -i? # This version is obviously unsafe verbose_sed() { sed -i.old -e "$1" "$2" diff -u "$2.old" "$2" rm "$2.old" } verbose_sed s/vim/emacs/g rant.txt You could then use all the tools that we already have for working with patches: colordiff to colorize the output, diffstat for a summary of changes, patch -R for reverting the changes, and so on. Of course, you're more likely to than not already using version control, which gives you all this and much more, even if you were to use vanilla find+sed.
flogic 14y ago
I don't think rewriting as a wrapper around sed would be an improvement. That would put you in the business of translating one regexp syntax into another which is probably more error prone.

by luigi 14y ago

tunesmith 14y ago

Me neither. It's not as if klabnik was asked to use it. Plain old rude, in the name of defending no principle in particular.

jjm 14y ago

The maximist point of view is to wrap sed, yes. But what also came to my mind was what if he/she just wanted to only learn, I can think of no better way than to try to write it 'yourself' in the language of your choice, if only as a learning exercise. All to often we in technology assume the maximist point of view, possibly completely discounting another dynamic point of view or some inspirational reasoning (of the originator). *edit: spelling

parfe 14y ago

How would you get sed to output the files and lines on which replacements happened?

noste 14y ago
How about using diff and sed -i? # This version is obviously unsafe verbose_sed() { sed -i.old -e "$1" "$2" diff -u "$2.old" "$2" rm "$2.old" } verbose_sed s/vim/emacs/g rant.txt You could then use all the tools that we already have for working with patches: colordiff to colorize the output, diffstat for a summary of changes, patch -R for reverting the changes, and so on. Of course, you're more likely to than not already using version control, which gives you all this and much more, even if you were to use vanilla find+sed.

flogic 14y ago

I don't think rewriting as a wrapper around sed would be an improvement. That would put you in the business of translating one regexp syntax into another which is probably more error prone.