5 ms·

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, t

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?

consp 8mo ago
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.
vanviegen 8mo ago
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.
- robinsonb5 8mo ago
  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.
  - iberator 8mo ago
    there is TCL-TK. :) Super easy to use, fast, almost zero ram usage and battle tested for 2 decades.
    - robinsonb5 8mo ago
      "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! ;)
      - ux266478 8mo ago
        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.
        NoGravitas 8mo ago
        I'd say it's easily the least bad of the bunch, anyway, if you're really committed to cross-platform.
  - skydhash 8mo ago
    Make the core feature of your app a library, then write different interfaces according to the targeted platforms.
hnlmorg 8mo ago
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.
tezza 8mo ago
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.
- anthk 8mo ago
  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.
  - wredcoll 8mo ago
    Sure, I get the theory, so why doesn't exist? Where's my modern text/command based interface?
    - anthk 8mo ago
      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.
mr_toad 8mo ago
> 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.
- ale42 8mo ago
  > 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.
  - pferde 8mo ago
    Calm down, they wrote "can", not "should".
eigenspace 8mo ago
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.
duskdozer 7mo ago
I'm not sure I understand - if you could have your way everything would be a GUI and no CLI? Or just terminals in their current form are not good?

consp 8mo ago

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.

vanviegen 8mo ago

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.

robinsonb5 8mo ago
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.
- iberator 8mo ago
  there is TCL-TK. :) Super easy to use, fast, almost zero ram usage and battle tested for 2 decades.
  - robinsonb5 8mo ago
    "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! ;)
    - ux266478 8mo ago
      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.
      - NoGravitas 8mo ago
        I'd say it's easily the least bad of the bunch, anyway, if you're really committed to cross-platform.
- skydhash 8mo ago
  Make the core feature of your app a library, then write different interfaces according to the targeted platforms.

hnlmorg 8mo ago

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.

tezza 8mo ago

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.

anthk 8mo ago
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.
- wredcoll 8mo ago
  Sure, I get the theory, so why doesn't exist? Where's my modern text/command based interface?
  - anthk 8mo ago
    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.

mr_toad 8mo ago

> 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.

ale42 8mo ago
> 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.
- pferde 8mo ago
  Calm down, they wrote "can", not "should".

eigenspace 8mo ago

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.

duskdozer 7mo ago

I'm not sure I understand - if you could have your way everything would be a GUI and no CLI? Or just terminals in their current form are not good?