2 ms·

You are wrong about #1: her design goal was use from the command line (according to her readme), not from node.js. You are wrong about #2 too: I have said this

by mrb 14y ago

You are wrong about #1: her design goal was use from the command line (according to her readme), not from node.js. You are wrong about #2 too: I have said this 5 times already: you can write a very short (much shorter than 173 lines of js) a wrapper shell script exposing an interface as easy as "replace". Please read what I wrote!

acqq 14y ago
Even if she designed it to be used from the command line, and this is still not the only possible use of the JavaScript code which she open sourced, she had one more reason: sed doesn't have JavaScript regexps. Anybody who really wants to use JavaScript regexps doesn't have other choice but to use her tool. Now you can say that you don't need that, but you still has to admit that others may. So you're still wrong.
- mrb 14y ago
  With all due respect, you add nothing to the discussion, I already acknowledged this in my OP: "There is only one case that justifies reimplementing things: if your tool has the requirement of supporting the exact js regex syntax..." (Please read what I wrote, really!)
  - acqq 14y ago
    a) Can you agree that the main reason of open sourcing a JavaScript code is for others to use the same code in their projects, not to "run the command line"? b) Regarding those that do want to "run the command line," can you agree that there are users who really want and need to use JavaScript regexps from the command line and not some other regexps with different semantics? c) Can you accept that these are the valid use cases that your "use sed" arguments just don't cover? I've read your arguments and I've never seen clear acceptance of a) b) and c). I've also seen that you had to carefully think and even improve your "use sed" implementations, giving also the good argument in favor of her approach. Having the tools that demand less from the user is a good thing. Can you accept that (d) too? Can you see why we discuss, when you just quote yourself as "There is only one case"? That's why I claim you're wrong. There's not only one case.

by mrb 14y ago

acqq 14y ago

Even if she designed it to be used from the command line, and this is still not the only possible use of the JavaScript code which she open sourced, she had one more reason: sed doesn't have JavaScript regexps. Anybody who really wants to use JavaScript regexps doesn't have other choice but to use her tool. Now you can say that you don't need that, but you still has to admit that others may. So you're still wrong.

mrb 14y ago
With all due respect, you add nothing to the discussion, I already acknowledged this in my OP: "There is only one case that justifies reimplementing things: if your tool has the requirement of supporting the exact js regex syntax..." (Please read what I wrote, really!)
- acqq 14y ago
  a) Can you agree that the main reason of open sourcing a JavaScript code is for others to use the same code in their projects, not to "run the command line"? b) Regarding those that do want to "run the command line," can you agree that there are users who really want and need to use JavaScript regexps from the command line and not some other regexps with different semantics? c) Can you accept that these are the valid use cases that your "use sed" arguments just don't cover? I've read your arguments and I've never seen clear acceptance of a) b) and c). I've also seen that you had to carefully think and even improve your "use sed" implementations, giving also the good argument in favor of her approach. Having the tools that demand less from the user is a good thing. Can you accept that (d) too? Can you see why we discuss, when you just quote yourself as "There is only one case"? That's why I claim you're wrong. There's not only one case.