Choosing the right tool: JavaScript vs. sed

1 points by claes-magnus ↗ HN
https://herebeseaswines.net/essays/2020-04-19-choosing-the-right-tool-js-vs-sed I am a junior Web developer and have just started to learn sed. Why don't more web developers use sed? I am sure there are quite a few who know this gnu-tool, but I can't recollect if I've seen sed being mentioned in the JS community. Yesterday I started to make a simple hobby project, but I quickly realized how stupid I was to use JS instead of sed and decided to compare a JS and sed solution (limited scope though).

15 comments

[ 3.5 ms ] story [ 55.2 ms ] thread
> I am sure there are quite a few who know this gnu-tool

You'd be very surprised if you start actually asking.

I predict if you start actually asking, you'll find that those who even know it exists are a very small minority of the group, and that those who actually use it are a small minority of that already small minority.

I don't know. As I said, I am a junior web developer so it is hard for me to generalize. Perhaps no-one use it? But I enjoy it. :)
Begin asking around in your dev circles.

Keep track of how many you ask, and how many of that value even know of it, and further, how many who know of it regularly utilize it.

Then you'll have some actual factual values with this to reach any conclusions. I predict you'll find that the "knows about" group is, maybe, at best 15% of the total, and the "uses it regularly" group is, maybe, at best 5% of the group that even knows it exists.

Yes, ok. But this doesn't say it's a bad tool? Only a not very used tool? (I know that you've not claimed neither; only that is not a very used tool)
It would give you specific data to use for your initial hypothesis:

"I am sure there are quite a few who know this gnu-tool"

My hypothesis is that you will find that instead of "quite a few who know" (implying a large value and/or majority) that if you start asking you will find that reality is "very few even know" and an even smaller subset of those very few actually utilize.

It is very hard to estimate such matters when you're a junior developer. :) Say you're right. Actually, I don't doubt you. I am certain that I will find I was wrong when I wrote that. But still, this does not mean sed is not a tool worth learning and I am very greedy in such contexts. I love learning. And in some contexts, it seems very reasonable to use sed (and awk) rather than js, python or a 'richer' language?
You are reading in something I never said.

This is what you are reading in: "this does not mean sed is not a tool worth learning"

I never said, nor implied, that.

None of my prior responses have said whether sed is worth, or not worth, learning. My responses were focused only on your initial hypotheses that implied a large number know of it. My hypotheses is if you actually test your statement within your JS dev. groups, you'll find a shockingly low number of members who even know sed exists.

Now, as for my opinion of sed, it is a fine tool, and it is well work knowing how to use it (at the very least knowing how to use it for its most common usage, replacing strings with other strings). I myself reach for it quite often when I need to do something that it is good at doing.

And, yes, for you, it is well worth learning something about it. It is also well worth you learning something about many of the other CLI tools, such as head, tail, join, comm, seq, etc. There are a huge number of them, and they can often allow you to solve a problem without ever writing a single line of code (unless you consider a Unix pipeline to be 'code').

I wrote, >> Yes, ok. But this doesn't say it's a bad tool? Only a not very used tool? (I know that you've not claimed neither; only that is not a very used tool)

But since you continued to stress your hypothesis and ignored this, I (incorrectly) presumed you had another agenda. I misinterpreted you, and I am thankful for you sharing knowledge on the other stuff. :) Sorry!

This is exactly what I am beginning to realize: >> hey can often allow you to solve a problem without ever writing a single line of code (unless you consider a Unix pipeline to be 'code' Therefore it is very valuable for me when someone who obviously have greater knowledge points this out. Thanks! This was also my point with my project: a demonstration aiming to show that we didn't need JS, but only a few lines of sed. :)

Sed is a command line utility for unixoid shells. It is comparable to awk. I say this because the awk binary is actually an interpreter for the similarly named programming language. So awk is in some way similar to the v8 JavaScript interpreter binary.

Using sed from JavaScript is therefore on similar footing then using Python from JavaScript. It results in a heavy process call with challenging passing of information between the caller and the callee. That's the basic difference between a shell script (which relies by definition on the system binaries) and a high level programming language.

I think a fairer question is: why is there not a npm module similarly powerful as sed. I dunno if there is. Maybe it is :)

If you find sed useful I would encourage you to check out Perl (https://www.perl.org/).

It has all of the powerful regular expression capabilities that sed has plus much more.

You should enjoy my post from yesterday: https://herebeseaswines.net/essays/2020-04-18-a-bash-perl

Yes, I wanna learn Perl! :)

If you are familiar with JavaScript then you should be able to be productive with Perl pretty quickly.

I recommend the reading "Programming Perl" (the Camel book) or "Learning Perl", both from O'Reilly press.

If you are using a Mac or Linux system, you probably already have Perl installed, so there is no setup to start using it.

Yes, I have it (I am on a Linux). Thank you for sharing! :) Cheers!
I think the Bash vs Perl example there is not exactly fair, since in Perl you're not assigning to ls_output first. You could do the same in bash, and it's arguably just as expressive:

    (( `ls | wc -l` > 100 )) && echo "many files" || echo "few files"
Nice!!! I am very grateful. Thank you for sharing! I did not know you could solve it like so. And yes, this is very expressive!