Introduction

(Last updated on 12-2-21.)

Since the 1980s, computer code has never been modified to accommodate the new graphical capabilities of computers. It still takes the form of plain text.

Even though screen resolutions have densified with each passing decade, the appearance of computer programming remains primitive, hardly different from the days of monochrome terminals.

For professional computer users, the GUI simply makes movable frames (windows) for the type of text that sat inside terminal screens.

The right half of the screen is empty. The placement of code on a page (that is, its layout) has never been recognized as an independent subject or concern. This image demonstrates that the plain text format imposes severe limitations on modern programming. Plain text does not allow deliberate arrangement of code elements.

When computer code's external form is not updated to match the complexity of today's software applications, programming becomes brittle. Instructing a computer requires unnecessarily painstaking processes:

Typing this out would normally be regarded as an exercise in self-torment if it weren't associated with the dazzling output of a computer. These array values should be contained in graphical boxes, not entered with curly braces, spaces, and commas.

In the last decade, some completely graphical programming languages have entered mainstream use, but these fall short in terms of completeness and usability.

Using them entails stringing together "nodes" into flow diagrams.

As a result of this situation, the commercial software industry developed the following notion:

1. code that is typed out in plain text makes software.
2. graphical programming will always be limited to auxiliary or niche purposes.

But in reality, there have only been graphical nodes offered to the programmer. This is only one graphical approach to code.

Furthermore, nearly all modern programming languages could adopt markup instead of plain text, quite easily, and the benefits would extend in many directions.

Plain text is showing its age as the medium of computer programming:

• Functions cannot be arranged horizontally, to make effective use of screen space on widescreen displays. When a code file is very lengthy, it is tedious to scroll through.

  // Not possible in today's code files: 

  func makeRectangle() { // try editing here. }

  func makeCircle() { // try editing here. }

• IDEs do not provide any sort of project maps (analogous to floor plans) for quick navigation of a project. This can be done, but the plain text format does not lend itself to a map layout easily. An interactive map can reveal multiple levels of detail according to the adjustment of its scale, allowing for swift surveying of large code repositories.
  
• Many programming endeavors are absurdly laborious relative to their subject matter. This becomes more obvious when discussing semiotics-based programming languages.
• Depending on the task, the programmer must constantly consult documentation, often looking up dozens of terms per day, because there is a need for consolidation of programming keywords. As code libraries have grown in size and complexity, so has programmer reliance on Q&A websites like Stack Overflow, largely because code lacks any conceptual facets.
• In the future, code files should be comprised of markup, not plain text, so as to enable rich formatting, interactive elements, page layout, and improved lexical analysis for the compiler.
  • A plain text code file does not naturally reveal its underlying containers or nesting levels (as follows).
    
    
    
  • Today's programming languages do not accept units of measurement within the code (e.g. 15in × 20in), nor do they allow working with fractions (e.g. 3½ ÷ 1⅐). As important as ratios are, they are also not supported syntactically in the code (e.g. hdRatio = 16:9). Many such areas have been neglected. Mathematical notations of all kinds are completely absent and geometric figures cannot be accommodated at all.
  • Too many characters have been reused for different purposes (e.g. asterisks stand for pointers, multiplication operators, and also comment blocks), creating confusion and ambiguity at first glance.
  • A compiler must sort out what the plain text data contains without the benefit of markup, which would provide structure and hierarchy inside the code file. Currently, if a single curly brace is accidentally deleted in a code file, this can confuse a compiler to the extent it returns dozens of false errors. A stray character can also produce the same result.
• Without realizing it, the programmer is constantly maintaining the code's legibility with the spacebar and delete keys, because a file of statements like y=x+2+z cannot be kept in such a compact form and also stay readable. Inserting and removing spaces is a source of fatigue, and a solution is to pre-pad certain characters so that spacebar and delete do not have to be pressed.
  
  
  
• Many staple characters of programming should be made independent of the Shift key because they are typed so frequently:

  ( )  { }

  :  !  @  #  $  %  ^   &   *  -  =

  Therefore, making a standard QWERTY keyboard with a key layout modified for programming is a topic of discussion. This keyboard would feature an extra row of keys (or columns) with these characters so that they can be pressed right away.

There are unrecognized opportunities to upgrade text-based code and incorporate interactive, graphical features, which will set software on a new course.

When this happens, computer programming will take a big step into the future.

Download a PDF summary (4.5MB) of the website.

Example Rearrangement of Plain Text Code

An if statement encloses a for loop, arranged in such a way that the presentation is better suited for very long files. (2X zoom, Redesign.Codes method).

Next: Code Layout