I also grew up on Borland IDE and to this day I still write TUIs to solve a variety of problems.
You correctly bring up bloat and I have a funny story about bloat and the Borland TUI. In the early 90s I was using Borland's TUI library toolkit and I couldn't get my program to load into 640k because the TUI itself was too bloated. I started going though the map file looking for what I could cut and I saw that the floating-point libraries were included. "What are those expensive FP libraries doing in there?!" I thought. I hunted down the references and found a single reference to sqrt. "Why on earth does the Borland TUI library need a floating point sqrt?" so I dug further. There was a not-so-useful feature that would do a tile-layout of the TUI windows and it used FP-sqrt for the size of the tile. "Oh my god! They linked in more than 64k of floating point library to compute the sqrt of an integer that is always less than 128!? For gods sake, just use a for loop counting up to 12! Or if a for loop seems liek too much work, how about a 128 byte look up table?" This was very memorable to me because it was my first head-on encounter with bloat and I've used it as my avatar of lazy programming ever since.
Dec 29, 2023·edited Dec 29, 2023Liked by Julio Merino
The late 80s early 90s TUI were partially a phenomenon of the availability of fast memory mapped character console displays. In the transition to GUIs you needed to use slow-ish ANSI terminal controls in a slow-ish terminal emulator window to do the same thing in a window and there was a period where that was unacceptably slow.
I'd love to assemble some gurus and compare and contrast the development experience on DOS, the Macintosh, the Amiga, and the first-class Smalltalk and Lisp implementations from the 90s. What is missing? What has improved? What has regressed? Which environment was most productive? Which was easiest to learn?
(Medley Interlisp was recently ported to run in the browser. Getting Open Genera to run takes a bit more wizardry, and I have no idea what the best Smalltalk was in 1990.)
Emacs predates DOS/Windows and IBM's CUA standard; it's the last survivor of an separate branch of computer interface development born from the MIT AI lab. (F10 actually brings up the drop-down menu, but the point about discoverability is well taken; Emacs is a relic of an alien civilization.)
So many memories! I learned to code early 2000s but somehow the school computers still had Turbo Pascal and Turbo C++, and then I switched to Borland Delphi for a while, until college when I first met a modern, enterprise IDE like Visual Studio 2005. So I had the fortune to travel through like 20 years in IDE history in the span of maybe 5. I'll never forget that sentiment as a teenager of making a ball bounce of an ants simulation with graphics.h. Thanks for taking me down this nostalgia lane.
I wish you had researched FPC (Free Pascal Compiler) more, rather than unkindly dismissing it as archaic. It certainly supports legacy Pascal and Pascal with Objects, but it ... very interestingly supports a thoroughly modern Object Pascal dialect that really isn't your daddy's Pascal. I feel your throw away comment is highly unjust. If you want to see what you can do with FPC, check out the Lazarus project. It's a cross-platform linux/bsd/mac/windows GUI development environment that styles itself on Delphi. All written using this "archaic" (as you put it) language.
MS-DOS 5 is from 1991, not 1981. I always think there seems to be not that much going on between DOS 2 and 5 and then Windows 3 happens and OMG that is a lot of code and design behind it.
When I first started using VS in the 90's, I thought how can they even call this Integrated?
Eventually I realized that what K. called "the unix programming environment" was an IDE. An Integrated Development Environment, including Shell and Storage and Editor and Compiler, and you could compile and edit from the shell (ok, editing took you into a subshell). And that is why IDE's like Eclipse were and are so dreadful compared even to TP 3: they try to virtualize / recreate / upgrade the "unix programming environment" of a federation of tools, shells, scripts and persistence, rather than the seamless single-source QB / TP environment.
Visual Studio stole the "visual" moniker from Visual Basic: it didn't offer visual development like VB, it just took the branding. IDE's like VS and Eclipse are Development Environments, but they aren't Integrated Development Environments like QB and TP: they just took the branding.
Emacs developer here. While I appreciate the effort you've put into writing this article, and the benign intentions behind it, it covers Emacs (and doubtless many other terminal-capable text editors which my limited understanding of does not permit me to comment on) from a perspective affected by several misapprehensions that does it a grave injustice.
My first and most significant objection is the selection of text editors against which Emacs is being compared, that is, the inclusion of Emacs in this comparison in and of itself: programs designed primarily for convenience in the face of limitations imposed by text terminals or PC displays of the early 1990s cannot be fairly compared, with respect to ease of operation in such environments, to a text editor that has evolved for decades amidst the comparative luxury of graphical user interfaces. This is seen to good advantage in the existence of features whose absence is mentioned here when Emacs is operating as a graphical program: clickable menu bar items being just about the only well-defined example, they are the only features I can confidently cite in turn as functional without any user configuration in graphical Emacs sessions. As regards the narrow color palette used in terminal sessions, it must be said that, besides choice of colors being very much subjective and the lion's share of Unix terminal programs adopting a similarly limited set of colors by default, our MS-DOS port adopts a different theme consisting of colors marked by far greater contrast that is much in line with other text editors on that system, notably the Turbo C++ that is the subject of this comparison.
Second, and by the same token, the comparison is framed between two starkly contrasting operating systems, each with its own culture and customs for command line programs and with its text-centric programs having evolved to meet differing requirements towards ease of use. Convergence between Unix-like systems and Microsoft's in these respects did not begin until the popularization of graphical user interfaces was well underway: the upshot being that although textual MS-DOS programs generally adopted mouse-driven interfaces, the same interfaces were spurned by developers of their cousins in the Unix sphere, up to the time (if at all) these programs received interfaces to X Windows. In addition, graphical text editors are equally capable of editing files on remote machines, or displaying on a machine other than where it is running; Emacs provides both in the form of TRAMP (Transparent Remote Access, Multiple Protocol) and support for maintaining connections to multiple X displays at once. Given the foregoing, some of the assertions made here as to the state of the art in Unix systems are unwittingly misleading and should be revised or just removed.
Last but not least, the conclusion that Emacs is liable to frustrate uninitiated users cannot hold water, in light of the several large buttons directing them to the tutorial, manual, and the two paragraphs' worth of instructions printed above the TMM menu-bar prompt. Incidentally, our MS-DOS port has _always_ supported mouse-driven menu interaction not unlike other MS-DOS applications, in keeping with users' preferences on that OS.
I cannot stay silent while some of the ubiquitous and repeatedly refuted myths and truisms concerning Emacs's alleged difficulty are being perpetuated and gain acceptance in the minds of ever more people for want of any factual information to the contrary (along with the typical reluctance to do research for oneself which readers of articles that make passing reference to Emacs often exhibit). So good day, and thank you for reading this.
Opinion on Eclipse, since multiple other commenters have brought it up (caveat: I last used it about a decade ago):
Eclipse looks bad, visually. The style is sort of Windows 95 like, but lower quality. Lots of one-pixel borders would overlap with the text they were supposed to surround.
Eclipse is slow. I move the cursor or select some text, it pauses for about one second to do I don't know what – maybe update the bad visuals with a border around the current name/symbol half obscuring the edges of its characters.
Eclipse is overcomplicated. My team had an ant project configured in Eclipse. When we needed to tweak the compiler configuration or the build in any way, we had to hunt down two places, the project configuration and Eclipse's own global configuration. Why we couldn't just do one, I don't know. One time we did both and it turned out not to be enough, and I don't remember whether I ever found the third, secret configuration layer besides Eclipse-global and project that needed to be fixed. I want to say I did but no longer recall what it was. Oh, and so much as finding project vs Eclipse-global configuration was unintuitive and needlessly difficult.
Eclipse was so bad, it drove me to write the code in Notepad++ (not that I'd recommend that now; that's another story) and to learn commandline/terminal tools for running the build, at a time when I was an ordinary 21st century Windows developer who would've preferred Visual Studio with no knowledge of Linux or CLI programs. (Wow, I feel like I was so young back then…) I guess I should be grateful. Learning how compilers and toolchains work, and how to work in the shell, ends up being one of those hacker nerd superpowers that I take for granted these days!
The great forgotten here is Eclipse, that has more than 2 decades in the back for developping c/c++ applications. In the embedded wold many of the ides are based in Eclipse. I use It to develop c applications for microcontrollers and lately to develop gtk4 tooling applications.
Vscode came many time after Eclipse existed doing... Well, doing the same than Eclipse, but with lots of noise made by ms fanboys and integration with GitHub.
The good of ides is that everybody can use the one they love.
Btw NetBeans is also a good ide supporting a lot of languages. Then fot c you also have code::blocks and codelite, that are good options to develop in a Raspberry pi in a graphical environment.
Free Pascal IDE also has nice helpfile support (CHM) also on non windows. I actually worked on the FPC textmode IDE for a while, but switched to Lazarus primarily for inactive code shading and intellisense like completion. I never even tried Gambas much, a product without a Windows version is too limited, so I don't know how it compares to Lazarus.
Another worthy textmode IDE was Topspeed's range (specially 3.x). I think overall I have used it even more than Turbo Pascal.
I also grew up on Borland IDE and to this day I still write TUIs to solve a variety of problems.
You correctly bring up bloat and I have a funny story about bloat and the Borland TUI. In the early 90s I was using Borland's TUI library toolkit and I couldn't get my program to load into 640k because the TUI itself was too bloated. I started going though the map file looking for what I could cut and I saw that the floating-point libraries were included. "What are those expensive FP libraries doing in there?!" I thought. I hunted down the references and found a single reference to sqrt. "Why on earth does the Borland TUI library need a floating point sqrt?" so I dug further. There was a not-so-useful feature that would do a tile-layout of the TUI windows and it used FP-sqrt for the size of the tile. "Oh my god! They linked in more than 64k of floating point library to compute the sqrt of an integer that is always less than 128!? For gods sake, just use a for loop counting up to 12! Or if a for loop seems liek too much work, how about a 128 byte look up table?" This was very memorable to me because it was my first head-on encounter with bloat and I've used it as my avatar of lazy programming ever since.
The late 80s early 90s TUI were partially a phenomenon of the availability of fast memory mapped character console displays. In the transition to GUIs you needed to use slow-ish ANSI terminal controls in a slow-ish terminal emulator window to do the same thing in a window and there was a period where that was unacceptably slow.
Great little article, Julio. I really enjoyed it and I have much the same thoughts -- for instance, here:
https://liam-on-linux.livejournal.com/42908.html (Note the date! Very nearly a decade ago now.)
In the end I found Tilde and I now use it in a lot of places on Linux.
https://github.com/gphalkes/tilde
I wrote an article praising it:
https://www.theregister.com/2021/12/17/tilde_text_editor/
Have you heard of tvision, with turbo, tvedit and and tvterm?
tvision is a modern, cross-platform port of turbo vision, including tvedit in its examples, a simple text editor similar to MS-DOS EDIT.
turbo is an IDE built with tvision, and is my go-to terminal text editor on any platform.
tvterm is a terminal emulator using tvision, and allows you to have multiple terminal windows in your terminal.
https://github.com/magiblot/tvision
https://github.com/magiblot/turbo
https://github.com/magiblot/tvterm
I'd love to assemble some gurus and compare and contrast the development experience on DOS, the Macintosh, the Amiga, and the first-class Smalltalk and Lisp implementations from the 90s. What is missing? What has improved? What has regressed? Which environment was most productive? Which was easiest to learn?
(Medley Interlisp was recently ported to run in the browser. Getting Open Genera to run takes a bit more wizardry, and I have no idea what the best Smalltalk was in 1990.)
Emacs predates DOS/Windows and IBM's CUA standard; it's the last survivor of an separate branch of computer interface development born from the MIT AI lab. (F10 actually brings up the drop-down menu, but the point about discoverability is well taken; Emacs is a relic of an alien civilization.)
So many memories! I learned to code early 2000s but somehow the school computers still had Turbo Pascal and Turbo C++, and then I switched to Borland Delphi for a while, until college when I first met a modern, enterprise IDE like Visual Studio 2005. So I had the fortune to travel through like 20 years in IDE history in the span of maybe 5. I'll never forget that sentiment as a teenager of making a ball bounce of an ants simulation with graphics.h. Thanks for taking me down this nostalgia lane.
I wish you had researched FPC (Free Pascal Compiler) more, rather than unkindly dismissing it as archaic. It certainly supports legacy Pascal and Pascal with Objects, but it ... very interestingly supports a thoroughly modern Object Pascal dialect that really isn't your daddy's Pascal. I feel your throw away comment is highly unjust. If you want to see what you can do with FPC, check out the Lazarus project. It's a cross-platform linux/bsd/mac/windows GUI development environment that styles itself on Delphi. All written using this "archaic" (as you put it) language.
MS-DOS 5 is from 1991, not 1981. I always think there seems to be not that much going on between DOS 2 and 5 and then Windows 3 happens and OMG that is a lot of code and design behind it.
When I first started using VS in the 90's, I thought how can they even call this Integrated?
Eventually I realized that what K. called "the unix programming environment" was an IDE. An Integrated Development Environment, including Shell and Storage and Editor and Compiler, and you could compile and edit from the shell (ok, editing took you into a subshell). And that is why IDE's like Eclipse were and are so dreadful compared even to TP 3: they try to virtualize / recreate / upgrade the "unix programming environment" of a federation of tools, shells, scripts and persistence, rather than the seamless single-source QB / TP environment.
Visual Studio stole the "visual" moniker from Visual Basic: it didn't offer visual development like VB, it just took the branding. IDE's like VS and Eclipse are Development Environments, but they aren't Integrated Development Environments like QB and TP: they just took the branding.
If you're looking for something that's better than nano, try micro! https://micro-editor.github.io/
Surprised cscope isn’t mentioned. That’s what the old hat vim developers I knew used for project management.
Emacs developer here. While I appreciate the effort you've put into writing this article, and the benign intentions behind it, it covers Emacs (and doubtless many other terminal-capable text editors which my limited understanding of does not permit me to comment on) from a perspective affected by several misapprehensions that does it a grave injustice.
My first and most significant objection is the selection of text editors against which Emacs is being compared, that is, the inclusion of Emacs in this comparison in and of itself: programs designed primarily for convenience in the face of limitations imposed by text terminals or PC displays of the early 1990s cannot be fairly compared, with respect to ease of operation in such environments, to a text editor that has evolved for decades amidst the comparative luxury of graphical user interfaces. This is seen to good advantage in the existence of features whose absence is mentioned here when Emacs is operating as a graphical program: clickable menu bar items being just about the only well-defined example, they are the only features I can confidently cite in turn as functional without any user configuration in graphical Emacs sessions. As regards the narrow color palette used in terminal sessions, it must be said that, besides choice of colors being very much subjective and the lion's share of Unix terminal programs adopting a similarly limited set of colors by default, our MS-DOS port adopts a different theme consisting of colors marked by far greater contrast that is much in line with other text editors on that system, notably the Turbo C++ that is the subject of this comparison.
Second, and by the same token, the comparison is framed between two starkly contrasting operating systems, each with its own culture and customs for command line programs and with its text-centric programs having evolved to meet differing requirements towards ease of use. Convergence between Unix-like systems and Microsoft's in these respects did not begin until the popularization of graphical user interfaces was well underway: the upshot being that although textual MS-DOS programs generally adopted mouse-driven interfaces, the same interfaces were spurned by developers of their cousins in the Unix sphere, up to the time (if at all) these programs received interfaces to X Windows. In addition, graphical text editors are equally capable of editing files on remote machines, or displaying on a machine other than where it is running; Emacs provides both in the form of TRAMP (Transparent Remote Access, Multiple Protocol) and support for maintaining connections to multiple X displays at once. Given the foregoing, some of the assertions made here as to the state of the art in Unix systems are unwittingly misleading and should be revised or just removed.
Last but not least, the conclusion that Emacs is liable to frustrate uninitiated users cannot hold water, in light of the several large buttons directing them to the tutorial, manual, and the two paragraphs' worth of instructions printed above the TMM menu-bar prompt. Incidentally, our MS-DOS port has _always_ supported mouse-driven menu interaction not unlike other MS-DOS applications, in keeping with users' preferences on that OS.
I cannot stay silent while some of the ubiquitous and repeatedly refuted myths and truisms concerning Emacs's alleged difficulty are being perpetuated and gain acceptance in the minds of ever more people for want of any factual information to the contrary (along with the typical reluctance to do research for oneself which readers of articles that make passing reference to Emacs often exhibit). So good day, and thank you for reading this.
You forgot Fox pro for DOS and Zenix
Opinion on Eclipse, since multiple other commenters have brought it up (caveat: I last used it about a decade ago):
Eclipse looks bad, visually. The style is sort of Windows 95 like, but lower quality. Lots of one-pixel borders would overlap with the text they were supposed to surround.
Eclipse is slow. I move the cursor or select some text, it pauses for about one second to do I don't know what – maybe update the bad visuals with a border around the current name/symbol half obscuring the edges of its characters.
Eclipse is overcomplicated. My team had an ant project configured in Eclipse. When we needed to tweak the compiler configuration or the build in any way, we had to hunt down two places, the project configuration and Eclipse's own global configuration. Why we couldn't just do one, I don't know. One time we did both and it turned out not to be enough, and I don't remember whether I ever found the third, secret configuration layer besides Eclipse-global and project that needed to be fixed. I want to say I did but no longer recall what it was. Oh, and so much as finding project vs Eclipse-global configuration was unintuitive and needlessly difficult.
Eclipse was so bad, it drove me to write the code in Notepad++ (not that I'd recommend that now; that's another story) and to learn commandline/terminal tools for running the build, at a time when I was an ordinary 21st century Windows developer who would've preferred Visual Studio with no knowledge of Linux or CLI programs. (Wow, I feel like I was so young back then…) I guess I should be grateful. Learning how compilers and toolchains work, and how to work in the shell, ends up being one of those hacker nerd superpowers that I take for granted these days!
The great forgotten here is Eclipse, that has more than 2 decades in the back for developping c/c++ applications. In the embedded wold many of the ides are based in Eclipse. I use It to develop c applications for microcontrollers and lately to develop gtk4 tooling applications.
Vscode came many time after Eclipse existed doing... Well, doing the same than Eclipse, but with lots of noise made by ms fanboys and integration with GitHub.
The good of ides is that everybody can use the one they love.
Btw NetBeans is also a good ide supporting a lot of languages. Then fot c you also have code::blocks and codelite, that are good options to develop in a Raspberry pi in a graphical environment.
There exist a lot of good tools few people know.
Free Pascal IDE also has nice helpfile support (CHM) also on non windows. I actually worked on the FPC textmode IDE for a while, but switched to Lazarus primarily for inactive code shading and intellisense like completion. I never even tried Gambas much, a product without a Windows version is too limited, so I don't know how it compares to Lazarus.
Another worthy textmode IDE was Topspeed's range (specially 3.x). I think overall I have used it even more than Turbo Pascal.