Programming Languages are Antiquated.
The first computers were people. The first mechanized computers were programmed when they were designed. Then came reconfigurable computer programmed by moving wires. Universal computers came along that accepted programs in binary. Binary was abstracted into text: first with assembly, then with programming languages. And that’s where things stopped.
The idea behind programming languages is relatively straightforward: define some unambiguous textual description of actions a computer can take and write a program that translates that text into the low-level action specifiers used by the computer hardware. There are myriad of such languages, each one defined a little differently and targeting a different set of tasks.
A programming language serves three main purposes.
Most programming language research (PL) focuses on the semantics. There are research papers that touch on the interface and even a few that address efficient file formats, but most PL work focuses on type systems and formal semantics and other theoretic underpinnings that impact the meaning of each phrase in the language.
The combined constraints of the three functions of programming languages have no intrinsic need to be combined.
My second postulate is quite simply that we would be better served if we split the user interfaces, file formats, and semantic models into three separate concerns. Since the 1990s we’ve had the space to store better files and the visual technology to present more than just text. I believe it is mostly attrition that keeps them all the same thing.
There have been many efforts to deviate from the text-is-everything model of programming. Most of these, though, have taken the form of some kind of “visual programming language”: that is, the separation is accompanied by an unproven and disruptive change in how we ask programmers to work. Once it becomes clear that programs are annoying to edit using the visual widgets of prototype tool X, every idea associated with tool X collapses.
Divorce is never easy. I suspect the correct way to proceed is with what software engineers call a “refactoring”. That is, we change the inner workings and structure without changing the visible surface at all. Programmers are accustomed to interacting with source code, so leave the source code interface visible. Change the file format to something more structured and extensible: perhaps JSON, XML, or YAML, since they are widely available. Leave the existing semantics and compilers/interpreters, just tweak the front-end to accept the data described by the new file format in liu of the old parse and annotate stages.
Once the separation exists, flexibility will follow. High-cost analyses can be performed and stored in the file format without that storage interrupting programmer views. Editing activities may be tweaked to interact directly with internal representations instead of current code-completion and highlighting editors duplicating compiler effort. Multiple views may be integrated into the “language” in an orderly ans systematic way. Etc.
What will grow out of a better design for programming I do not know. But I do know that if you give a programmer a more flexible tool you’ll be amazed by the things they do with it.
It’s high time for programming languages to get a divorce.