I think the charitable interpretation is that the author is referring to particular use-cases which stopped being served by CLIs.
Heck, just look at what's happening at this very moment: I'm using a textarea with a submit button. Even as a developer/power-user, I have zero interest in replacing that with:
echo "I think the..." | post_to_hn --reply-to=45742461
A hybrid will likely emerge. I work on a chat application and it's pretty normal that LLM can print custom ui as part of the chat. Things like sliders, dials, selects, calendars are just better as a GUI in certain situations.
I've once saw a demo of an AI photo editing app that displays sliders next to light sources on a photo and you are able to dim/brighten the individual light sources intensity this way. This feels to me like a next level of the user interface.
1. There's a "normal" interface or query-language for searching.
2. The LLM suggests a query, based on what you said you wanted in English, possibly in conjunction with results of a prior submit.
3. The true query is not hidden from the user, but is made available so that humans can notice errors, fix deficiencies, and naturally--if they use it enough--learn how it works so that the LLM is no longer required.
Yessss! This is what I want. If there is a natural set of filters that can be applied, let me speak it in natural language, then the LLM can translate that as good as possible and then I can review it. E.g. searching photos between X and Y date, containing human Z, at location W. These are all filters that can be presented as separate UI elements so I can confirm the LLM interpreted correctly and I can adjust the dates or what have you without having to repeat the whole sentence again.
Also, any additional LLM magic would be a separate layer with its own context, safely abstracted beneath the filter/search language. Not a post-processing step by some kind of LLM-shell.
For example, "Find me all pictures since Tuesday with pets" might become:
Then the implementation of "fuzzy-content" would generate a text-description of the photo and some other LLM-thingy does the hidden document-building like:
Description: "black dog catching a frisbee"
Does that "with pets"?
Answer Yes or No.
Yes.
But the article is coming from a decisively antagonistic angle though.
>This was also why people hated operating systems like MS-DOS, and why even all the Linux users reading this right now are doing so in a graphical user interface.
What is the significance of "Even all the Linux users"? First of all it's probably incorrect, because of the all quantifier. I've went out of my way to look at the website via the terminal to disprove the statement. It's clearly factually incorrect now.
Second, what does hate have anything to do with this? Graphical user interfaces serve different needs than text interfaces. You can like graphical user interfaces and specifically use Linux precisely because you like KDE or Gnome. You can make a terrible graphical user interface for something that ought to be a command line interface and vice versa. Vivado isn't exactly known for being easy to automate.
Third, why preemptively attack people as nerds?
>There were a tiny handful of incredible nerds who thought this was fun, mostly because 3D graphics and the physical touch of another human being hadn't been invented yet.
I mean, not only does this come off as an incredible strawman. After all, who wouldn't be excited by computers in an era where they were the hot new thing? Computers were exciting, not because they had text interfaces. They were fun, because they were computers. It's like learning how to drive on the highway for the first time.
The worst part by far is the unnecessary insinuation though. It's the standard anti-intellectual anti-technology stereotype. It creates hostility for absolutely no reason.
The first time my driving instructor took me on a high way.. after a few minutes he looked over at me and said something like "isn't this exciting?" The sarcasm did not register with me because I indeed found it exhilarating even though we were just casually cruising in traffic.
Some TUI programs can embed a small cli. Like Midnight Commander, and others. Or externally call commands and shells, or even pipe the output. Ed itself, vi, slrn...
Also, some commenters here at HN stating that the CLI/TUI it's just the fallback option... that's ridiculous. Nvi/vim, entr, make... can autocompile (and autocomplete too with some tools) a project upon writting any file in a directory thanks to the entr tool.
If we take the total number of computer users globally, and look at who use GUI vs CLI, the latter will be a teeny tiny fraction.
But most of those will likely be developers, that use the CLI in a very particular way.
If we now subdivide further, and look at the people that use the CLI for things like browsing the web, that's going to be an even smaller number of people. Negligible, in the big picture.
Don't forget to count people that require screen readers, this is often a less vocal minority that often depend on CLI tools for interaction with the computer.
It's actually an interesting example, because unlike Warp that tries to be a CLI with AI, Claude defaults to the AI (unless you prefix with an exclamation mark). Maybe it says more about me, but I now find myself asking Claude to write for me even relatively short sed/awk invocations that would have been faster to type by hand. The uncharitable interpretation is that I'm lazy, but the charitable one I tell myself is that I don't want to context-switch and prefer to keep my working memory at the higher level problem.
In any case, Claude Code is not really CLI, but rather a conversational interface.
Claude Code is a TUI (with "text"), not a CLI (with "command line"). The very point of CC is that you can replace a command line with human-readable texts.
You may think that's pedantic but it really isn't. Half-decent TUIs are much closer to GUIs than they are to CLIs because they're interactive and don't suffer from discoverability issues like most CLIs do. The only similarity they have with CLIs is that they both run in a terminal emulator.
"htop" is a TUI, "ps" is a CLI. They can both accomplish most of the same things but the user experience is completely different. With htop you're clicking on columns to sort the live-updating process list, while with "ps" you're reading the manual pages to find the right flags to sort the columns, wrapping it in a "watch" command to get it to update periodically, and piping into "head" to get the top N results (or looking for a ps flag to do the same).
But that's not how it's typically used, it's predominantly used in TUI mode so the popularity of CC doesn't tell us anything about popularity of the CLI.
Hi, sorry for the unrelated reply, but I wanted to ask you about a comment you made 6months back about archiving Gamasutra posts. I came across it while searching HN for "gamasutra".
I'd bookmarked a lot of Gamasutra articles over the years and am kinda bummed out that I can't find any of them now that the site has shifted. You mentioned having a collection of their essays? Is there any way to share or access them?
Also, to be clear, I’m mostly goofing about it CLIs, and — as I mentioned in the piece — I use one every day. But yes, there are four or five billion internet users who don’t and never will. And CLIs are a poor user interface for 99+% of the tasks that people accomplish on computing devices, or with browsers, which is pertinent for the point I was making.
If I’d anticipated breaching containment and heading towards the orange site, I may not have risked the combination of humor and anything that’s not completely literal in its language. Alas.
Well, it's not just that (not that I disagree with the author in general, but I do on this point). point-and-click interfaces _are_ objectively worse interfaces for power use. I've been stuck selecting a group of files, moving them, double-clicking and renaming, selecting another, etc. all the while knowing that I could write a script that could do all of this much faster if I had access to a command line interface. Point-and-click is just easier to get started with.
The comparison with Zork and the later comment about having to "guess" what to input to get a CLI to work we're also bizarre. He's obviously stretching really hard to make the analogy work.
Don't get me wrong, I'm not arguing that expansion of GUI based interfaces wasn't a good thing. There's plenty of things I prefer to interact with that way, and the majority of people wouldn't use computers if CLIs were still the default method. But what he's describing is literally not how any ever used the commandline.
Also most of the infocom games were pretty much improved against Zork in the 80's.
In the 90's, the amateur Inform6 games basically put Infocom games almost as if they were the original amateur ones, because a lot of them were outstanding and they could ran on underpowered 16 bit machines like nothing.
Ask your non-dev peers if they know what the command line is and if they have ever used it or seen especially when most people use the web on their smartphone.
I recently demonstrated ripgrep-all with fzf to search through thousands of PDFs in seconds on the command line and watched my colleague’s mind implode.
No we didnt.