4 ms·

I like command-lines. I don't like TUIs. Here's the litmus test for whether a program truly belongs there: Would it shit the bed if its stdout was a printer?

TeMPOraL 8y ago
So you edit with ed? :). Also anything wrapped inside tmux would definitely defecate if hooked up to printer. Some jobs are interactive. TUIs ain't bad for those.
- OJFord 8y ago
  > Some jobs are interactive. TUIs ain't bad for those. Exactly. A printer is an inappropriate output interface for an interactive job, it's not the input interface that's at fault.
- scarmig 8y ago
  That got to me brainstorming what someone might do if they were trying to write a modern line editor, targeting developers writing in... maybe not Java, but perhaps Go. It doesn't seem like anyone has tried to build anything like that before. Most recent seems to be Rob Pike's sam from the 1980s, which (at one time in the 2000s at least) was the professed favored programming tool by Brian Kernighan and Bjarne Stroustrup.
  - jgtrosh 8y ago
    I have an intuition that any line editor would find its limits quite fast for most existing code. (After having used ed a bit on regular files I came across, it's often both surprisingly useful and surprisingly obtuse compared with Vim.) Now, maybe a semantic structured language would find an amazing CLI editor. I'm vaguely thinking something like a lisp, or something with tagged structures. I guess the goal would be repurposing Vim's text objects to generic programming structures. That's as much as I can muster right now!
- JonathonW 8y ago
  If it "defecates if hooked up to a printer", it's not going to be useful in a Unix-style text pipeline, either. So, what benefit do applications like emacs or vim (which are, fundamentally, keyboard-driven GUI applications, even if they're running in text-mode) gain by being stuck in a terminal? It's a simple least-common-denominator that's easy to push over a slow SSH connection, but why wouldn't I want to relax some of those limitations when I'm working locally?
  - TeMPOraL 8y ago
    Vim benefits from being in a terminal because you can use things like tmux to improve its workflow. Terminal Emacs can be used like this too, but Emacs can also handle this by itself - its philosophy is actually the opposite. Emacs will consume the stuff you're doing in terminal, but in a much deeper way than other GUI editors/IDEs. Simple least-common-denominator SSH-style workflow is actually a feature for devops/sysadmins, so that's why I believe you'll find a disproportionate amount of them favouring vim. In Emacs, you can relax limitations of a terminal, while benefiting from its text-based design that enables heavy interoperability and ergonomic workflow (and then you discover that terminal Emacs retains 95% of those features anyway, so you can get them over SSH too).
deleted 8y ago
[deleted]
agumonkey 8y ago
reminds me my litmus test for website design: elinks we should have a curated litmus list.. listmus.com
- enriquto 8y ago
  an elinks lover here! It is an amazing web browser.
da_chicken 8y ago
I was going to disagree with you, but after thinking about it I don't think I do. Vim is a great program that would completely shit the bed if stdout was a printer. However, vim's interface is shit, regardless of how well it works after using it long enough. It's notoriously hard to learn, and the vast majority of non-programming users, IMX, know enough to open a file, make a modification, and save it. Vim would be better if it had a GUI (one more extensive than gVim); that's exactly why SublimeText, Atom, Visual Studio Code, etc. are all so popular. They're vim (they all have vim key extensions), but with the GUI that makes them easier to learn and use. No, they don't have a perfect analog for that one super obscure feature that only you ever use even though you tell other people how great it is all the time, but that's because they're newer programs with fewer features, not because they have a worse interface. Even programs like top really work better as a GUI. Being able to sort and scroll the list easily, or get contextual information from a process with the mouse is better. Top is good, but it's limited, and not a substitute for a more complete process monitor.
- haolez 8y ago
  You are missing the point. How do you integrate existing programs into a new program using GUIs? Terminals and text are great for that.
- rhinoceraptor 8y ago
  top would be good to have as a GUI, but I think 99% of people would prefer not to have X11 running on their servers, not least because of how insecure it is. Also, a surprising amount of TUI apps do have at least some mouse support. Sure, it will never be as good as a GUI app since you can't scroll by less than one row, and depending on the terminal the responsiveness for resizing isn't great, but it is there when you want it. Also, one of my favorite things in vim is splits. Whenever I use GUI editors the split support seems to be very bad. Some of the Mac OS editors are at least meant to be used with multiple windows, but I think that philosophy of the desktop metaphor is dying out and people are just writing apps to be used full screen.
toast0 8y ago
Do people write programs that work like that anymore? I guess there is Linux's make config, but make menuconfig seemed so much faster. Basically, text adventures for doing productive tasks, doesn't sound very productive to me, but I'd love to be wrong.
- jgtrosh 8y ago
  TUI text editors, debuggers, pagers, music players are still very much used, if maybe not very actively developed. I guess even style escape codes would break line printers? This would discard a vast amount of tools I personally use daily. I would be happy to receive UNIX-philosophy arguments, but until such tools that bring the same functionality appear, TUIs are often the best of all worlds for me.
  - toast0 8y ago
    Most of the debuggers I use would be fine with a line printer, at the level of sophistication I'm capable of using them. A pager would be ok, as long as you're using more and not less. I use plenty of interactive tools in a terminal, but almost all of them are screen oriented, very few are line oriented. I would say the distinguishing thing to make something usable on a printer / a real teletype is that the paper only moves in one direction.
richardjdare 8y ago
The Amiga was like that. It didn't physically have a text mode, so there was no point to TUIs. The console (a GUI app that displayed text) was primarily command based. Anything screen oriented (even the first version of Vim) was a GUI app. I kinda wish we'd move beyond the GUI/text dichotomy. I wish we had something more like the Listener on Symbolics Lisp Machines, which could show rich text and images, forms, clickable elements etc from within a console environment.

TeMPOraL 8y ago

So you edit with ed? :). Also anything wrapped inside tmux would definitely defecate if hooked up to printer. Some jobs are interactive. TUIs ain't bad for those.

OJFord 8y ago
> Some jobs are interactive. TUIs ain't bad for those. Exactly. A printer is an inappropriate output interface for an interactive job, it's not the input interface that's at fault.
scarmig 8y ago
That got to me brainstorming what someone might do if they were trying to write a modern line editor, targeting developers writing in... maybe not Java, but perhaps Go. It doesn't seem like anyone has tried to build anything like that before. Most recent seems to be Rob Pike's sam from the 1980s, which (at one time in the 2000s at least) was the professed favored programming tool by Brian Kernighan and Bjarne Stroustrup.
- jgtrosh 8y ago
  I have an intuition that any line editor would find its limits quite fast for most existing code. (After having used ed a bit on regular files I came across, it's often both surprisingly useful and surprisingly obtuse compared with Vim.) Now, maybe a semantic structured language would find an amazing CLI editor. I'm vaguely thinking something like a lisp, or something with tagged structures. I guess the goal would be repurposing Vim's text objects to generic programming structures. That's as much as I can muster right now!
JonathonW 8y ago
If it "defecates if hooked up to a printer", it's not going to be useful in a Unix-style text pipeline, either. So, what benefit do applications like emacs or vim (which are, fundamentally, keyboard-driven GUI applications, even if they're running in text-mode) gain by being stuck in a terminal? It's a simple least-common-denominator that's easy to push over a slow SSH connection, but why wouldn't I want to relax some of those limitations when I'm working locally?
- TeMPOraL 8y ago
  Vim benefits from being in a terminal because you can use things like tmux to improve its workflow. Terminal Emacs can be used like this too, but Emacs can also handle this by itself - its philosophy is actually the opposite. Emacs will consume the stuff you're doing in terminal, but in a much deeper way than other GUI editors/IDEs. Simple least-common-denominator SSH-style workflow is actually a feature for devops/sysadmins, so that's why I believe you'll find a disproportionate amount of them favouring vim. In Emacs, you can relax limitations of a terminal, while benefiting from its text-based design that enables heavy interoperability and ergonomic workflow (and then you discover that terminal Emacs retains 95% of those features anyway, so you can get them over SSH too).

deleted 8y ago

[deleted]

agumonkey 8y ago

reminds me my litmus test for website design: elinks we should have a curated litmus list.. listmus.com

enriquto 8y ago
an elinks lover here! It is an amazing web browser.

da_chicken 8y ago

I was going to disagree with you, but after thinking about it I don't think I do. Vim is a great program that would completely shit the bed if stdout was a printer. However, vim's interface is shit, regardless of how well it works after using it long enough. It's notoriously hard to learn, and the vast majority of non-programming users, IMX, know enough to open a file, make a modification, and save it. Vim would be better if it had a GUI (one more extensive than gVim); that's exactly why SublimeText, Atom, Visual Studio Code, etc. are all so popular. They're vim (they all have vim key extensions), but with the GUI that makes them easier to learn and use. No, they don't have a perfect analog for that one super obscure feature that only you ever use even though you tell other people how great it is all the time, but that's because they're newer programs with fewer features, not because they have a worse interface. Even programs like top really work better as a GUI. Being able to sort and scroll the list easily, or get contextual information from a process with the mouse is better. Top is good, but it's limited, and not a substitute for a more complete process monitor.

haolez 8y ago
You are missing the point. How do you integrate existing programs into a new program using GUIs? Terminals and text are great for that.
rhinoceraptor 8y ago
top would be good to have as a GUI, but I think 99% of people would prefer not to have X11 running on their servers, not least because of how insecure it is. Also, a surprising amount of TUI apps do have at least some mouse support. Sure, it will never be as good as a GUI app since you can't scroll by less than one row, and depending on the terminal the responsiveness for resizing isn't great, but it is there when you want it. Also, one of my favorite things in vim is splits. Whenever I use GUI editors the split support seems to be very bad. Some of the Mac OS editors are at least meant to be used with multiple windows, but I think that philosophy of the desktop metaphor is dying out and people are just writing apps to be used full screen.

toast0 8y ago

Do people write programs that work like that anymore? I guess there is Linux's make config, but make menuconfig seemed so much faster. Basically, text adventures for doing productive tasks, doesn't sound very productive to me, but I'd love to be wrong.

jgtrosh 8y ago
TUI text editors, debuggers, pagers, music players are still very much used, if maybe not very actively developed. I guess even style escape codes would break line printers? This would discard a vast amount of tools I personally use daily. I would be happy to receive UNIX-philosophy arguments, but until such tools that bring the same functionality appear, TUIs are often the best of all worlds for me.
- toast0 8y ago
  Most of the debuggers I use would be fine with a line printer, at the level of sophistication I'm capable of using them. A pager would be ok, as long as you're using more and not less. I use plenty of interactive tools in a terminal, but almost all of them are screen oriented, very few are line oriented. I would say the distinguishing thing to make something usable on a printer / a real teletype is that the paper only moves in one direction.

richardjdare 8y ago

The Amiga was like that. It didn't physically have a text mode, so there was no point to TUIs. The console (a GUI app that displayed text) was primarily command based. Anything screen oriented (even the first version of Vim) was a GUI app. I kinda wish we'd move beyond the GUI/text dichotomy. I wish we had something more like the Listener on Symbolics Lisp Machines, which could show rich text and images, forms, clickable elements etc from within a console environment.