4 ms·

> Modern PCs being insanely fast doesn't mean we have to use software that requires insanely fast computers. Never claimed that, but efficient software doesn't

by Crinus 7y ago

> Modern PCs being insanely fast doesn't mean we have to use software that requires insanely fast computers. Never claimed that, but efficient software doesn't imply 70s terminal UIs.

rocqua 7y ago
Screen, tmux, vim, emacs, ncurses. None of these are 70s products. Nor do they optimize for 70s performance limitations. They are modern terminal UIs. We pick terminal UIs because the terminal tends to expose a lot more features than a gui. This tendency is probably because it is easier to add features to a tui than to a gui. Then there is a kind of self reinforcing effect where people like working within similar paradigms, and people get used to TUIs in general. This makes those people prefer making TUIs over GUIs even more. Incidentally, it is mostly developers who tend to need the more powerful features currently only offered in a TUI.
- Crinus 7y ago
  They are not 70s products but they look like 70s products. See my original comment about how those TUIs look and feel worse than programs you'd see in DOS despite having a lot more power and features available to them - even if you confine yourself to the basic colors (but many modern terminals also support -simple, yet usable- graphics, more colors and more characters). > Then there is a kind of self reinforcing effect where people like working within similar paradigms, and people get used to TUIs in general. Yes, it is basically a matter of fashion and what baffles me is that fashion. I mean, even if you consider that terminal-based applications are great, why limit yourself to what a beefed up VT100 could do? Why when typing "ls" not also have a tiny folder icon near the directories (you are already going into the hassle of adding colors anyway, a little icon would make it more obvious which are folders and which are files when you are looking at a huge list), why not having a command akin to "cat" that can decode and display image files right in the terminal, why not have an over-time graph in "perf"'s realtime TUI mode, Emacs already supports different font sizes when running as a GUI program, why not have this in terminal mode too, Clang's static analyzer can show you data flow-based errors, why not have graphical arrows superimposed over your syntax highlighted code when you run it from the terminal (Xcode already does that but it is a GUI), etc. These are just some examples from the top of my head, i'm sure i can come up with even more. I think by using only text-based UIs people get used to text-based UIs and all they can imagine is within the limitations of text-based UIs.
  - saltminer 7y ago
    > They are not 70s products but they look like 70s products I'm not sure how you could have a TUI that didn't look old. For serious applications, you have to build TUIs assuming the worst - that the user has no colors or special keys. Sure, some terminals can display bitmapped images with 24-bit color, but you can't depend on that, especially for anything running over SSH or within Tmux, screen, emacs, (neo)vim, or some combination of these. These can create some very obscure bugs related to colors and keybindings, so you can't assume every key will work as expected or that your users will have color at all (I disable Vim syntax highlighting over SSH because it tends to demolish its performance, for example). This is why many TUIs are 16-color and use just ASCII characters - you don't know if the user can display emojis or if it'll show up as a garbled mess. GUI applications (including text-based ones like gVim and emacs) have a lot more flexibility because they can control more than they can in a terminal and can guarantee 8- or 24-bit color instead of having to hope for 16-color support. > Why when typing "ls" not also have a tiny folder icon near the directories (you are already going into the hassle of adding colors anyway, a little icon would make it more obvious which are folders and which are files when you are looking at a huge list) That would probably break a lot of scripts. I just alias "l" to "ls -l" so I can see the permissions (which has a "d" to indicate directories).
    - Crinus 7y ago
      > For serious applications, you have to build TUIs assuming the worst - that the user has no colors or special keys. Realistically, what are the chances of this happening nowadays and how worth is it supporting such users? > That would probably break a lot of scripts. If an icon would break scripts, so would having colors, but it doesn't since ls knows when it outputs to a terminal or to a pipe and adjusts the output accordingly. But this misses the point, it could be another commands like vls (visual ls) or whatever, the point is the ability to use more than ASCII text. > I just alias "l" to "ls -l" so I can see the permissions (which has a "d" to indicate directories). An icon is more distinguishable from a single letter and using the -l view would not take advantage of any horizontal space you have.
    - ulisesrmzroche 7y ago

by Crinus 7y ago

> Modern PCs being insanely fast doesn't mean we have to use software that requires insanely fast computers. Never claimed that, but efficient software doesn't imply 70s terminal UIs.

rocqua 7y ago

Screen, tmux, vim, emacs, ncurses. None of these are 70s products. Nor do they optimize for 70s performance limitations. They are modern terminal UIs. We pick terminal UIs because the terminal tends to expose a lot more features than a gui. This tendency is probably because it is easier to add features to a tui than to a gui. Then there is a kind of self reinforcing effect where people like working within similar paradigms, and people get used to TUIs in general. This makes those people prefer making TUIs over GUIs even more. Incidentally, it is mostly developers who tend to need the more powerful features currently only offered in a TUI.

Crinus 7y ago
They are not 70s products but they look like 70s products. See my original comment about how those TUIs look and feel worse than programs you'd see in DOS despite having a lot more power and features available to them - even if you confine yourself to the basic colors (but many modern terminals also support -simple, yet usable- graphics, more colors and more characters). > Then there is a kind of self reinforcing effect where people like working within similar paradigms, and people get used to TUIs in general. Yes, it is basically a matter of fashion and what baffles me is that fashion. I mean, even if you consider that terminal-based applications are great, why limit yourself to what a beefed up VT100 could do? Why when typing "ls" not also have a tiny folder icon near the directories (you are already going into the hassle of adding colors anyway, a little icon would make it more obvious which are folders and which are files when you are looking at a huge list), why not having a command akin to "cat" that can decode and display image files right in the terminal, why not have an over-time graph in "perf"'s realtime TUI mode, Emacs already supports different font sizes when running as a GUI program, why not have this in terminal mode too, Clang's static analyzer can show you data flow-based errors, why not have graphical arrows superimposed over your syntax highlighted code when you run it from the terminal (Xcode already does that but it is a GUI), etc. These are just some examples from the top of my head, i'm sure i can come up with even more. I think by using only text-based UIs people get used to text-based UIs and all they can imagine is within the limitations of text-based UIs.
- saltminer 7y ago
  > They are not 70s products but they look like 70s products I'm not sure how you could have a TUI that didn't look old. For serious applications, you have to build TUIs assuming the worst - that the user has no colors or special keys. Sure, some terminals can display bitmapped images with 24-bit color, but you can't depend on that, especially for anything running over SSH or within Tmux, screen, emacs, (neo)vim, or some combination of these. These can create some very obscure bugs related to colors and keybindings, so you can't assume every key will work as expected or that your users will have color at all (I disable Vim syntax highlighting over SSH because it tends to demolish its performance, for example). This is why many TUIs are 16-color and use just ASCII characters - you don't know if the user can display emojis or if it'll show up as a garbled mess. GUI applications (including text-based ones like gVim and emacs) have a lot more flexibility because they can control more than they can in a terminal and can guarantee 8- or 24-bit color instead of having to hope for 16-color support. > Why when typing "ls" not also have a tiny folder icon near the directories (you are already going into the hassle of adding colors anyway, a little icon would make it more obvious which are folders and which are files when you are looking at a huge list) That would probably break a lot of scripts. I just alias "l" to "ls -l" so I can see the permissions (which has a "d" to indicate directories).
  - Crinus 7y ago
    > For serious applications, you have to build TUIs assuming the worst - that the user has no colors or special keys. Realistically, what are the chances of this happening nowadays and how worth is it supporting such users? > That would probably break a lot of scripts. If an icon would break scripts, so would having colors, but it doesn't since ls knows when it outputs to a terminal or to a pipe and adjusts the output accordingly. But this misses the point, it could be another commands like vls (visual ls) or whatever, the point is the ability to use more than ASCII text. > I just alias "l" to "ls -l" so I can see the permissions (which has a "d" to indicate directories). An icon is more distinguishable from a single letter and using the -l view would not take advantage of any horizontal space you have.
  - ulisesrmzroche 7y ago