I still think this is true, after so many years :) Shell, awk, and make all started out as limited DSLs, and then they grew bad languages on top.
Also, shell, awk, and make are still weirdly popular, and even increasing in popularity, in 2024 vs. 2016. I honestly think this is due to a "design deficit" -- in some ways we are designing worse systems software in the 2010's and 2020's, compared to 1980 or 1990.
Shouldn't something better already exist?
This is probably due to incentives -- there is a negative incentive for interoperability. (The Internet itself of course being the ultimate in interoperability; we're missing that in software - https://www.oilshell.org/blog/2022/02/diagrams.html )
---
So combining them makes sense, but in retrospect, it isn't trivial! I made comments on this last year:
Also, good news as of this weekend -- Oils is completely translated to fast native code via C++. The next release will show ZERO test failures in C++ vs. Python, out of thousands.
That's an interesting perspective. I would be surprised though how long any change would take to propagate given the big intertia behind all of these tools. The fact that you can find awk and (ba)sh on nearly all Linux machines makes it the default choice when writing a portable script or oneliner.
Hm, I guess my response would be that this sorta begs the question. WHY are awk and sh/bash the "best" thing on nearly all Linux machines, the default choice?
Why didn't something better come along in the 90's or 2000's or 2010's that made them less appealing or obsolete? That something could be installed "everywhere" by now.
Not to say there hasn't been progress of course -- I think say fish, ninja, jq, etc. are great projects. They also are installed in most places, and ninja and jq aren't that old.
IMO, it's just a lot less than you would expect given the huge growth in computing in the last 20-30 years.
> WHY are awk and sh/bash the "best" thing on nearly all Linux machines, the default choice?
From my experience with of them: They are good enough.
Leapfrogging software with incremental advances only works sometimes and the "standard env" is already very advanced.
I do appreciate the features provided by, e.g., ripgrep over GNU grep but I can likely get the job done without it.
There are ofc some exceptions, like jq for JSON handling, but I have only really seen that used by developers. However I've rarely seen it on legacy/ production machines because it often makes more sense to use Python/ Perl at this stage.
