7 ms·

To summarize: The people who ruined native GUIs moved to HTML pages. After ruining HTML pages they are now moving to terminals. In this very thread we're seein

To summarize: The people who ruined native GUIs moved to HTML pages. After ruining HTML pages they are now moving to terminals. In this very thread we're seeing people say "Well sure, but why not add ...". The reason why the CLI is good is because it _can't_ do most things people want it to do. Which means you have to think when making an application. Please, if you're one of the people 'modernizing' the terminal stop and think why the terminal is valuable. Don't make it into another of the long line of UIs which have been destroyed by modern developers.

kvark 2y ago
Having a standard CLI is definitely helpful. But does it have to be so hard to use? At what point would we acknowledge that we are being hostage by some random ideas put into ancient software, which just happened to survive? I don't think calling for a stop of experimentation is the way. Nobody is going to take away your vi and bash any time soon.
- immibis 2y ago
  We shouldn't be held hostage, but the evolution of interactive CLIs is GUIs and the evolution of batch CLIs is scripting languages, and we don't need to render the CLI concept meaningless by integrating both. I've seen a terminal emulator that supported pixel graphics - what's the point! Just make a GUI using your favorite framebuffer library! A TUI is not a CLI, either.
wiseowise 2y ago
> The reason why the CLI is good is because it _can't_ do most things people want it to do. -1. You’ve lost me here. The reason why CLI is good because it solves problems that even modern GUIs can’t, not because of some artificial limitations or lack of convenient defaults. > Which means you have to think when making an application. “Think” and “remember obscure syntax that greyheads keep on a paper under their mattress” are two different things. I agree with the author that sensible defaults are severely lacking from some of the tools.
- ulbu 2y ago
  one great property of the terminal is that it’s not a continuous canvas. it’s a grid of discrete cells, just as it is natural for computers to be. instead of laying interactive objects out in virtual space, you’re pushed to think in discrete states and discrete actions. so I say cli is, indeed, good in part due of its limitations. edit: i’ll add that continuousness of guis is actually its limitation. a terminal interface is indexable, a gui is not. so what looks like freedom is actually a different structure. a gui is more general, as real numbers are more general than whole numbers. but to get to whole numbers, you have to re-constrain real numbers. this is left up to the developer to create a constraining framework. and it’s a path of less resistance to not do this. most data we deal with is discrete. so a continuous representation of it is a mismatch of structures. terminals force you to stay in that same discrete space. so your solutions are from the getgo closer in fit to your data. it’s important to match up the structure of your interactive surface with the structure of your domain. it’s a common principle we talk about too little.
  - cdrini 2y ago
    I think that's it, although I don't think I'd describe it as a grid, but as a 1d list. The core concept of CLIs is linear. That's in part why streaming works so effectively in CLIs, because the linear medium clicks really well with the idea of streaming data. And actually the fact that a lot of UNIX commands actually operate on a graph of sorts under-the-hood is where you can see some of the limitations of this linear approach (eg trying to pipe one stream to multiple paths with each path having its own processing requires a branch which is inherently a little difficult to represent in a linear system). You can lay things out in a grid, but the same can be said of GUIs. You can consider each character a cell in a grid, but I think that's so small that at that point it's not conceptually sufficiently different from being continuous. The computational paradigm that's a grid at its core is spreadsheets.
- deleted 2y ago
  [deleted]
- oulipo 2y ago
  Exactly, they conflate the fact that the CLI tool is just a "programmable API view" of an app, and that GUI is more of a "interaction view", with the fact that it can or cannot do some stuff Now with AI and better design, nothing in theory would prevent us to "script UI apps" like we do with terminal, you could say "take a screenshot of my webpage with Chrome | set it in isometric with nice shadow using Photoshop | send it on my iPhone Twitter app" and you would get the same pipeline of course "UI apps" just have too many input / output possibilities, and you wouldn't want to have "--flags" everywhere for every possibility But that's where "natural language as a universal API" applies, or perhaps just a better design for interaction with UI apps
lifthrasiir 2y ago
The terminal is valuable just because it has applications that are easy to do or even only possible in it. Specifically, a full-duplex interactivity at a low data rate. I don't think any current "modernization" proposals threatened that so far, the biggest contender would be any image support but it isn't meant to be used every time anyway.
- flohofwoe 2y ago
  TBH I would love a pixel framebuffer standard for terminals that's fast enough to run things like Doom, emulators, or simple UI applications in the terminal. The Sixels standard exists but has a too complicated pixel encoding.
  - immibis 2y ago
    That's every GUI system, though. /dev/fb0, or X11. We don't have to force it to fit into a character stream abstraction for some silly reason. Different abstractions are allowed to be different.
hnlmorg 2y ago
As someone who is working on modernizing the command line, I think it is entirely possible to strike a balance. - the command line is just byte streams Shells like Elvish, Nushell, Powershell and my own shell, Murex, support typed pipelines and that brings a great number of enhancements. Like native support for JSON, CSV and other data formats. Thus meaning you can have a unified syntax for handling different files rather than remembering a dozen different tools and their specific idiosyncrasies, eg `jq`, `awk`, etc - readline is dated We can do better than the typical shell interface. The popularity of tools like `fzf` and `starship` show that people do actually find modern TUIs useful - rendered text is static Lets say you view a JSON file in Firefox, you can expand and collapse specific branches of that JSON file. I'd love to be able to do that with JSON in the terminal. And not just JSON, tools like `tree` could benefit from that too. Collapsible trees is a feature I'm working on implementing in my terminal emulator and it's completely optional. ie by default the tree renders the same way any other terminal would render that clump of text. Except you can then optionally collapse branches just like you can with code in an IDE or comments in HN. --- I love the command line. I've been using it for 30+ years and written so many tools for fellow CLI enthusasts. But even I think an ideal world would be us moving away from grid based virtual teletype interfaces pushing communicating via raw bytes and with in-band control codes, and instead switch to something more robust. But that's never going to happen. Heck, even things like job control (ie when you hit ^z) is non-trivial to implement at a shell level. It requires multiple signals (each originating from a different sender), and 3 different hierarchies of process ID registration. Frankly, it's amazing any of this stuff still works. And that's before we touch on the plethora of competing standards to test what client (ie terminal emulator) is connected to that "virtual typewriter".
- aragilar 2y ago
  But how many of these new tools are robust when there's high latency? The advantage of good old POSIX shell is it works on cheap routers, the latest HPC systems, the system next to me and the system of the literal other side of the world, and everything in between.
  - maccard 2y ago
tazu 2y ago
This is why Textualize[1] concerns me. I've tried a few of the applications using their framework, and they have noticable keypress latency. I didn't think it was possible to make a bloated TUI, but they have somehow succeeded. This might just be a Python thing because of the GIL, because VisiData[2] has the same problem. It's physically jarring to use VisiData because it's such a cool idea, but takes 500ms to register key presses in my 120hz terminal emulator. It's reminiscent of scroll-jacking, excessive animation, and other web GUI bloat, just translated to TUIs. [1]: https://www.textualize.io/ https://www.textualize.io/ [2]: https://www.visidata.org/ https://www.visidata.org/
- saulpw 2y ago
  (Author of VisiData here) I don't know what the issue is on your computer, but it definitely doesn't take my computer 500ms to register a key press in VisiData in the general case. That would be an issue I'd have to take seriously. I've spent way too much time optimizing VisiData's startup time to be under 300ms to let something like that slide. It's a point of pride for me that VisiData doesn't incorporate that "web GUI bloat" as you mention. If you're willing to help out, please contact me so we can file an informative issue and see if we can figure out what's going on in your setup. I have a hunch it's generalized computer/OS bloat that we (VisiData) can't do anything about, but at least we can try to understand it so that hand-crafted software like VisiData isn't unnecessarily maligned.
contrarian1234 2y ago
I think it's a general issue of developers with tricked out machines and fast internet connections developing software for everyone else. The reason the CLI is fast is not because it was carefully engineered that way, but because most of the software was developed when computers were slower than the chip you'd find in a washing-machine these days example: flatpak. Last I tried - tab-outcompleting to install a package makes a network request for the application list. This ofcourse means you don't have to maintain a cache like `apt` and certainly makes things easier. I'm sure this makes sense if you're on your macbook pro in a cafe in Cupertino. But it was nearly unusable (whole CLI locks up and hangs) from my Core m3 computer tethered to a shitty network in a 2nd tier city in China.
- pxc 2y ago
  > I think it's a general issue of developers with tricked out machines and fast internet connections developing software for everyone else. The reason the CLI is fast is not because it was carefully engineered that way, but because most of the software was developed when computers were slower than the chip you'd find in a washing-machine these days. I think in the context of the ongoing 'CLI renaissance', what this misses is that many of the most recognizable tools which emerge from (or perhaps kicked off) the contemporary 'CLI renaissance' are very carefully engineered with performance in mind. Ripgrep is, to me, the most vital of all the 'next-gen' CLI programs. GNU grep is already incredibly fast, and ripgrep manages to be faster, to take common-sense shortcuts, to add in a few extra conveniences (like --replace, so you don't always need to pipe to sed or awk or whatever when you want to do a very simple transformation) without going nuts and losing focus. Its author, burntsushi, has written here on HN about their implementation as well as GNU grep's and other regex implementations, and it's clear that the predecessors have been studied with great care and respect. I love many newer CLI tools, and this pattern holds for all of them. Consider, for instance, `jq`, which has become a 21st-century complement to vital staples like awk. This is even the case for many tools whose purposes are largely 'cosmetic', like `bat`, which more or less exists to be a more performant replacement for older colorizers like `ccat`. As cringey as the buzzword 'blazing fast' has become, Rust CLI tools are typically in tune with the general cultural emphasis of speed in the Rust community. And many Go CLI tools today are rewrites or clones of Python or Ruby tools, which were written expressly to achieve improved performance. This also seems to hold for next-gen CLI environments: one of the main advancements most next-gen shells (e.g., Elvish, Nushell, Oil) offer over PowerShell (which introduced structured pipelines to the shell world) is performance! This doesn't mean that every single new CLI tool is well thought-out, or (if it has direct antecedents) better than its predecessors. But I don't think the idea that new CLI tools are generally written without care for performance or consideration of the past is borne out when you look at what's out there.
oulipo 2y ago
You conflate the fact that the CLI tool is just a "programmable API view" of an app, and that GUI is more of a "interaction view", with the fact that it can or cannot do some stuff Now with AI and better design, nothing in theory would prevent us to "script UI apps" like we do with terminal, you could say "take a screenshot of my webpage with Chrome | set it in isometric with nice shadow using Photoshop | send it on my iPhone Twitter app" and you would get the same pipeline of course "UI apps" just have too many input / output possibilities, and you wouldn't want to have "--flags" everywhere for every possibility But that's where "natural language as a universal API" applies, or perhaps just a better design for interaction with UI apps
- oulipo 2y ago
  in theory, if computers were really "smart" (and I'm not talking about AI, but just better design), you could define that pipeline and it would JIT-build an optimized binary that does the equivalent of your pipeline for each app, so that it would still be an optimized process Eg. each "UI app" would just become a big API of all input/output possibilities, and "interactive mouse / keyboard / visual interaction" would just be one possibility among others Your computer would know how to pipe between each app, optimize it if possible, and give you what you want
- anthk 2y ago
  KDE's Konqueror+Krita+a KDE3 twitter tool would be able to do that with DCOP, DBUS grandpa but for KDE3. Ditto with Haiku OS (and Be) with the 'Hey' tool: https://www.haiku-os.org/blog/humdinger/2017-11-05_scripting_the_gui_with_hey/ https://www.haiku-os.org/blog/humdinger/2017-11-05_scripting... On pure CLI tools, that's trivial with some of them sending commands to Chromium, piping the output to ImageMagick and using something like ttytter (now it wouldn't work with the API changes). Replace Twitter with Mastodon and I'm sure you could do that with 'toot'.
pjmlp 2y ago
Pretty much so, I really don't get those rainbow terminals full of fluff running after each command. Then to top that, we had TUIs up to the mid-1990's because we couldn't afford anything else, it was the best many of us could have, given the bugdet and the astronomical cost of anything with a graphics display attached to the computer. I really don't get the coolness of reproducing this experience, I was more than happy to move away from this as soon as I could afford to.
Zababa 2y ago
I don't think this is what the article says, and I don't think terminals are getting "ruined". The trend of TUi is a bit worrying (usually you get a better looking but worse GUI), but the tools are great. fzf is great, fd is great, rg is great. Some TUIs are great too, lazygit and lazydocker being good examples. > The reason why the CLI is good is because it _can't_ do most things people want it to do. Which means you have to think when making an application. I don't think this is true at all. If I had to say why the CLI is good, I would mention: - speed - composability, as in I can grep for something and then do other operations - ease of development, it's very easy to make a small tool for my usage
poincaredisk 2y ago
>The people who ruined native GUIs moved to HTML pages. After ruining HTML pages they are now moving to terminals. I know this is just (probably) a figure of speech, but I really don't like this way of writing. This has strong "us vs them" vibes. There is no team of people actively working on ruining GUI, HTML and now terminals, over the last 30 years. There are just people who have different tastes than you and I. I find this approach more productive.

kvark 2y ago

Having a standard CLI is definitely helpful. But does it have to be so hard to use? At what point would we acknowledge that we are being hostage by some random ideas put into ancient software, which just happened to survive? I don't think calling for a stop of experimentation is the way. Nobody is going to take away your vi and bash any time soon.

immibis 2y ago
We shouldn't be held hostage, but the evolution of interactive CLIs is GUIs and the evolution of batch CLIs is scripting languages, and we don't need to render the CLI concept meaningless by integrating both. I've seen a terminal emulator that supported pixel graphics - what's the point! Just make a GUI using your favorite framebuffer library! A TUI is not a CLI, either.

wiseowise 2y ago

> The reason why the CLI is good is because it _can't_ do most things people want it to do. -1. You’ve lost me here. The reason why CLI is good because it solves problems that even modern GUIs can’t, not because of some artificial limitations or lack of convenient defaults. > Which means you have to think when making an application. “Think” and “remember obscure syntax that greyheads keep on a paper under their mattress” are two different things. I agree with the author that sensible defaults are severely lacking from some of the tools.

ulbu 2y ago
one great property of the terminal is that it’s not a continuous canvas. it’s a grid of discrete cells, just as it is natural for computers to be. instead of laying interactive objects out in virtual space, you’re pushed to think in discrete states and discrete actions. so I say cli is, indeed, good in part due of its limitations. edit: i’ll add that continuousness of guis is actually its limitation. a terminal interface is indexable, a gui is not. so what looks like freedom is actually a different structure. a gui is more general, as real numbers are more general than whole numbers. but to get to whole numbers, you have to re-constrain real numbers. this is left up to the developer to create a constraining framework. and it’s a path of less resistance to not do this. most data we deal with is discrete. so a continuous representation of it is a mismatch of structures. terminals force you to stay in that same discrete space. so your solutions are from the getgo closer in fit to your data. it’s important to match up the structure of your interactive surface with the structure of your domain. it’s a common principle we talk about too little.
- cdrini 2y ago
  I think that's it, although I don't think I'd describe it as a grid, but as a 1d list. The core concept of CLIs is linear. That's in part why streaming works so effectively in CLIs, because the linear medium clicks really well with the idea of streaming data. And actually the fact that a lot of UNIX commands actually operate on a graph of sorts under-the-hood is where you can see some of the limitations of this linear approach (eg trying to pipe one stream to multiple paths with each path having its own processing requires a branch which is inherently a little difficult to represent in a linear system). You can lay things out in a grid, but the same can be said of GUIs. You can consider each character a cell in a grid, but I think that's so small that at that point it's not conceptually sufficiently different from being continuous. The computational paradigm that's a grid at its core is spreadsheets.
deleted 2y ago
[deleted]
oulipo 2y ago
Exactly, they conflate the fact that the CLI tool is just a "programmable API view" of an app, and that GUI is more of a "interaction view", with the fact that it can or cannot do some stuff Now with AI and better design, nothing in theory would prevent us to "script UI apps" like we do with terminal, you could say "take a screenshot of my webpage with Chrome | set it in isometric with nice shadow using Photoshop | send it on my iPhone Twitter app" and you would get the same pipeline of course "UI apps" just have too many input / output possibilities, and you wouldn't want to have "--flags" everywhere for every possibility But that's where "natural language as a universal API" applies, or perhaps just a better design for interaction with UI apps

lifthrasiir 2y ago

The terminal is valuable just because it has applications that are easy to do or even only possible in it. Specifically, a full-duplex interactivity at a low data rate. I don't think any current "modernization" proposals threatened that so far, the biggest contender would be any image support but it isn't meant to be used every time anyway.

flohofwoe 2y ago
TBH I would love a pixel framebuffer standard for terminals that's fast enough to run things like Doom, emulators, or simple UI applications in the terminal. The Sixels standard exists but has a too complicated pixel encoding.
- immibis 2y ago
  That's every GUI system, though. /dev/fb0, or X11. We don't have to force it to fit into a character stream abstraction for some silly reason. Different abstractions are allowed to be different.

hnlmorg 2y ago

As someone who is working on modernizing the command line, I think it is entirely possible to strike a balance. - the command line is just byte streams Shells like Elvish, Nushell, Powershell and my own shell, Murex, support typed pipelines and that brings a great number of enhancements. Like native support for JSON, CSV and other data formats. Thus meaning you can have a unified syntax for handling different files rather than remembering a dozen different tools and their specific idiosyncrasies, eg `jq`, `awk`, etc - readline is dated We can do better than the typical shell interface. The popularity of tools like `fzf` and `starship` show that people do actually find modern TUIs useful - rendered text is static Lets say you view a JSON file in Firefox, you can expand and collapse specific branches of that JSON file. I'd love to be able to do that with JSON in the terminal. And not just JSON, tools like `tree` could benefit from that too. Collapsible trees is a feature I'm working on implementing in my terminal emulator and it's completely optional. ie by default the tree renders the same way any other terminal would render that clump of text. Except you can then optionally collapse branches just like you can with code in an IDE or comments in HN. --- I love the command line. I've been using it for 30+ years and written so many tools for fellow CLI enthusasts. But even I think an ideal world would be us moving away from grid based virtual teletype interfaces pushing communicating via raw bytes and with in-band control codes, and instead switch to something more robust. But that's never going to happen. Heck, even things like job control (ie when you hit ^z) is non-trivial to implement at a shell level. It requires multiple signals (each originating from a different sender), and 3 different hierarchies of process ID registration. Frankly, it's amazing any of this stuff still works. And that's before we touch on the plethora of competing standards to test what client (ie terminal emulator) is connected to that "virtual typewriter".

aragilar 2y ago
But how many of these new tools are robust when there's high latency? The advantage of good old POSIX shell is it works on cheap routers, the latest HPC systems, the system next to me and the system of the literal other side of the world, and everything in between.
- maccard 2y ago

tazu 2y ago

This is why Textualize[1] concerns me. I've tried a few of the applications using their framework, and they have noticable keypress latency. I didn't think it was possible to make a bloated TUI, but they have somehow succeeded. This might just be a Python thing because of the GIL, because VisiData[2] has the same problem. It's physically jarring to use VisiData because it's such a cool idea, but takes 500ms to register key presses in my 120hz terminal emulator. It's reminiscent of scroll-jacking, excessive animation, and other web GUI bloat, just translated to TUIs. [1]: https://www.textualize.io/ https://www.textualize.io/ [2]: https://www.visidata.org/ https://www.visidata.org/

saulpw 2y ago
(Author of VisiData here) I don't know what the issue is on your computer, but it definitely doesn't take my computer 500ms to register a key press in VisiData in the general case. That would be an issue I'd have to take seriously. I've spent way too much time optimizing VisiData's startup time to be under 300ms to let something like that slide. It's a point of pride for me that VisiData doesn't incorporate that "web GUI bloat" as you mention. If you're willing to help out, please contact me so we can file an informative issue and see if we can figure out what's going on in your setup. I have a hunch it's generalized computer/OS bloat that we (VisiData) can't do anything about, but at least we can try to understand it so that hand-crafted software like VisiData isn't unnecessarily maligned.

contrarian1234 2y ago

I think it's a general issue of developers with tricked out machines and fast internet connections developing software for everyone else. The reason the CLI is fast is not because it was carefully engineered that way, but because most of the software was developed when computers were slower than the chip you'd find in a washing-machine these days example: flatpak. Last I tried - tab-outcompleting to install a package makes a network request for the application list. This ofcourse means you don't have to maintain a cache like `apt` and certainly makes things easier. I'm sure this makes sense if you're on your macbook pro in a cafe in Cupertino. But it was nearly unusable (whole CLI locks up and hangs) from my Core m3 computer tethered to a shitty network in a 2nd tier city in China.

pxc 2y ago
> I think it's a general issue of developers with tricked out machines and fast internet connections developing software for everyone else. The reason the CLI is fast is not because it was carefully engineered that way, but because most of the software was developed when computers were slower than the chip you'd find in a washing-machine these days. I think in the context of the ongoing 'CLI renaissance', what this misses is that many of the most recognizable tools which emerge from (or perhaps kicked off) the contemporary 'CLI renaissance' are very carefully engineered with performance in mind. Ripgrep is, to me, the most vital of all the 'next-gen' CLI programs. GNU grep is already incredibly fast, and ripgrep manages to be faster, to take common-sense shortcuts, to add in a few extra conveniences (like --replace, so you don't always need to pipe to sed or awk or whatever when you want to do a very simple transformation) without going nuts and losing focus. Its author, burntsushi, has written here on HN about their implementation as well as GNU grep's and other regex implementations, and it's clear that the predecessors have been studied with great care and respect. I love many newer CLI tools, and this pattern holds for all of them. Consider, for instance, `jq`, which has become a 21st-century complement to vital staples like awk. This is even the case for many tools whose purposes are largely 'cosmetic', like `bat`, which more or less exists to be a more performant replacement for older colorizers like `ccat`. As cringey as the buzzword 'blazing fast' has become, Rust CLI tools are typically in tune with the general cultural emphasis of speed in the Rust community. And many Go CLI tools today are rewrites or clones of Python or Ruby tools, which were written expressly to achieve improved performance. This also seems to hold for next-gen CLI environments: one of the main advancements most next-gen shells (e.g., Elvish, Nushell, Oil) offer over PowerShell (which introduced structured pipelines to the shell world) is performance! This doesn't mean that every single new CLI tool is well thought-out, or (if it has direct antecedents) better than its predecessors. But I don't think the idea that new CLI tools are generally written without care for performance or consideration of the past is borne out when you look at what's out there.

oulipo 2y ago

You conflate the fact that the CLI tool is just a "programmable API view" of an app, and that GUI is more of a "interaction view", with the fact that it can or cannot do some stuff Now with AI and better design, nothing in theory would prevent us to "script UI apps" like we do with terminal, you could say "take a screenshot of my webpage with Chrome | set it in isometric with nice shadow using Photoshop | send it on my iPhone Twitter app" and you would get the same pipeline of course "UI apps" just have too many input / output possibilities, and you wouldn't want to have "--flags" everywhere for every possibility But that's where "natural language as a universal API" applies, or perhaps just a better design for interaction with UI apps

oulipo 2y ago
in theory, if computers were really "smart" (and I'm not talking about AI, but just better design), you could define that pipeline and it would JIT-build an optimized binary that does the equivalent of your pipeline for each app, so that it would still be an optimized process Eg. each "UI app" would just become a big API of all input/output possibilities, and "interactive mouse / keyboard / visual interaction" would just be one possibility among others Your computer would know how to pipe between each app, optimize it if possible, and give you what you want
anthk 2y ago
KDE's Konqueror+Krita+a KDE3 twitter tool would be able to do that with DCOP, DBUS grandpa but for KDE3. Ditto with Haiku OS (and Be) with the 'Hey' tool: https://www.haiku-os.org/blog/humdinger/2017-11-05_scripting_the_gui_with_hey/ https://www.haiku-os.org/blog/humdinger/2017-11-05_scripting... On pure CLI tools, that's trivial with some of them sending commands to Chromium, piping the output to ImageMagick and using something like ttytter (now it wouldn't work with the API changes). Replace Twitter with Mastodon and I'm sure you could do that with 'toot'.

pjmlp 2y ago

Pretty much so, I really don't get those rainbow terminals full of fluff running after each command. Then to top that, we had TUIs up to the mid-1990's because we couldn't afford anything else, it was the best many of us could have, given the bugdet and the astronomical cost of anything with a graphics display attached to the computer. I really don't get the coolness of reproducing this experience, I was more than happy to move away from this as soon as I could afford to.

Zababa 2y ago

I don't think this is what the article says, and I don't think terminals are getting "ruined". The trend of TUi is a bit worrying (usually you get a better looking but worse GUI), but the tools are great. fzf is great, fd is great, rg is great. Some TUIs are great too, lazygit and lazydocker being good examples. > The reason why the CLI is good is because it _can't_ do most things people want it to do. Which means you have to think when making an application. I don't think this is true at all. If I had to say why the CLI is good, I would mention: - speed - composability, as in I can grep for something and then do other operations - ease of development, it's very easy to make a small tool for my usage

poincaredisk 2y ago

>The people who ruined native GUIs moved to HTML pages. After ruining HTML pages they are now moving to terminals. I know this is just (probably) a figure of speech, but I really don't like this way of writing. This has strong "us vs them" vibes. There is no team of people actively working on ruining GUI, HTML and now terminals, over the last 30 years. There are just people who have different tastes than you and I. I find this approach more productive.