1. 14
  1.  

  2. 19

    The fact we’re celebrating hackish extensions on top of TTYs is a sign of the myopia in our industry. We have all these great ways to render any kind of interface (even 1980’s bitmaps are an improvement), command line or not, and we just consider 1977 state of the art to be perfect.

    1. 9

      While I think it’s valid to criticize “back to the future” efforts to revitalize the command line instead of doing something new, I’d like to see more efforts to replicate the strengths of the command line in new UIs. I like this summary of the command line’s advantages:

      • Power of the keyboard — the keyboard allows for faster input than the alternation of keyboard & mouse usage.
      • Reproducibility — because all commands are text, they may be more easily reproduced and shared.
      • Composable commands — commands on the command line may be arbitrarily composed, using the output of one command as the input of another. This allows for powerful means of expression.
      • Scripting — the interactive session may be used as the basis for a script (a computer program), allowing for the automation of certain tasks.

      Any GUI that fulfilled these requirements as well as a TTY would be a force to be reckoned with, at least with the vital programmer demographic. You can see some successful efforts to bring these into the GUI world, such as Spotlight harnessing the power of the keyboard for desktop search, but generally this is underexplored territory IMHO.

      I’ll also echo @bsandro’s advantages of standardization, portability (between windowing systems and OSes), and remote connection (via SSH).

      In the absence of efforts to replicate the command line’s strengths, I will continue to invest time and energy into command line and TUI software.

      1. 7

        Command lines and GUIs aren’t a dichotomy - things from CLIM to Mathematica should make this known. Even within more commodity things, command palettes, AppleScript/Shortcuts/OSA, and the fact Windows is fully keyboard navigable make this already addressed.

        And as much as I don’t like Pike, I have to agree with his studies on keyboard and mouse, where the mouse was found to be actually faster, even if it didn’t feel like it. With newer HID, that leads to me swiping on the trackpad to switch workspaces instead of going for the keyboard. With future HID, who knows what’s next?

        1. 4

          and the fact Windows is fully keyboard navigable make this already addressed.

          I’m creating apps that enable faster interaction with medical software by using the Windows automation. I assure you this is not the case and I’m trying really hard to use the accessibility/Windows apis, before attempting to use keyboard, before resorting to “look for this and that field and click between them + about 5px to the right”. It’s uncommon, but still way more common than it should be.

        2. 3

          Any GUI that fulfilled these requirements as well as a TTY would be a force to be reckoned with…

          What about the Oberon interface, which was a very strong influence on Plan 9 and Acme? I’d say those are both GUIs that meet all of those requirements, with the possible exception of the first one (people have forked Acme and added more keyboard-only control but I’m not sure it caught on, possibly because that advantage isn’t really real).

          @calvin also pointed me at Apollo’s Domain/OS a while ago: there are some similar interface ideas in there too.

          … at least with the vital programmer demographic.

          That’s the problem, really. Within little niches, people are already using alternative interfaces. They just never make it to the mainstream as they aren’t compatible with the lowest common denominator.

        3. 7

          kinda sucks that rendering proportional fonts in a terminal today is at best a hack, too. I just really dislike reading monospace prose 😔

          1. 6

            I woke up one day and realised this, so now I run gtk+ emacs. There are upsides and no real downsides

            1. 5

              It’s depressing, isn’t it? Everyone would rather cosplay a 1970s mainframe wizard than consider what a 21st century interface could be.

              Well, not everyone. We also have people using GUI IDEs from the ‘90s. I don’t know what would be better but I think it’s a shame that nothing new has appeared for a while now.

              I wonder if we’re stuck at a lowest common denominator? I’ve seen some cool programming interfaces for Smalltalk but that’s no good unless you’re using Smalltalk. Are we stuck because everything has to be cross-platform and language-agnostic?

              1. 8

                One of the recent articles on here really resonated with me, about how desktop GUIs got lost after the advent of tablets fooled them into wanting to merge the two ways of interacting. It explains why there’s so much interest in terminals and 90s GUIs: we’re looking for things that fit laptops/desktops better than the current bad tablet-oriented compromises. Maybe we’re stuck in a dead-end, and by rewinding to GUIs that worked well, we can break out and start improving things again.

                1. 4

                  The “tabletification” tends to be overblown, and the retrofetishism started long before.

              2. 4

                It sounds like you consider more pixels to be better, or perhaps more arbitrary layouts of information.

                While the terminal isn’t perfect, it seems a lot of people find it very powerful and useful. I’d love to see your prototype of a better system. Would it be something like a Jupiter notebook for shell? Or what ?

                1. 4

                  Are bitmaps better though? I can’t think of a system that’s better than terminal for everything. (I’m excluding actual images of course) Specific cases, sure, but even though I’m using vscode, half the time I’ve got a terminal panel open inside it.

                  When things are outside the terminal, I normally run into this issue: how do I filter / reuse / compose this information? For example, I’ll take lshw / lspci over a Windows device info app because it’s so much more useful. Sure, we could do better and there are ideas like powershell and other shells that try to present structured outputs. I keep trying those and finding out they’re just not convenient enough to be worth switching.

                  I disagree that it’s an industry myopia - there’s a new project trying to improve the situation every week. None have really succeeded as far as I can tell. There’s a chance we’re really at the global maximum right now with the idea of “pretty text in a grid for interactive use + a flag for structured output + bitmaps for very specific things that require bitmaps”, yet we’re still able to constantly improve on that with various implementations.

                  1. 3

                    Specific cases, sure, but even though I’m using vscode, half the time I’ve got a terminal panel open inside it.

                    What if you could just execute a shell command from within VS Code? For example, suppose you could select any text in any tab or panel, then right-click and choose “Run in shell” or something similar. Then you’d get the result as editable text in a new tab. Or maybe you could select any text and pipe it into stdin for an arbitrary shell command, with an option to replace the selected text with the result. Or the selected text could be the arguments to a shell command. You’d get all the flexibility of textual commands and outputs, with all the ability to filter / reuse / compose results, but integrated into your editor, rather than having to copy & paste things to and from a separate terminal panel.

                    Maybe there’s a VS Code extension that does this, I have no idea. I just wonder if it’s really the terminal that you want, or is it the ability to compose commands and munge their output?

                    1. 4

                      I don’t think that would be helpful (for me). Issues: already too many tabs, how to handle interactive commands, how to handle binary input/output, how to handle command history, how to handle huge/streaming/ephemeral data? Also, previous output / task context wouldn’t be visible. Once in a while I do want the output in a tab… so I redirect to /tmp/foo and ctrl-click it in the terminal panel - solves 99% of what you describe without requiring a redo of the whole system.

                      Running the selection as a command already exists as “workbench.action.terminal.runSelectedText”.

                      or is it the ability to compose commands and munge their output?

                      This, but the new system would have to do it better than the plain terminal solution.

                      1. 2

                        I like that you call it “the plain terminal solution” - to me, embedding a whole terminal emulator seems much more complicated than the “plain” solution :)

                        Regarding the other issues, I’m not sure why the terminal solves any of them better than a normal text editor window - except the interactive commands, I guess. But I’m not trying to convince you of the merit of my entirely hypothetical vscode extension, just trying to work out if it’s really a terminal emulator that you want rather than specifically the ability to run and manipulate shell commands.

                        The article is about using terminal escape sequences to build TUIs, which seems like a weird thing to want in a panel inside a real GUI application like VS Code.

                        1. 1

                          I think there is another benefit that make the terminal more appealing than that hypothetical extension and I see it rarely mentioned. The command line offers a very strict chronological command/response interaction. A new command is placed at the bottom, older stuff moves up.

                          This means that I have a clear overview of history, with specific information of all the steps. This command resulted in that output. It also follows one thread of history per terminal. So while one can do things in parallel, nothing gets “lost” running in the background.

                          That historical overview is for instance what is missing from Jupiter notebooks and I find them always very confusing to work with when I need to do more than just follow the steps from top to bottom.

                          1. 4

                            I completely agree! Although I think that’s an argument against this sort of terminal interface…

                            The problem is the overloading of the word “terminal”. Although the article is called The Renaissance of the Command Line, it’s really more about TUIs: the ncurses style of interface that uses terminal escape sequences. Likewise, the top comment in this thread is about rendering interfaces using “hackish extensions on top of TTYs”. When you use that sort of interface, you lose your history in the terminal. You can’t scroll up and see exactly what that vim command did.

                            Obviously, you can’t “scroll up” and see exactly what that code or subl command did either. But since neither TUIs nor GUIs preserve terminal history, that’s obviously not an advantage for TUIs.

                            I sometimes use good old ed for sysadmin work, because it preserves the history. Then I really can scroll up and see a very clear audit log of this command resulted in that output.

                            I’m not against having a terminal window into which you can type commands: I still think that’s the best interface for many situations. I’m more questioning the utility of TUIs. Or, to put it another way, a “dumb” terminal is great, but should we really, in the 21st century, be building application interfaces on top of an emulated VT100?

                2. 6

                  As far as UI “common denominators” go CLI and TUI interfaces are really there imo: at least terminal standartization is present to some extent. Moreover between X Window System, Wayland, GDI and multitude of ui toolkits (motif, gtk, qt, winforms, you name it) the terminal is still the most consistent and stable user interface. The biggest change so far that I’ve seen was the ability to display actual images inside of certain terminal emulators and earlier - larger color palette support. The whole deal is limited to ansi/ascii/unicode and it helps quite a lot with compatibility and longevity.

                  Another important factor I think is that CLI/TUI works over extremely widespread and common SSH. Remote connect is still a big thing and all we got is incompatible protocols like RDP or VNC and because they’re somewhat flawed - a bunch of custom solutions like TeamViewer, AnyDesk or even radmin.

                  1. 5

                    Noting here that there is Sixel which lets you draw pretty much anything into the terminal, and almost all major terminals (including the venerable xterm) supports it. You can watch a movie (not character based like aalib, but true color pixel perfect) if that is what you want drawn on the terminal.

                    1. 2

                      Something that has struck out to me, and this may be because I am most definitely not a software engineer, is the whether the bigger question of “should you really include this library” is pondered. There are, of course, scenarios where the user experience is greatly improved by interactivity and having more visual bells and whistles, but examples such as Charm’s Gum’s conventional commits script beg, for me, the question of whether just writing a thing like that in pure Go (or even Bash if one is so inclined) would be better for all involved. It just feels like such examples may lead people to prematurely introduce bits and pieces that might not actually be needed.