Speaking of bloat: why are binaries from Rust or (much worse) Go so damn huge? This is in release mode with debug off.
It’s weird because memory use for the same sorts of programs is not much worse than other languages. In Rust memory use seems comparable to C++. In Go there’s a bit more overhead but it’s still smaller than the binary. So all this is not being loaded.
I get the sense devs just don’t put a lot of effort into stripping dead code and data since “storage is cheap” but it shows next to C or even C++ programs that are a fraction of the size.
I see nothing about Rust’s safety or type system that should result in chonky binaries. All that gets turned into LLVM IR just like C or C++.
Go ships a runtime so that explains some, but not all, of its bloat.
I used most of these and they weren't worth it. They didn't do enough to justify being locked in to the tool. The debuggers were too, uh, buggy. Command line tools were more flexible.
They finally got good enough in the late 90s. I think it helped that computers finally had enough memory to run both the editor and the program itself.
In the golden age of DOS you had an array of bytes representing characters and an array representing attributes (background and foreground colors) and the hardware drew out of that. If you wanted to write a ‘A’ to a certain spot you wrote 0x41 to a certain memory address and that was that —- there were some wait states involved but it was way faster than drawing on a 9600 baud terminal with ANSI terminal commands that use up even more bytes.
I first used emacs on terminals that were hooked to Sun workstations and you were either going to use a serial terminal which was very slow, or the terminal emulator on the Sun which was a GUI program that had to do a lot of work to draw the characters into the bitmap. So that’s your reason TUIs went away.
I used Borland Turbo Pascal in 1984. It was amazing to work with something so fast on a PC that was really so slow. No IDE/Compiler since then matched the speed. Today's code is massively more sophisticated and complex, so there is no way to match that performance today despite the speed of computers today.
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.
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.
I think Emacs still does all of this; the argument the author makes is that it is "arcane", it just uses conventions he is not used to. It is however fully self-documented and interactive.
For me the best textual interface I've ever used remains Magit in Emacs: https://magit.vc/ I wish more of Emacs was like it.
I actually use emacs as my git clients even when I'm using a different IDE for whatever reason.
Oh wow. Slightly surprised about the emotions these pictures evoke! Not that I would want to program with that today, but I sure had fun with it back then.
The knocks against Emacs feel unwarranted. It has plenty of colour; it has mouse support, even in the terminal, but not all terminals support it, so it's optional. It also runs in a GUI with, you know, image support and whatnot.
You can rail against its defaults, but do not make misleading claims.
I'm going to get punished for saying this, but I don't really see the point of IDEs when you have things like vim, Makefiles and bash. It just seems like more things to go wrong. I used Eclipse while I was doing Java development for a while and it had some conveniences but for the most part I just see it as one more thing that can go wrong and get in my way.
Anyway, does anyone remember Metrowerks CodeWarrior? I see it still exists, but I mean back from the 90s. I got a T-shirt from them at MacWorld '99 and still had it until not too long ago. High quality merch.
Ah, Borland’s IDE! An absolute delight. I’ve yet to find anything modern that matches it. Sure, nostalgia turns everything syrupy, but I actively hunt for excuses to use Free Pascal just to fire up that interface. Okay, fine—I like Pascal too. You caught me.
I also use Sam and Acme from Plan 9 (technically from the excellent plan9port), but let’s be honest: those aren’t IDEs. They’re editors. Tools that let me think instead of wrestle.
There’s a lot we could (and probably should) learn from the old TUIs. For example, it’s perfectly acceptable, even heroic, to spawn a shell from the File menu and run something before returning. Seems people are afraid of losing style points with such grievous actions.
And the keybindings! So many of those classic TUIs adopted WordStar’s sacred keystrokes. They’re burned into my muscle memory so thoroughly that using EMACS feels like trying to type with oven mitts. For years, joe (with the blessed jstar alias) was my editor of choice.
Anyway! Time to boot the Dr. DOS VM, spin the wheel of Advent of Code, and be nostalgically inefficient on purpose.
I used to use a Java-oriented IDE called “Visix Vibe”, at first as an experiment in application development with Java and then as an alternative to Delphi, which was my bread and butter tooling environment for custom application development.
Both of these IDE’s gave me a huge productivity boost, and it used to be a no-brainer to give customers a realizable estimate for getting the UI done, then wiring up logic, and get things ready to ship, etc.
I really miss these IDE’s, because of the integration factor. It was fun to wire up a database table and generate a form and immediately have something that could be used for data input and validation on the project - then spend a few weeks refining the UI to be more robust and cater to the application use case in focus.
These days, it feels like a lot more careful planning is needed to make sure the UI/API/backend realms can play properly together.
It would be nice to see some more progress on this level of tooling. It’s one thing to have an AI generate UI code - but I still think there is room for painting the code and using a UI to build a UI.
(The moment someone produces a properly WYSIWYG tool for JUCE, the glory days will begin again ..)
> The moment someone produces a properly WYSIWYG tool for JUCE,
Side note: Steinberg's vstgui framework not only has a WYSIWYG editor, you can even build/edit the UI while the plugin is running in a DAW. I usually give Steinberg a lot of shit for their arrogance and ignorance, but this I found extremely cool! I have only toyed around with it, so I don't know how viable it is for complex plugin UIs.
Schoolaged 1995 coder self with a fpuless Mac would like a word about what we lost/gained (no available c compilers at the time).
The need for tui argument is vague outside of muscle memory. Lots of beautiful poetry though.
That age of computing the author is romanticizing was expensive and corporate fed stupid (RIP Mr Bollenbach my hs cs teacher who gave us weekly insider tech reports).
I feel like tui folk need their stack/os/integrated environment...oh wait. Nevermind.
Great nostalgia! I fondly remember QuickBasic, and how excited I was to compile my BASIC code. And the rarely mentioned gem I thought was amazing at the time: Visual Basic for DOS!
One I used to love back in the 80s/90s was GFA Basic on the Atari ST. In a similar category of TUI (mostly, it did have mouse control and menu bars, but you didn't have to reach for them) with great auto-indentation and code folding (features not common in mainstream editors at the time) and instant compilation and error checking.
It took many decades for me to get that kind of flow back for mainstream programming languages on modern computers. And modern IDEs still have higher latency than they should.
> “In my house”, we used something called SideKick Plus (1984), which wasn’t really a code editor: it was more of a Personal Information Management (PIM) system with a built-in notepad.
Finally! Someone who still remembers the best software ever written. I looooved Sidekick and we used it throughout our small company. It's so long ago. I remember only parts of it now but it was such a useful tool.
156 comments
[ 3.0 ms ] story [ 75.1 ms ] threadhttps://github.com/cosmos72/twin
https://github.com/Julien-cpsn/desktop-tui
It’s weird because memory use for the same sorts of programs is not much worse than other languages. In Rust memory use seems comparable to C++. In Go there’s a bit more overhead but it’s still smaller than the binary. So all this is not being loaded.
I get the sense devs just don’t put a lot of effort into stripping dead code and data since “storage is cheap” but it shows next to C or even C++ programs that are a fraction of the size.
I see nothing about Rust’s safety or type system that should result in chonky binaries. All that gets turned into LLVM IR just like C or C++.
Go ships a runtime so that explains some, but not all, of its bloat.
They finally got good enough in the late 90s. I think it helped that computers finally had enough memory to run both the editor and the program itself.
I first used emacs on terminals that were hooked to Sun workstations and you were either going to use a serial terminal which was very slow, or the terminal emulator on the Sun which was a GUI program that had to do a lot of work to draw the characters into the bitmap. So that’s your reason TUIs went away.
https://github.com/gphalkes/tilde
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.
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.
https://xkcd.com/1168/
https://xkcd.com/1597/
* Harmonious design
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.
https://en.wikipedia.org/wiki/IBM_Common_User_Access
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.
For me the best textual interface I've ever used remains Magit in Emacs: https://magit.vc/ I wish more of Emacs was like it.
I actually use emacs as my git clients even when I'm using a different IDE for whatever reason.
You can rail against its defaults, but do not make misleading claims.
Its nothing bloated, its not embedded ide like vscode and all
Rather scite is just gui frontend for cli based binaries, it uses programming environments you have installed on your os
Just like old time on cmd or sh, we used compilers eg javac or cpp
Now scite just make it easy, its exactly same as borland turbo, you add path to your compiler binaries in scite and done you click compile or run,
Plus its lightweight and portable, carry it in usb and run on any computer by just setting paths to compiler and executor binaries
Anyway, does anyone remember Metrowerks CodeWarrior? I see it still exists, but I mean back from the 90s. I got a T-shirt from them at MacWorld '99 and still had it until not too long ago. High quality merch.
I also use Sam and Acme from Plan 9 (technically from the excellent plan9port), but let’s be honest: those aren’t IDEs. They’re editors. Tools that let me think instead of wrestle.
There’s a lot we could (and probably should) learn from the old TUIs. For example, it’s perfectly acceptable, even heroic, to spawn a shell from the File menu and run something before returning. Seems people are afraid of losing style points with such grievous actions.
And the keybindings! So many of those classic TUIs adopted WordStar’s sacred keystrokes. They’re burned into my muscle memory so thoroughly that using EMACS feels like trying to type with oven mitts. For years, joe (with the blessed jstar alias) was my editor of choice.
Anyway! Time to boot the Dr. DOS VM, spin the wheel of Advent of Code, and be nostalgically inefficient on purpose.
Programmers are trying to bring them back bc nostalgia I guess?
I floated the idea of TUIs to our data engineering team and got very negative responses. (My nostalgia for undergrad turbo pascal TUI I guess lol)
Both of these IDE’s gave me a huge productivity boost, and it used to be a no-brainer to give customers a realizable estimate for getting the UI done, then wiring up logic, and get things ready to ship, etc.
I really miss these IDE’s, because of the integration factor. It was fun to wire up a database table and generate a form and immediately have something that could be used for data input and validation on the project - then spend a few weeks refining the UI to be more robust and cater to the application use case in focus.
These days, it feels like a lot more careful planning is needed to make sure the UI/API/backend realms can play properly together.
It would be nice to see some more progress on this level of tooling. It’s one thing to have an AI generate UI code - but I still think there is room for painting the code and using a UI to build a UI.
(The moment someone produces a properly WYSIWYG tool for JUCE, the glory days will begin again ..)
Side note: Steinberg's vstgui framework not only has a WYSIWYG editor, you can even build/edit the UI while the plugin is running in a DAW. I usually give Steinberg a lot of shit for their arrogance and ignorance, but this I found extremely cool! I have only toyed around with it, so I don't know how viable it is for complex plugin UIs.
The need for tui argument is vague outside of muscle memory. Lots of beautiful poetry though.
That age of computing the author is romanticizing was expensive and corporate fed stupid (RIP Mr Bollenbach my hs cs teacher who gave us weekly insider tech reports).
I feel like tui folk need their stack/os/integrated environment...oh wait. Nevermind.
"Is FreeDos the Moderate Libertarian TempleOS?"
It took many decades for me to get that kind of flow back for mainstream programming languages on modern computers. And modern IDEs still have higher latency than they should.
Finally! Someone who still remembers the best software ever written. I looooved Sidekick and we used it throughout our small company. It's so long ago. I remember only parts of it now but it was such a useful tool.
You could throw together a CRUD app in under an hour interactively.
Moved to Dev-C++
Nowadays just any editor and using GCC directly
Eternally greatful for open source, Microsoft charged thousands for Visual C++ back then.