It's a testament to the improvements in software engineering that we can even write large-scale systems at all in the first place. Structured programming and object-oriented programming [1] have proven to be revolutionary in the language front. Similarly, you can point to the development of the modern DAG-based VCS and continuous integration on the infrastructure front. Or modern IDEs with integrated debuggers and refactoring tools for development; automated regression suites; fuzzers and sanitizers--we've come a long way.
But I think a lot of people keep falling into the same trap when it comes to imagining what the next set of major improvements should be. Graphical programming is a popular example: the author pooh-poohs the terminal, for example. But text is the densest way we can precisely convey information; if we're trying to scale to the next system size, cutting information density by ½ (or more!) is not a good first step.
[1] I'm referring here specifically to the principle that state should be contained with objects that are protected by interfaces and passed around to people who need access to them, instead of everything just being functions that manipulate global variables. This is closer to what Alan Kay's original definition than the current interpretation.
> Graphical programming is a popular example: the author pooh-poohs the terminal, for example. But text is the densest way we can precisely convey information; if we're trying to scale to the next system size, cutting information density by ½ (or more!) is not a good first step.
You don't necessarily need a terminal for a text-based interface (looking at you, Oberon). Our terminals are teletype emulators. TTY is hard-baked deep into the most prevalent operating systems and it affects what we consider "programming" and limits our collective horizon.
The parent's point wasn't about CLI vs. GUI so much as different ways to present and design programs. Most people these days write software in an editing environment that's much richer than the TTY.
> But text is the densest way we can precisely convey information
I take issue with that claim. For one, it is possible to enhance text (which I take to mean a sequential glyph representation here) with useful graphical elements which take up little space (e.g. making use of the often considerable amount of whitespace around text). And there are many types of information that are poorly suited to textual representation.
Of course, people may assign different meanings to the word text. To take an example from the article, you can say that a spreadsheet interface uses text in its cell values and formulas. But it is arguably not a text interface in the way CLIs and text/code editors are commonly understood.
But I think a lot of people keep falling into the same trap when it comes to imagining what the next set of major improvements should be. Graphical programming is a popular example: the author pooh-poohs the terminal, for example. But text is the densest way we can precisely convey information; if we're trying to scale to the next system size, cutting information density by ½ (or more!) is not a good first step.
[1] I'm referring here specifically to the principle that state should be contained with objects that are protected by interfaces and passed around to people who need access to them, instead of everything just being functions that manipulate global variables. This is closer to what Alan Kay's original definition than the current interpretation.