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).
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 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.
LLMs solved this exact problem. Not perfectly (they can sneak in some malicious commands) but good enough for everyone. This is also mostly what non-developers mean by "vibe-coding". They can "tell the computer to do the things" they want. Previously they were limited to existing GUI applications. Now they can automate and customize their workflows as they wish and think they're a 'coder'.
I was pretty close in guessing what they believe was "wrong" (or really, superfluous) with their initial shell script example.
I'd even drop the "if" from their footnote version, 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.
I wonder if there’s some obscure syntax for "do this if the last command fails and propagate its exit code". For just returning some error you can of course have something like `die("boom")` (though not as a builtin?) but sometimes it’s useful to know the exact code.
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.
That philosophical point about what it even means to "tell a computer to do things" is a good one. Sure, clicking around in a GUI is also telling the computer what to do. But there's a huge difference between using someone else's abstraction and building your own from scratch. The article is about that second part - the ability to throw stuff together however you want. With a GUI, you're stuck with whatever the designer thought of. With a shell, you can build just about anything
But you’re still limited by the designer of that shell? Or userspace? Or kernel? Or cpu architecture? I mean, how deep should you go before «it’s however YOU want»?
There are some really powerful UIs that are extremely flexible, like spreadsheets, or ComfyUI, or certain issue trackers. On the whole however I would say they all still are mostly their own interaction silos and integrations with other programs have to be explicitly built for each app.
The great thing about a shell is that you can glue together programs that don't know about each other. This is not a silver bullet, with shell programs being text oriented etc., but it does give rise to some powerful possibilities that don't really work with UIs.
Your next homework assignment is to write your own scripting language that emits asm. Then you'll be one step closer to understanding what it really means to tell your computer to do things!
Nice article about actually learning stuff and putting this knowledge to use together. Not with AI but with one’s own brain.
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).
in what case jq, a specialized json tool, is more limiting than sql?
Good advice. I've gotten a ton of utility out of my shell without learning very many tools particularly well.
If you take nothing else away from this, memorize the syntax of one-liner for loops, it has saved me so many times.
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
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 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.
LLMs solved this exact problem. Not perfectly (they can sneak in some malicious commands) but good enough for everyone. This is also mostly what non-developers mean by "vibe-coding". They can "tell the computer to do the things" they want. Previously they were limited to existing GUI applications. Now they can automate and customize their workflows as they wish and think they're a 'coder'.
I was pretty close in guessing what they believe was "wrong" (or really, superfluous) with their initial shell script example.
I'd even drop the "if" from their footnote version, 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.
I wonder if there’s some obscure syntax for "do this if the last command fails and propagate its exit code". For just returning some error you can of course have something like `die("boom")` (though not as a builtin?) but sometimes it’s useful to know the exact code.
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.
That philosophical point about what it even means to "tell a computer to do things" is a good one. Sure, clicking around in a GUI is also telling the computer what to do. But there's a huge difference between using someone else's abstraction and building your own from scratch. The article is about that second part - the ability to throw stuff together however you want. With a GUI, you're stuck with whatever the designer thought of. With a shell, you can build just about anything
But you’re still limited by the designer of that shell? Or userspace? Or kernel? Or cpu architecture? I mean, how deep should you go before «it’s however YOU want»?
There are some really powerful UIs that are extremely flexible, like spreadsheets, or ComfyUI, or certain issue trackers. On the whole however I would say they all still are mostly their own interaction silos and integrations with other programs have to be explicitly built for each app.
The great thing about a shell is that you can glue together programs that don't know about each other. This is not a silver bullet, with shell programs being text oriented etc., but it does give rise to some powerful possibilities that don't really work with UIs.
Your next homework assignment is to write your own scripting language that emits asm. Then you'll be one step closer to understanding what it really means to tell your computer to do things!
There is, of course, a programming language designed to do shelly things as succinctly as a shell script: Perl.
I was amused to see DeepSeek using it recently, as I didn't realize it was installed on my machine (macos with brew).
Ruby is much, much prettier for similar purposes though, and so that's what I'll learn if I ever need to do this more frequently.
Also Scsh[0].
[0]: https://en.wikipedia.org/wiki/Scsh