On the higher level question in the article of why do people not use their main languages for basic file and command management?
I believe the answer is the same as to why Python remains hugely popular despite all the well-documented shortcomings: batteries included.
Shell languages include so many neat and concise ways to execute commands, deal with their input, output and exit codes, allow simple traversal of deep directory structures with globs and advanced tools like 'find' or 'xargs', that everything else is very unergonomic.
And niche by default (until it gets used widely enough), so even your LANG-OF-CHOICE-expert you recruit, they will not know a thing about that shell-focused library in LANG-OF-CHOICE.
I was sure this article would be about how we tell computers to do things now (writing prompts to an AI in plain English). I was wrong. Interesting nonetheless.
TIL that the duckdb REPL supports reading json files (https://duckdb.org/docs/current/data/json/overview). This might actually be useful the next time I need to investigate a massive json file (`jq` can only go so far).
I was pretty close in guessing what they believe was "wrong" (or really, superfluous) with their initial shell script example.
I'd actually even drop the "if" from their footnotes, and go with simply
npm install || (echo "boom" && exit)
(Not exactly equivalent because there won't be an "exit" if echo fails, but it's my preferred instict over ";") Also, "(" starts a subshell, if we are being pedantic.
Why are we assuming using the terminal is the only way of "telling a computer to do things"? Every way you interact with a machine, you are telling it to do things in theory.
For example
> At a fundamental level, I wasn’t able to tell my computer to accomplish anything that involved logic or stitching together multiple programs
How can that be true if you are telling it to boot on into a os? It doesn't involve logic? Or stiching together multiple programs?
Using a shell =\= telling a machine what to do on a broad level. You are just using the abstractions provided by the os. If you mean get better at shell so you can use it more efficiently than okay cool but that doesn't someone who uses a GUI doesn't "tell" the machine what to do as much as you.
I believe the answer is the same as to why Python remains hugely popular despite all the well-documented shortcomings: batteries included.
Shell languages include so many neat and concise ways to execute commands, deal with their input, output and exit codes, allow simple traversal of deep directory structures with globs and advanced tools like 'find' or 'xargs', that everything else is very unergonomic.
And niche by default (until it gets used widely enough), so even your LANG-OF-CHOICE-expert you recruit, they will not know a thing about that shell-focused library in LANG-OF-CHOICE.
I'd actually even drop the "if" from their footnotes, and go with simply
(Not exactly equivalent because there won't be an "exit" if echo fails, but it's my preferred instict over ";") Also, "(" starts a subshell, if we are being pedantic.If you take nothing else away from this, memorize the syntax of one-liner for loops, it has saved me so many times.
For example
> At a fundamental level, I wasn’t able to tell my computer to accomplish anything that involved logic or stitching together multiple programs
How can that be true if you are telling it to boot on into a os? It doesn't involve logic? Or stiching together multiple programs?
Using a shell =\= telling a machine what to do on a broad level. You are just using the abstractions provided by the os. If you mean get better at shell so you can use it more efficiently than okay cool but that doesn't someone who uses a GUI doesn't "tell" the machine what to do as much as you.