I'm still annoyed and baffled by the fact that Ubuntu had searchable application menus 10 years ago, which were awesome and worked for just about any program, and then dropped them when they abandoned Unity. And neither KDE not Gnome thought to bring them back. In stead, many apps have since dropped application menus entirely, in favour of... some mishmash of icons and ad hoc menu buttons?
Also, even in the post-LLM era, building a decent GUI app is a lot more work than building a decent terminal app.
Between that and the level of complexity of modern GUI toolkits - and the size of their dependency trees - distribution of a GUI app is a much bigger headache than distributing a terminal app.
Super easy to use, fast, almost zero ram usage and battle tested for 2 decades.
* Ad Hoc
requirements change and terminal gives ultimate empty workbench flexibility. awesome for tasks you never new you had until that moment.
* Precision
run precisely what you want, when you want it. you are not constrained by gui UX limits.
* Pipeline
cat file.txt | perl/awk/sed/jq | tee output.result
* Equal Status
everything is text so you can combine clipboard, files, netcat output, curl output and then you can transform (above) and save. whatever you like in whatever form you like, named whatever you like.
9front copes with actual text throwing the terminal as a different tool to run legacy stuff in such as SSH or some small ANSI C tools either with the APE compat layer or NPE binding ANSI C code to Plan9 native functins.
You can resize windows with shells under 9front freely, no more SIGWINCH. No more broken cuts and pastes while running a terminal multiplexer. No control code risks executing potential malware.
My typical interface is that I have an editor open where I write package code, and then I have a julia REPL open beside it where I load the package (or includet the script or testset). Any changes I make with my editor to functions or structs in the package / script / testset are automatically reflected in my running julia session via Revise.jl.
I then execute the functions interactively from the REPL, introspect into data or generated code, debug, run benchmarks etc all from the REPL.
GUIs are great for many things, but they lack the flexibility I need for my day to day work.
Think of it like different types of programming languages. Some are more suited on different types of problems than others.
For me, my workflow is about composing and gluing different processes together rather than using a standard defined tool repeatedly in the same way as that tools UI was originally designed. So the CLI is ideally suited for me in all the areas where a GUI would be high friction.
As little as possible. Anything that can be done in a terminal can be scripted and automated, put under version control, and deployed using modern CI/CD and devops tools.
Sure, next time I'll need to quickly edit a configuration file I'll setup a complete CI/CD pipeline to run vim (or nano, or whatever) inside it.