The arguments for using TUI IDEs are just very poor. Developers should not be relying on something as loaded with legacy bloat like the terminal, to do development.
Zed has remote editing support and is open source. Resource consumption is a bizarre proposition, considering what abstractions the terminal has to be forced into to behave something like a normal window.
Really, TUIs are not very good. I get it, I use the terminal all the time and I will edit files with vim in it, but it is a pointless exercise to try to turn the terminal into something it was never meant to be and try to have it emulate something which would be trivial on a normal OS window. To be honest it makes me cringe when people talk about how much they perform tasks in the terminal, which would be much easier done in a graphical environment with proper tools.
One thing that's nearly impossible to replicate on modern systems is the extremely tight feedback loop these TUIs had. Keyboard latency was near non-existent while basic calculators these days will happily take a hundred milliseconds to process a key press.
We don't need to go back to the 66MHz era, but it's embarrassing that programs running on a dozen computer cores all executing at several gigahertz feel less responsive than software written half a century ago. Sure, compiling half a gigabyte of source code now finishes before the end of the year, but I rarely compile more than a hundred or new lines at a time and the process of kickstarting the compiler takes much longer than actual compilation.
A terminal is no more than a rendering environment. With some workarounds (a custom renderer and input loop most likely), you can probably compile Zed to run in a FreeDOS in the same environment you use to run Turbo Pascal. I doubt you'll get the same responsiveness, though.
AFAIK Borland C++ (even on Windows) used to read the source from whatever editor buffers you had already in the IDE and since the compiler was part of the IDE, it cached various states in memory, which is why it was so fast (for a C/C++ compiler anyway - Delphi was much faster) even on slow hardware. Meanwhile Visual C++ (and modern IDEs) had you autosave the file to disk so the compiler, that was launched as a separate program (often for each file), could read it (and rebuild its internal state from scratch for every single file).
C does as well, that is half the point of make. When building a large C project it will first create a bunch of object files from the source files then link them into an executable. make then keeps track of what source files have changed and rebuilds only those object files. The first build is slow, subsequent builds are much faster. only needing to compile one file then link them.
At least that's the theory, in reality make has a lot of warts and implementing a good solid make file is an art. Don't even get me started on the horrors of automake, perhaps I just need to use it in one of my own projects but as someone who primarily ports others code, I hate it with a passion. It is so much easier when a project just sticks with a hand crafted makefile.
For completeness: The other half of make is to implement the rest of the build process.
I would say autoconf/automake is not really useful anymore and probably somebody should just establish a new and simplified standardized setup and Makefile for C projects.
And yes, efficient separate and incremental compilation is major advantage of C. I do not understand why people criticize this. It works beautifully. I also think it is good that the language and build system are separate.
I think you probably refer to something else than what i meant in my post above.
Borland C++ had the compiler as part of the IDE (there was also a separate command-line version, but it was also compiled as part of the IDE). This allowed the IDE to not spawn separate processes for each file nor even need to hit the disk - the compiler (which was already in RAM as part of the IDE's process) would read the source code from the editor's buffer (instead of a file, so again, no hitting the disk) and would also keep a bunch of other stuff in memory between builds instead of reading it.
This approach allows the compiler to reuse data not only between builds but also between files of the same build. Meanwhile make is just a program launcher, the program - the compiler - need to run for each file and load and parse everything it needs to work for every single source file it needs to compile, thus rebuilding and destroying its entire universe for each file separately. There is no reuse here - even when you use precompiled headers to speed up some things (which is something Borland C++ also supported and it did speed up things even more on an already fast system), the compiler still needs to build and destroy that universe.
It is not a coincidence that one of the ways nowadays to speed up compilation of large codebases is unity builds[0] which essentially combine multiple C/C++ files (the files need to be aware of it to avoid one file "polluting" the contents of another) to allow multiple compilation units reuse/share the compilation state (such as common header files) with a single compiler instance. E.g. it is a core feature of FASTbuild[1] which combines distributed builds, caching and unity builds.
Of course Borland C++'s approach wasn't perfect as it had to run with limited memory too (so it still had to hit the disk at some point - note though that the Pascal compilers could do everything in memory, including even the final linking, even the program could remain in memory). Also bugs in the compiler could linger, e.g. i remember having to restart Borland C++ Builder sometimes every few hours of using it because the compiler was confused about something and had cached it in memory between builds. Also Free Pascal's text mode IDE (shown in the article) has the Free Pascal compiler as part of the IDE itself, but in the last release (i think) there is a memory leak and the IDE's use keeps increasing little by little every time you build, which is something that wouldn't matter with a separate program (and most people use FPC as a separate program via Lazarus these days, which is most likely why nobody noticed the leak).
>One thing that's nearly impossible to replicate on modern systems is the extremely tight feedback loop these TUIs
Why? Yes, VSCode is slow. But Zed and many neovim GUIs are extremely responsive. Why would achieving that even be impossible or even that hard? You "just" need software which is fast enough to render the correct output the frame after the input. In an age where gaming is already extremely latency sensitive, why would having a text editor with similar latency performance be so hard?
Do you have any actual evidence that zed or neovide are suffering from latency problems? And why would putting a terminal in the middle help in any way in reducing that latency?
I'm not sure if you know what "terminal" means. I'm not talking about terminal emulators (the "terminal" program on macOS/Linux/Android/etc.) but actual, real terminals. The "terminal" is a text mode rendering mechanism built into computers of the terminal era. The closest modern operating systems come to it is the terminal-like environment you can get on Linux or the *BSDs by disabling the GUI, but even those merely emulate text mode, they still contain the stacks upon stacks of timers and necessary to process input peripherals.
The problem is the entire software stack between the keyboard and the display. From USB polling to driver loops and GPU callbacks, the entire software stack has become incredibly asynchronous, making it trivial for computers to miss a frame boundary. Compared to DOS or similar environments, where applications basically took control over the entire CPU and whatever peripherals it knew to access, there are millions of small points where inefficiencies can creep in. Compare that to the hardware interrupts and basic processor I/O earlier generations of computers used, where entered keys were in a CPU buffer before the operating system even knew what was happening.
VSCode isn't even that slow, really. I don't find it to be any slower than Zed, for instance. Given the technology stack underneath VSCode, that's an impressive feat by the Microsoft programmers. But the kind of performance TUI programs of yore got for free just isn't available to user space applications anymore without digging into low-level input APIs and writing custom GPU shaders.
In small part, CRTs running at 70Hz or 85Hz back in the mid-80s, as well as the much smoother display output of CRTs versus even modern LCDs, made for a much better typing experience.
Even 68k-based systems running in single digit megahertz could run full featured terminal emulation and have a lot of other stuff going too. There's legacy stuff in terminals, but compared to all the other stuff you've got going (Wayland, GTK, frickin' browser engine) it isn't bloated.
I'd bet you never seriously used Borland's Turbo Pascal for DOS versions 5.5 or 6.0. That IDE was extremely FAST. A lot of really good software was written in it back in the day (pre-internet).
Unless your window full of text is GPU-accelerated, tear-free and composited, with raytraced syntax highlighting and AI-powered antialiasing, what is even the point?
TUIs are great if your structure them around keyboard input. There's more of a learning curve, but people develop a muscle memory for them that lets them fly through operations. I think the utility of this is sorely underestimated and it makes me think of my poor mom, whose career came to an end as she struggled with the new mouse-driven, web-enabled custoner service software that replaced the old mainframe stuff.
The late 80s/early 90s trend of building GUI-like TUIs was really more to get users on board with the standard conventions of GUIs at a time when they weren't yet ubiquitous (among PC users). Unifying the UI paradigms across traditional DOS and Windows apps, with standard mouse interactions, standard pull-down menus, and standard keyboard shortcuts was a good thing at the time. Today it's less useful. Things like Free Pascal have UIs like this mainly for nostalgia and consistency with the thing they're substituting for (Turbo Pascal).
You are conflating a method of interaction with a method of drawing things to the screen. These are totally different things. Whether you have a keyboard focused interface like vim or not, has absolutely nothing to do with whether you are drawing graphics by sending escape codes to a terminal emulator to render the interface.
Neovim and it's frontends prove that if you remove terminal emulators the applications become better. The terminal emulator is just in the way.
There is absolutely no reason to build that keyboard focused interface around the terminal. Just drop the terminal and keep the interface, just like neovim did.
Neovim is my favorite editor and is a brilliant TUI.
I think what TUIs get right is that they are optimized for use by the keyboard.
I don’t care if they are a pain for devs to write vs OS APIs, they have the best keyboard control so I use them. I despise the mouse due to RSI issues in the past.
Neovim instantly becomes a superior piece of software if you use any of the GUI frontends. If you use neovim inside a terminal you are just straight up using an inferior product, with less features and more problems. The terminal version is most likely slower as well as you now also have the entire legacy terminal overhead.
>I think what TUIs get right is that they are optimized for use by the keyboard.
Neovim is just as much a GUI as a TUI. You can even use it as a backend for VSCode. Nothing about the keyboard controls have anything to do with this.
> If you use neovim inside a terminal you are just straight up using an inferior product, with less features and more problems
I use neovim like that and the selling point for me is that it's 1 less program that I have to install and learn with the added (crucial) benefit that it doesn't update on its own, changing UI and setting that I was used to.
>benefit that it doesn't update on its own, changing UI and setting that I was used to.
This exact thing remains true though, you are using the exact same neovim, but instead of it being wrapped inside a totally bizarre piece legacy software, it is rendered inside a modern graphical frontend. It looks mostly the same, except it handles fonts better, it is independent of weird terminal quirks and likely faster. There is no dowside.
And again, your point about using TUI stuff because of the input method or whatever is just false. Neovide has the exact same input method, yet has a complete GUI. Using the terminal makes no sense it all, it is the worst neovim experience there is.
Yeah but I also use a bunch of other stuff inside of Kitty so by using it in Kitty it composes well with the rest of my tools. Kitty windows and neovim splits integrate perfectly with smart splits. I even get images in the terminal and in Neovim.
What? "Slower" how? And why would dev experience not matter more?
TUIs are bizarre legacy technology, which are full of dirty hacks to somewhat emulate features every other desktop has. Why would any developer use them, when superior alternatives, not based on this legacy technology, exist and freely available?
Lots of opinions in the thread without any substance to back it up. If you don’t like TUIs and terminals, that’s ok. But if you actually want to argue against them, let’s hear a substantive argument. What specifically is so bad about the TUI?
They are built on ancient technology and need an enormous array of hacks to emulate basic features, which are trivial to do in any modern GUI.
User experience is inconsistent with features varying wildly between terminals, creating a frustrating user experience.
It is also making customization difficult. E.g. in a TUI IDE you can not have font settings. Short cuts are also terminal dependent, an IDE can only use those shortcuts the terminal isn't using itself.
Something as basic as color is extremely hard to do right on a terminal. Where in a normal GUI you can give any element a simple RGB color, you can not replicate that across TUIs. The same goes for text styling, the terminal decides what an italic font it wants to use and the IDE can not modify this.
They are also very limited in graphical ability. Many features users expect in a GUI can not be replicated or can only be replicated poorly. E.g. modern data science IDEs feature inline graphics, such as plots. This is (almost) not replicable on a Terminal. If you are using profiler you might want to plot, preferably with live data. Why arbitrarily limit what an IDE can do to some character grid?
The terminal is just a very poor graphical abstraction. It arbitrarily limits what an IDE can do. Can you tell me why anybody would seriously try to use a terminal as an IDE? Terminals UIs are more complex, because they need to handle the bizarre underlying terminal, they are often less responsive, since they rely on the terminal to be responsive. There might be some very marginal improvement in resource usage, do you think that is even relevant compared to the much increased dev experience of a normal GUI?
There absolutely is no real advantage of TUIs. And generally I have found people obsessing over them to be mostly less tech literate and wanting to "show off" how cool their computer skills are. All serious developers I have ever known used graphical dev tools.
>As someone already mentioned before, I don't think you are talking about the same terminal as others are.
People know perfectly well that I am talking about the way in which a terminal emulator can be used to display 2D graphics. By utilizing specific escape sequences to draw arbitrary glyphs on the terminal grid.
>What are those hacks.
Everything is a hack. TUIs work by sending escape sequences, which the terminal emulator then interprets in some way and if everything goes right you get 2D glyph based graphics. Literally everything is a hack to turn something which functions like a character printer into arbitrary 2D glyphs. Actually look at how bad this whole thing is. Look at the ANSI escape sequence you need to make any of this work, does that look like a sane graphics API to you? Obviously not.
>As far as I can remember, TUIs ran faster on ancient hardware then anything else on today's modern computers.
This is just delusional. Modern 2D graphics are extremely capable and deliver better performance in every metric.
Windows NT has a native console API that every non-Cygwin program used until a few years ago, when Microsoft finally implemented terminal emulation. See, for example, https://github.com/vim/vim/blob/e7c765fe5997daa845222351e114.... It’s just that there is little interest in TUIs from Windows users.
I don't think others are talking about what you are angry about. I said that with the first reply and I'm not the only one saying it. Nobody is trying to take Zed or Neovim away from you.
By the way one of the most frequent modern TUI apps that I use is Midnight Commander. It's a very nice app, which I use mostly when I SSH into a remote machine to manage it. Is there a 2D accelerated GUI that can help me do the same?
>Is there a 2D accelerated GUI that can help me do the same?
Of course. Just mount it through ssh and use whatever file manager you already have. It is very silly to switch tools just because the machine is somewhere else.
Switching tools just to accommodate the machine being remote is just bizarre to me. You even said that you used mc mostly for remote machines. What is the point of that? Now you have to use at least two tools which do the exact same thing, except you only use one when the system is remote? Does that not seem like a total waste? It would be one thing if you said that mc is what you always used, but that is not the case, you actively switch tools just to accommodate the machine being remote. Why? Do you think that is reasonable at all, when something as simple as just mounting over ssh exists?
You seem to have very strong feelings when other people have different preferences then you. Why would use words like bizarre, delusional and total waste, when discussing such trivial matters.
>> Why? Do you think that is reasonable at all, when something as simple as just mounting over ssh exists?
In short yes. I use it mostly on remote machines and on my desktop Linux machine. Before that I used Norton Commander on DOS. I don't remote only from Linux machines but also from a Windows laptop. It is much quicker and easier to simple run "mc" in an ssh session when I need it than trying to mount the drive and then run another application on the local machine.
i'm talking about turbo c++ of the 90s. it was a completely integrated experience. no screen switching was key. everything contained in one app. worth all the nostalgia but you kind of had to be there! and yep it was faster than zed.
This is just a bundle of your opinions -- to which you're entitled, even if they're totally wrong -- but downthread I see you attempt to defend them and claim they are objective fact, which is simply ridiculous.
TUIs are a superb tool. They were when they were first standardised in late-tera DOS apps in the late 1980s and early 1990s, and they still have a place today.
Here are some primary reasons you have not considered in your rant:
* UI standards and design
TUIs bring the sensible, designed-by-experts model of UI construction and human-computer interface from the world of GUIs into text-only environments such as the terminal, remote SSH connections, and so on.
For example, they let one set options using a form represented in dialog box, by Tabbing back and forth and selecting with Space or entering values, without trying to compose vast cryptic command lines.
This is not just me; this is the stuff of jokes. This is objective and repeatable.
A well-done TUI lets users use the same familiar UI both in a GUI and at the console. This is the actively beneficial flipside of the trivial cosmetics you are advocating: you praise a text-mode app implemented in a GUI because it can do more. That is a poor deal; a ground-up native GUI app can do much more still.
But TUIs bring the advantages of familiarity with GUIs to situations where a GUI is unavailable.
* Common UI
The apps you cite as positive examples are markedly poor at following industry-standard UI conventions, which suggests to me that you are ignorant that there are industry standard UI conventions. Perhaps you are too young. That is no crime, but it does not mean I must forgive ignorance.
Nonetheless, they exist, and hundreds of millions of people use them.
TUIs allow familiar UIs to be used even when a GUI or graphics at all are unavailable.
TUIs are not just about menus; they also define a whole set of hotkeys and so on which allow skilled users to navigate without a pointing device.
* Disabilities and inaccessibility
Presumably you are young and able-bodied. Many are not.
GUIs with good keyboard controls are entirely navigable by blind or partially-sighted users who cannot use pointing devices. They are also useful for those with motor disabilities that preclude pointing and clicking.
Millions use these, not from choice, from need.
But because those tools are there, that means that they can also use TUI apps which share the UI.
And the fact that this common UI exists for keyboard warriors like myself, who actively prefer a keyboard-centric UI, means that the benefits of a11y carry across and remain benefits for people who do not need a11y assistance.
=====
That's 4 reasons, intertwined, that you showed no sign of having considered. IMHO any 1 of the 4 is compelling on its own but combined any 2 would be inescapable and all of them together, for me, completely rebut and refute your argument.
Zed has remote editing support and is open source. Resource consumption is a bizarre proposition, considering what abstractions the terminal has to be forced into to behave something like a normal window.
Really, TUIs are not very good. I get it, I use the terminal all the time and I will edit files with vim in it, but it is a pointless exercise to try to turn the terminal into something it was never meant to be and try to have it emulate something which would be trivial on a normal OS window. To be honest it makes me cringe when people talk about how much they perform tasks in the terminal, which would be much easier done in a graphical environment with proper tools.