Programming languages designed for application software development are more capable than a few decades ago, but not by much. Any progress has occurred inside the plain text file format. They haven't been upgraded in a comprehensive way that utilizes the new graphical capabilities of computers. It's all terminal type. To give an illustrative example that adds to the two shown above, an object variable should be assignable to an interactive vector field in the code editor. A UI control embedded in a line of code can do much more than alphanumeric type in complex situations, across a wide range of subjects. Instructions can someday be expressed semiotically, even, if graphics are embraced as elements inside a line of code. So far, there has never been a semiotical programming language system.
When graphics are included, the resulting depth of command over the operations of a computer will not be matched by any current sequence of plain text. Small experiments have shown that this is much superior, it's just that there are doubts expressed by some over whether it can match the speed of editing plain text— in other words the user interface. We address this here. What seems like an insurmountable obstacle— making graphical code's interface comparable to plain text in editing power— is actually a matter of taking a different approach. Always, previous attempts abandoned too much of what was in active use in plain text code and tried to come up with something foreign, which means that the code conventions did not match what people try to do when they program. Instead, Noctivagous' plan is to gradually add augmentations to plain text as it exists today. At later stages, code can break free from plain text and sit inside its own document file format. So, initially it is that UI and widgets additions are allowed inside plain text code, just like right now when a color can be assigned to a color picker control. After a color picker has been used in code for a while, it is missed when not available. In this way, graphical widgets and controls won't only be a matter of convenience. When they are placed into code, they will be able to summarize large sequences of computer instructions such that no one will want to go backwards to just typing out regular terminal type (monospaced type).
The importance of this effort can be explained in the following. Producing a competing web browser engine that is as complete as Chromium or WebKit can't be done in a short period of time, and when this isn't possible it represents a dead end for software development. Those two software projects will never be unseated because there is little incentive to surpass them, as what is written from scratch with current programming languages will basically end up being the same in outcome. Even with AI programming assistants, this does not change because those engines have reached the ceiling of what plain text code will manage without an upgrade.
It is possible to break past this dead end, and it is by leaving the fusion of code to the typewriter. For a major upgrade to happen, alterations like the above image have to occur, because code has to look more like the software it produces, not just raw, monospaced type. It has to be able to express complex operations in terms of signs and symbol someday. Computer science mindsets that refuse collaboration with graphic design won't suffice, then, as software development has stayed inside terminal type all this time. When code is upgraded, the initial subjects of concern turn out to be different; they will have to incorporating graphic design and media design principles. The areas of expertise involved are often outside of what is found in mainstream software engineering discussions.As explained in the articles on this page, the obstacle to a deeper level of progress in software development is the confining, primitive offerings of the file format plain text, that it has been stretched far beyond its bare capabilities to serve increasingly large and complex needs, blowing past the environment of 1980s computing. This primitive code medium doesn't lend itself to showing up as a zoomable map like CAD, and it of course by definition cannot accommodate rich text inside the code without adaptations.
A collection like an array or dictionary is still not editable by way of a data table GUI control. Instead, the programmer clumsily navigates through commas with the arrow keys. In addition to this, future computer code needs to be editable in multiple newspaper-like columns to make efficient use of screen space. Plain text is too raw of a file format for programming software in the 21st century, and it doesn't allow inclusion of modern GUI controls for formulating groups of instructions.
Noctivagous starts with the plain text code as programmers work with it today and then adds GUI to that as the first step, continuing the trend of exists today where the value of a color variable is controllable by an inline color picker. It is believed that later the code file should be transformed into a document file format for truly rich code editing. Each article below explains these issues.
Noctivagous will let you wire up application windows as if they are nodes in node-based programming, because the input and outputs will be on the back of the window and it can flip around. Different applications will interact with each other, providing their complex features to each other, publishing and receiving data as the user decides.