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.
Oh goodness do I miss the days that 64k could be called bloat.
I still do some development in visual studio 6 (first released 1999) because "hello windows" only takes about 16k, meaning that real apps can be delivered in less than 100kb. It's getting nearly impossible though, as even good old Win32 APIs have changed so much in 24 years.
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.)
Do you know since when F10 opened the Emacs menu? I had no idea about this (after more than 20 years using Emacs), and various other people in HN have pointed it out. I'm also surprised it's not even mentioned in the welcome page...
I downloaded and grepped through the old Emacs releases, courtesy of Lars Brinkhoff's Emacs history repository. Text mode access to menu-bar is added in 19.29 (1995-06-19), and binds tmm-menubar (text mode menu) to F10 by default. M-` was added in 19.30 a few months later, and tmm-menubar finally gets an info entry in 19.31.
You might have had issues with tmm-menubar because of the nonstandard controls, assuming it wasn't broken in the release you used. Per 19.31's manual: "On text-only terminals, you can use the menu bar by typing M-` (`tmm-menubar'). This enters a mode in which you can select a menu item from the keyboard. Either type the initial of the item you want, or use the left and right arrow keys to choose an item and use RET to finalize the choice."
The two major Smalltalk implementations from mid 80s to mid 90s were ParcPlace Smalltalk (later updated to VisualWorks) and Digitalk's Smalltalk/V (later Visual Smalltalk Enterprise). Digitalk also had a TUI version named Methods. They were all commercial.
The first cut of Squeak Smalltalk, which is a direct descendant of Smalltalk-80, is announced in 1996. It is arguably the first open source Smalltalk that developed a significant community. There are other opened source ones (eg. Tim Budds Little Smalltalk) but they're mostly educational or single dev hobbies. I'm not sure how to classify Smalltalk/X as it was open, but almost invisible hobby project until the dev, Claus Gittinger, commercialized it in 1994.
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.
Yeah, that was a typo. I searched for "MS-DOS 5", incorrectly landed on the generic MS-DOS Wikipedia page, and copied the 1981 date from there. It sounded wrong, but somehow I didn't put a second thought to re-validate the date. Will fix the text.
But yeah, the jump from MS-DOS pre-5 and 5 + Windows 3.x was incredible.
Yes, that's how I read it too, but the earlier blog post is clearer. DOS, when the PC was released in 1981, had a text editor: EDLIN. It was awful -- I speak as someone who used it every day for years -- but it was there and it worked.
You're right about when EDIT.COM was introduced, though. In MS-DOS 5, EDIT required QBASIC as it called the BASIC executable for its editor, discarding the interpreter. In MS-DOS 6.x it was a standalone app and you didn't need QBASIC.
(I think this betrays some of the internal organisation of Microsoft: wouldn't it be more sensible for the BASIC to call the editor, not the other way round? But this is in accordance with Conway's Law:
As I recall, almost no one used EDLIN outside of emergency situations. EDLIN was a *line* editor, like 'ed' on *nix systems, and I remember it being easier to use the GW-BASIC interpreter as a text editor than to use EDLIN, as it included a screen editor from the outset.
Before EDIT.COM, there were a lot of shareware editors for DOS, distributed around via BBSes and the line. The one I remember using the most was called QEdit, which amazingly has a relatively current descendant called TSEPro: https://en.wikipedia.org/wiki/The_SemWare_Editor
You remember incorrectly, then. I started my career in PC support and worked in the field for a decade. In the era of MS-DOS 3.x there was no choice: EDLIN was the only editor shipped as standard. It was not possible to use the GWBASIC editor to edit anything except BASIC programs. (Perhaps you are confusing it with QBASIC?)
Most PCs probably had a wordprocessor of some kind, but many of those were not able to save plain-text files. There was a serious risk of rendering a PC unusable if you accidentally saved CONFIG.SYS or AUTOEXEC.BAT in some rich-text format that DOS could not interpret. WordStar was about the only WP that could be use to edit plain text relatively safely.
edlin may have been the pack-in but pretty much the first app anybody "downloaded" from sneakernet was some kind of visual editor. Maybe in the corporate world it was different, but for instance, at Virginia Tech every computer came with a site-licensed copy of Kedit "installed' before the machine made it onto your desk. Kedit was a weird choice that itself wasn't entirely different from edlin, but still 1000x more usable. It was a clone of xedit, IBM's mainframe editor, which was also line based, but at least showed all the lines simultaneously.
> pretty much the first app anybody "downloaded" from sneakernet was some kind of visual editor.
I am not saying that nobody did this, but in my experience in the DOS 3.x era, we just got on with the job in Edlin. It was bad but not all that bad, and just like Vi[m] once you know the keystrokes it's pretty quick.
In tech support you usually don't get the option of installing your own binaries onto customers' kit so you have to do the job using what is there. You can't rely on _any_ external tools being present, and even if we _had_ FOSS alternatives that were legal to add to a corporate box, you couldn't, because [a] the customer might not like that [b] you might not be able to write to the disk [c] you can't go sticking your own files onto corporate machines.
undelete, unformat, drivespace, help for all commands, qbasic, edit, an anti-virus, smartdrv, defrag.. MS-DOS 5.0 was a massive update indeed! I also recall QuatroPro and MS-Word 5 for DOS wilth modern CUA interfaces (akin to edit.com)
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.
emacs may have plenty of tutorials, but the old Borland IDEs needed no tutorials to be completely usable. So I think you are letting your love and experience with emacs cloud your judgement here. Which is not to say emacs could be as easy to use as the Borland tools - with great power additional complexity is necessary. Emacs probably goes beyond that, though, with unnecessary complexity, but then anything that's evolved over 40(?) years is going to be that way.
I think that one of the remarks of the article writer is that there are no IDE for small and middle size projects. Visual Studio is great for those megaprojects with version systems and all. Emacs has a steep learning curve even if the revard is significant. Does it still have a programmability in Lisp? I would like an editor adaptable in Python.
Emacs is indeed programmable in Lisp. Most of its functionality is actually provided that way. And frankly I think that's the main appeal at this point. The control scheme is technically powerful but I'm not sure anyone positively likes it better than newer alternatives; even vi's seems to be more popular (I say this as an emacs user who never "got" vi and appreciates that emacs at least has a TUI, however minimal/bad, rather than invisible input modes).
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.
Meanwhile, the modern developer world loses its mind when "leftpad" disappears from npm...
Oh goodness do I miss the days that 64k could be called bloat.
I still do some development in visual studio 6 (first released 1999) because "hello windows" only takes about 16k, meaning that real apps can be delivered in less than 100kb. It's getting nearly impossible though, as even good old Win32 APIs have changed so much in 24 years.
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.
That is a very interesting perspective. Thanks for the details.
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.)
Do you know since when F10 opened the Emacs menu? I had no idea about this (after more than 20 years using Emacs), and various other people in HN have pointed it out. I'm also surprised it's not even mentioned in the welcome page...
I downloaded and grepped through the old Emacs releases, courtesy of Lars Brinkhoff's Emacs history repository. Text mode access to menu-bar is added in 19.29 (1995-06-19), and binds tmm-menubar (text mode menu) to F10 by default. M-` was added in 19.30 a few months later, and tmm-menubar finally gets an info entry in 19.31.
You might have had issues with tmm-menubar because of the nonstandard controls, assuming it wasn't broken in the release you used. Per 19.31's manual: "On text-only terminals, you can use the menu bar by typing M-` (`tmm-menubar'). This enters a mode in which you can select a menu item from the keyboard. Either type the initial of the item you want, or use the left and right arrow keys to choose an item and use RET to finalize the choice."
The two major Smalltalk implementations from mid 80s to mid 90s were ParcPlace Smalltalk (later updated to VisualWorks) and Digitalk's Smalltalk/V (later Visual Smalltalk Enterprise). Digitalk also had a TUI version named Methods. They were all commercial.
The first cut of Squeak Smalltalk, which is a direct descendant of Smalltalk-80, is announced in 1996. It is arguably the first open source Smalltalk that developed a significant community. There are other opened source ones (eg. Tim Budds Little Smalltalk) but they're mostly educational or single dev hobbies. I'm not sure how to classify Smalltalk/X as it was open, but almost invisible hobby project until the dev, Claus Gittinger, commercialized it in 1994.
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.
delphi was a way better product then vs those days.
rad at its best.
it is probably still is better.
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.
Yeah, that was a typo. I searched for "MS-DOS 5", incorrectly landed on the generic MS-DOS Wikipedia page, and copied the 1981 date from there. It sounded wrong, but somehow I didn't put a second thought to re-validate the date. Will fix the text.
But yeah, the jump from MS-DOS pre-5 and 5 + Windows 3.x was incredible.
> MS-DOS 5 is from 1991, not 1981
Yes, that's how I read it too, but the earlier blog post is clearer. DOS, when the PC was released in 1981, had a text editor: EDLIN. It was awful -- I speak as someone who used it every day for years -- but it was there and it worked.
You're right about when EDIT.COM was introduced, though. In MS-DOS 5, EDIT required QBASIC as it called the BASIC executable for its editor, discarding the interpreter. In MS-DOS 6.x it was a standalone app and you didn't need QBASIC.
(I think this betrays some of the internal organisation of Microsoft: wouldn't it be more sensible for the BASIC to call the editor, not the other way round? But this is in accordance with Conway's Law:
https://en.wikipedia.org/wiki/Conway%27s_law
)
As I recall, almost no one used EDLIN outside of emergency situations. EDLIN was a *line* editor, like 'ed' on *nix systems, and I remember it being easier to use the GW-BASIC interpreter as a text editor than to use EDLIN, as it included a screen editor from the outset.
Before EDIT.COM, there were a lot of shareware editors for DOS, distributed around via BBSes and the line. The one I remember using the most was called QEdit, which amazingly has a relatively current descendant called TSEPro: https://en.wikipedia.org/wiki/The_SemWare_Editor
You remember incorrectly, then. I started my career in PC support and worked in the field for a decade. In the era of MS-DOS 3.x there was no choice: EDLIN was the only editor shipped as standard. It was not possible to use the GWBASIC editor to edit anything except BASIC programs. (Perhaps you are confusing it with QBASIC?)
Most PCs probably had a wordprocessor of some kind, but many of those were not able to save plain-text files. There was a serious risk of rendering a PC unusable if you accidentally saved CONFIG.SYS or AUTOEXEC.BAT in some rich-text format that DOS could not interpret. WordStar was about the only WP that could be use to edit plain text relatively safely.
edlin may have been the pack-in but pretty much the first app anybody "downloaded" from sneakernet was some kind of visual editor. Maybe in the corporate world it was different, but for instance, at Virginia Tech every computer came with a site-licensed copy of Kedit "installed' before the machine made it onto your desk. Kedit was a weird choice that itself wasn't entirely different from edlin, but still 1000x more usable. It was a clone of xedit, IBM's mainframe editor, which was also line based, but at least showed all the lines simultaneously.
> pretty much the first app anybody "downloaded" from sneakernet was some kind of visual editor.
I am not saying that nobody did this, but in my experience in the DOS 3.x era, we just got on with the job in Edlin. It was bad but not all that bad, and just like Vi[m] once you know the keystrokes it's pretty quick.
In tech support you usually don't get the option of installing your own binaries onto customers' kit so you have to do the job using what is there. You can't rely on _any_ external tools being present, and even if we _had_ FOSS alternatives that were legal to add to a corporate box, you couldn't, because [a] the customer might not like that [b] you might not be able to write to the disk [c] you can't go sticking your own files onto corporate machines.
undelete, unformat, drivespace, help for all commands, qbasic, edit, an anti-virus, smartdrv, defrag.. MS-DOS 5.0 was a massive update indeed! I also recall QuatroPro and MS-Word 5 for DOS wilth modern CUA interfaces (akin to edit.com)
I noticed that as well... Prior to that we had CPM, DOS' predecessor...
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.
emacs may have plenty of tutorials, but the old Borland IDEs needed no tutorials to be completely usable. So I think you are letting your love and experience with emacs cloud your judgement here. Which is not to say emacs could be as easy to use as the Borland tools - with great power additional complexity is necessary. Emacs probably goes beyond that, though, with unnecessary complexity, but then anything that's evolved over 40(?) years is going to be that way.
I think that one of the remarks of the article writer is that there are no IDE for small and middle size projects. Visual Studio is great for those megaprojects with version systems and all. Emacs has a steep learning curve even if the revard is significant. Does it still have a programmability in Lisp? I would like an editor adaptable in Python.
Emacs is indeed programmable in Lisp. Most of its functionality is actually provided that way. And frankly I think that's the main appeal at this point. The control scheme is technically powerful but I'm not sure anyone positively likes it better than newer alternatives; even vi's seems to be more popular (I say this as an emacs user who never "got" vi and appreciates that emacs at least has a TUI, however minimal/bad, rather than invisible input modes).
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.