Afterwards, in the decades that followed, software programmers found it difficult to move past monospaced type as the medium for mainstream computer code. There have been attempts to transcend it, especially in the 1990s, but none have succeeded, with the result being that people have given up and concluded that plain text is the only medium code can have. That is very far away from the truth of the situation, if the goal is changed to upgrade code from within its existing conditions rather than impose something from the outside from the outset. In many computer programming circles, there is strong resistance to upgrading any aspect, in part because of the many previous attempts and how they fell short, implying that it just can't be done.
Yet, at the same time, in the last decade there has been much more interest in adding enhancements for monospaced code, in all modern IDEs (code editors). There are, increasingly, insertions of GUI conveniences that work alongside the plain text code, to make the overall software engineering situation more consistent with the complexity of modern software.
Everything is taking place to make programming better except upgrading the plain text itself, to something beyond what it is. Plain text is the main bottleneck to progress for code, and moving past it will produce a programming dynamic more in keeping with the display and computing technologies of today, when storage, RAM, and processing power are much greater, in exponential proportions.
This throwback appearance persists due to the absence of graphic design specialists who would be working alongside the computer scientists and software engineers shaping software development tools at various commercial enterprises, like Apple, Microsoft, or Google. The two disciplines of graphic design and computer science are too far away from each other, with very few individuals carrying interests or skills in both, and there are few who would become involved in this particular topic in a direct way. Unfortunately, collaboration between graphic designers and computer scientists will be rare until there are deliberate efforts to bridge their communities on this matter.
There are growing signs that this is an unrecognized possibility that would be very attractive to the current environment, viewed in light of recent developments.
This demonstrates that the mainstream software development community is seeking much more from code’s interactive dynamic than unprocessed plain text. Though programmers may believe strongly in plain text as their best choice for code, they are, in practice, moving away from it by adding so many enhancements. Any nostalgia for the command line has to face up to this reality, that the computer user couldn't copy and paste lines of text into the old computer terminals, as people do with the GUI terminal windows today. There is, thus, a blending of GUI and plain text taking place that has to be transcended. Put in different terms, it is unrecognized jerry-rigging of GUI enhancements in plain text (.TXT).
In the view of the mainstream programmers and the computer companies themselves, there is officially no change happening to code anywhere, just tweaks to make it better. But these tweaks are too substantial for that claim to hold up: in any code editor of the 2020s, there is usually a “code-folding” GUI feature built into left margin of the text view, sitting next to the code line numbers. After these come to be utilized regularly by the larger software development community, they have in fact altered the dynamic that code has, beyond its plain text origins. Many of these features are exposing the inadequacy of how code exists when it consists of plain text. (Noctivagous states that the goal should be to start over with a document file format and make that the basis of code, but in combination with new user interface principles that rely on keypresses instead of tedious mouse coordination and clicks.)
These GUI code-folding arrows that are placed in the left margin that allow collapsing or expanding sections of a plain text (.txt) code file are sort of upgrade without formally acknowledging an upgrade. Plain text has a UI but it is too basic, so efforts are frequently made to compensate for its deficiencies when it is forced to make software that is so large. At the same time, the UI provided by plain text is indeed more effective. It cannot be escaped through superficial efforts. A person truly has to be involved in the UI at a deeper level to transcend plain text.
So the first goal for the programming community is to acknowledge what is true: if it is now mainstream to depend on a blend of GUI gadgets and plain text in order to make code, then mainstream programming relies on shims. As more veneer is placed onto plain text like this, what gets lost is that programmers are actually communicating all the time that they want to interact with a formally-established document file format, because that is in effect what they are provided already by the modern IDE. Of course they don't realize they are saying that or that their actions suggest this. All of these added GUI controls and widgets relate exactly to that outcome if the situation is seen for what it is, because it is an interactive media document file format that supports these modern software features, not terminal type (.TXT).
No software engineer would start a project from scratch by designing GUI components that interact with plain text. In other words, code editors are moving towards, without actually taking the step of doing it, the upgrade of computer code’s form, away from the old terminal type. But because they don't do it on purpose, the outcome is getting more forced and strange. This isn't saying that it is inevitable that code will move towards a document file format, but that this should be the goal.
If there is any remaining dispute about this, When a line of code is entered and there is a chart of information produced as a result, code has changed. These are the kinds of features that interactive media and graphic designers should be involved in.
If a large community of the graphic designers were introduced to code, as something for them to examine for improvement, the topics that would come up first would likely be: the absence of any page layout, the lack of any meaningful organization in the code. There are no headings, no outlined boxes, no columns of text. There are no side columns for making notes. And of course, it isn’t even possible to embed an image inside the typical programming language code file.
The undifferentiated appearance of a file of code, and the large amount of screen space waste produced by having only one column (newspaper page layout) of functions at any time, would be obvious missed opportunities to a graphic designer. But if something does not change, that graphic designer or interactive media specialist will not be invited by computer science professionals to a code conference to intervene in the matter. Instead, code will get incremental add-ons that modify the current situation passively, placing graphical user interfaces on top of plain text.