Terminal Obsession
Most programmers do at least some of their work inside of a command-line terminal. There are some programs that are simply easier to make function in a command-line interface. One example of this would be programming. The read/eval/print loops found in most scripted programming languages are a type of interface that only really works on a command line because it is a kind of program that is operated specifically by issuing commands line by line.
What works exceptionally well is that because lines of text are used both as the input and the output of such programs, they can be easily chained together through process known as piping. A query program might output data on the state of a database, then a processing program will read the input and output a modified output, a formatting program will consume that input and output something that is readable to a human.
What is radical about this method, compared to the traditional way of gluing programs by means of APIs,1 is that gluing text mode programs together is effectively as simple as copying the output of one into the input of another — except it’s even simpler because piping is done automatically. The ability for a keen programmer to quickly automate a task without writing any kind of specialized code is a powerful one, and this ability is improved by the natural composability of text mode programs.
However…
The command line is usually not what is referenced when others speak of using the terminal.
Most users who “never leave the terminal” are not doing so to make use of powerful text processing/editing facilities. They use programs like “vi” or “emacs” that, while they do exist in a terminal, they primarily present their information within an interface more like a GUI — as the state of the program changes, text or box-drawing characters are printed onto any arbitrary part of the terminal per the rules of the program being used. Though they are presented through a text-based medium, these applications feel more akin to something like Dwarf Fortress.2
Based on my own time primarily using terminal-based applications, I would assume that the main appeal to the terminal is the perceived simplicity of it. It’s easy to imagine that an application that is concerned with drawing its state onto a character terminal should be simpler than an application that uses a GUI framework to display itself to the user. Unfortunately, it’s not true. Terminal libraries like “ncurses” are riddled with legacy code because they are ancient, and their goal to target old character terminals from the 70s is unchanged even today. Because of the surprising ubiquity of this particular implementation, it has created an expectation that many terminal-based applications support a number of features that in my opinion don’t really benefit the user — features like colorized output are implemented mostly as a matter of convention.
Worse still, is that by entirely forgoing text mode, these flashy terminal apps also forgo the biggest advantage to using the command-line over the GUI: composability. There is no way to compose these terminal-based applications with one another without emulating entire terminals within a terminal, and that approach becomes messy very quickly.3 Even so, the composability is meaningless as it’s only composability in UI presentation. All GUI apps can do this by sharing screen space, and it’s actually easier as they don’t need to fight for which app gets permission to render pixels onto the screen.
I think, ultimately, the team at Bell Labs made the right call by completely ignoring the terminal by instead focusing on how to improve the command-line. Editors like Sam and Acme were built specifically to leverage standard UNIXy utilities like “fmt” or “awk” to allow savvy users to take any arbitrary text they write and perform arbitrary computations in-place. Having once done my taxes like this — by piping some transaction data through awk to convert currencies — I found it much easier to get all the information organized and verified, and I was able to do some pretty specific accounting work without needing to spend a significant amount of time learning some kind of spreadsheet software. The composability of tools allowed me to transfer skills from one problem domain to another quite effortlessly.
I think it’s a shame it hasn’t caught on.