Hacker News Reader

Comment by kamaal | Hacker News Reader

I think the point everyone is trying to make here is. Should every person spend 5-10 minutes doing this?

If the problem occurs too frequently, it makes more sense to make the solution re usable. Which is exactly what 'replace' is doing here.

View on HN

> I think the point everyone is trying to make here is. Should every person spend 5-10 minutes doing this?

Exactly. People tell me "Nobody needs ack, you just write wrappers around find+grep" and I say "You could, but I published it and now people don't have to."

This reminds me of the first of Larry Wall's three virtues:

"[Laziness] makes you write labor-saving programs that other people will find useful, and document what you wrote so you don't have to answer so many questions about it. Hence, the first great virtue of a programmer."

I use ack, but that's because it searches for the right file types, ignores source control directories automatically, and has pretty colors, not because it's find+grep.

Other than "pretty colors", your statement contradicts itself. Doing the things you mentioned is being find+grep. That's the entire point of ack, to be find+grep.

I didn't say that find couldn't ignore source control directories or find only specific file types. However, ack does that far better as it has a better semantic awareness of both concepts.

I don't have to worry about updating my find command lines to account for new types of source code or source control folders in unfamiliar programs, I need only ensure that ack is kept up-to-date.

I'm not sure what you are trying to say. Your post contradicted itself. You literally said "I don't use ack because it is find+grep, I use it because it is find+grep". I am simply pointing this out.

Except by that logic, you could say that any user of a high-level language was really claiming (in the end) to be using assembly.

C++ once compiled to C, but even then people wouldn't claim they were using C, they'd claim they were using C++. "I don't use C++ because it's C with 'classes', I use C++ because it sets up my vtables and overloaded functions"

That analogy makes absolutely no sense. You are claiming an intended use. And then contradicting yourself by saying you don't use it for that intended use. The analogy would be "I don't use C++ to write programs, I use C++ to write words that have a particular syntax that a C++ compiler can understand and translate into executable machine code". And that statement is just as contradictory as the one you made.

The point everyone seems to be making is that there is no reason to do this in javascript if it's for command line use. Implementing it in js like this is just silly.

JavaScript has a widely used, native regular expression engine. That's enough technical defense on its own for that particular design decision, besides the usual, "Reimplementing a unix command-line tool in your favorite language is always a useful exercise."

Then write it once and share the wrapper script on github. No?

Why do you have such a strong objection to someone spending their own free time to simplify and / or mimic [insert unix tool functionality here].

It clearly serves a purpose and it's apparently useful. Most importantly, it exists, so there's no need to argue over how you think it should have been implemented.

I'm sure if you were to release your own [script / wrapper], someone would find use for it, in the same manner that some have apparently used 'replace'. I honestly fail to see the big deal here.

I know it someone's right to do this, of course. I object because I come from an environment (software industry) where I have spent hundreds of hours undoing people's poor jobs where they wasted time and money reimplementing (incorrectly) library functions, system commands, etc. Because of this personal experience, I reacted the same way many reacted when seeing her script. So, I decided to explain to her and attempt to convince her that she should have spent her time and skills on something else (especially because she seems a rather good programmer!) Does it make sense?

I object because I come from an environment [...] where I have spent hundreds of hours undoing people's poor jobs where they wasted time and money reimplementing [...] system commands

What you fail to take into account is that there's definitely a niche for Node.js-based development tools such as this script: The GNU userland is not ubiquitous.

Node.js did not come with a system command to search and replace across files - now it does.

It's a one off tool, unlikely to be used in any project you are writing software for. She provided the source code freely, and the code isn't bad at all.

I fail to see why you will ever need to rewrite this?

Fair. I can see where you're coming from.

You have better things to do than tell people to invent time machines to go back and not do things that are already done.

C'mon we are long past the days where tools had to written in $somelanguage. These are days where even things like compilers and databases are not being written in C.

If its of any help I think its time for the Unix community as a whole to sit down and self reflect. If people are beginning to think something like 'sed' as too level to use, then better job needs to be done to make them more accessible and usable. There are enough examples on this thread where people are saying that they look at sed as an API on top which a program needs to be built up on. And not a complete program in itself. Also shell is not a full fledged programming language.

I respectfully disagree with you here. The beauty and the wonder of these small command line tools (for me, at least) is that they are a) small and b) fast and c) ubiquitious. I do a lot of data manipulation, and while I'll do anything complex in a real programming language (with a REPL) sed, awk, grep and find are really really handy for quick data finding and manipulation.

Any new API on top of them would only be present on a fraction of machines, and thus would reduce the major advantage of them in that they are available everywhere.

Wow, you actually stated something that was wrong enough to force me to comment. The beauty of these tools are that they are small, fast, ubiquitous, AND easy to replace with other tools if they fit your problem better. Unix was built exactly for swapping in these small one-off programs and to deny that is to deny the beauty of it's design and to basically ignore the fact that the system is built to string arbitrary programs together to solve complex problems in simple ways.

One advantage of her Javascript replace is that she can drop it on any machine with a Javascript runtime and it will work, unlike sed.

And the real truth is, she wrote something that solves a problem she has, which is the measure of her success, not someones arbitrary comments.

Reply on news.ycombinator.com