It's perennially baffling to me why we're still clinging to VT220/xterm compatible terminals. I even see people claiming they prefer working in the terminal, though it's not clear to me what type of work those people are doing.
Give me a proper graphical application any day, but I recognize that it's historically been a lot more work to produce a GUI in the pre-LLM era.
But golly gee whizz if we're going to keep the command line around, can we move on from 1983?
GUI apps are good for discoverability. They generally are not optimized for rapid use by power users though. That's of course not an inherent limitation of GUI apps, it's just that dominant paradigms hardly seem to consider power users.
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.
Another factor is the lack of a good cross-platform GUI toolkit (by which I mean one that (a) doesn't feel out-of-place and jarring on any platform and (b) doesn't turn a 50K app into a 1GB download.)
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.
there is TCL-TK. :)
Super easy to use, fast, almost zero ram usage and battle tested for 2 decades.
"Equally jarring and out-of-place on all platforms" isn't quite what I asked for, but I guess it's the next best thing! ;)
That hasn't been true for a while, it's easily the best of the bunch at this point. It's also always been trivial to change, which can't be said of the others.
I'd say it's easily the least bad of the bunch, anyway, if you're really committed to cross-platform.
Make the core feature of your app a library, then write different interfaces according to the targeted platforms.
Terminals are text. Text adds features missing from gui namely:
* 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.
Unix is not about a terminal, that the obsolete medium, kinda like preaching about DOS PC with 386's... and CGA video cards.
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.
Sure, I get the theory, so why doesn't exist? Where's my modern text/command based interface?
In 9front, a decades old fork of Plan9. It's basically more Unix than Unix itself, by expanding the 'everything it's a file motto' and now for real and leaving out useless VT220 emulators (and any TTY/serial emulating connections) for legacy stuff such as the 'vt' emulator itself running under a graphical window and, for instance, when running SSH against Unix machines sending you a PTY plus a shell.
Why? There is huge compatibility layer build on top of this and changing even these minor things will break stuff in places you do not expect. Want a fancy terminal? Install another one. By default most allow changing to many terminal formats. Break things to move forward is fun when it's not your problem to solve down the line.
Personally, I find a REPL-based programming interface to be the most flexible and powerful way to interact with code.
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.
Graphical applications are great if your workflow mirrors the workflow that the GUI was designed for. However if your workflow differs then you’ll often be fighting the GUI.
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.
> it's not clear to me what type of work those people are doing.
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.
> Anything that can be done in a terminal can be scripted and automated
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.
Calm down, they wrote "can", not "should".