Hacker News Reader

Comment by vyuh | Hacker News Reader

"A good programmer uses the most powerful tool to do a job. A great programmer uses the least powerful tool that does the job." I believe this, and I always try to find the combination of simple and lightweight tools which does the job at hand correctly.

Awk sometimes proves surprisingly powerful. Just look at the concision of this awk one liner doing a fairly complex job:

    zcat large.log.gz | awk '{print $0 | "gzip -v9c > large.log-"$1"_"$2".gz"}' # Breakup compressed log by syslog date and recompress. #awksome

Taken from: https://mobile.twitter.com/climagic/status/61415389723039744...

View on HN

Ehh. Until the 'job' gets extended and then your simple tool makes it exponentially more complex and you have to rewrite it with the more powerful tool.

Choosing a "good enough for the medium term with minimal effort now" is a winner in my book, even if it's likely to be rewritten in the long term.

Exactly. I end up re-implementing my scripts if they outgrow the original scripting language anyway, because it's a good time to add proper argument and error handling, logging, etc.

Surely that isn't a weakness of a simple tool?

A 5 min job that probably won't get extended saving you from having to spend 20 mins coding something up is better than, feeling annoyed that you have spent the 20 mins coding up the original implementation and then extend it.

Hopefully, you also get the benefit of additional knowledge on that future implementation as well. Why wouldn't this just be a net win?

Unless you're talking about writing hack after hack after hack, eventually leaving yourself with some incomprehensible eldritch monstrosity, in which case, don't do that?

The nice thing about a 1-liner is you only lose a few minutes to throwing it out entirely and rewriting it to fit a new purpose. Dwelling on what might be needed is of limited utility, because of the very real possibility that what's actually needed in the future is wildly different from what you spent all that time planning for.

This is fine. I often "prototype" my automations as shell scripts, to explore what I actually want the tool to handle. Once it gets longer than 20 or so lines, it's time to move to a better language, but I don't mind rewriting. This is a chance to add error handling, config, proper arguments, built-in help texts and whatever else.

I started to add error handling to my shell scripts and often never rewrite them. Defo agree with the sentiment that you should always be happy (and able) to rewrite a shell scripts, dont let its scope creep. I don't mind long(ish) shell scripts as long as the program flow is fairly linear. Too many function calls is the smell that makes me rewrite.

If I understand this correctly, it will gzip every line separately instead of gzipping them together... it's not really the most effective but it does work

It does not. The pipe command leaves the pipe open and successive pipes with identical strings remain open until the pipe is explicitly closed.

[edit]

Here's the link to the gawk documentation, but most flavors of AWK work similarly: https://www.gnu.org/software/gawk/manual/gawk.html#Close-Fil...

Wow, this is amazing. It really shows how complexity should be managed in the tool so that the user can do the naive thing and have it be accidentally optimal

It is surprising to people who expect them to behave like shell pipelines and redirections though. I somehow never got bit by it, but have definitely corrected other's awk scripts who didn't know about this feature.

I really love that quote "..A good programmer...", do you have a source?

I believe the source is https://mathwithbaddrawings.com/2015/12/16/good-mathematicia...

Reply on news.ycombinator.com