Journal

The terminal of the future or don't call it a terminal

This HN thread caught my attention: The terminal of the future, and made me think about the concept of a piece of software.

This isn’t the first time I encounter this kind of discussion around the same essential topic: where to draw the line between maintaining a piece of software and pushing new features, versus adding only critical updates because that piece of software is self-contained and complete.

The *nix philosophy made this decision easy: since your goal is just one, you can easily delimit what’s needed and what’s not. Thus, what is not needed is part of another piece of software. Obviously, this is not always the case, and nowadays the industry pushes for a paradigm where constant updates and new features are the justification to keep charging a monthly fee. Not exactly a piece of software anymore, but a product: even absurd pivots, like Spotify going TikTok-like, are becoming more common. Current industry trend is trapped into this loop: a stalled product loses value over time, and the only way to keep it alive is to keep adding new features. That logic is not technical – it’s a business model.

But the terminal? It’s a historical contract between a user and a computer: a basic operating system abstraction. And the ideas behind it are rock solid: they’ve endured the test of time after more than 50 years. It does not need a fancy UI. Yes, it inherits from an old VT100 that does not support many features we take for granted in modern software. But again, the overhead of adding the list of features the author proposes would make it a completely different piece of software. Do not call it a terminal.