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.

3-in-1 Programming Languages

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.

User Interface

When a programmer wants to read, write, or edit a program it is the source code that that programmer views. There are a variety of integrated development environments that streamline bits and pieces, adding colors and tool-tips and so on to make things more clear; there are even automatic code generation tools that create bunches of common code for you; but in the end of the day, programmers are interfacing with code more or less directly.

File Format

Programming languages are file formats. They specify, down to the byte, how a program is represented on disk. There’s no concept of “‍save as‍” in programming, nor is there anything in the file that the programmer didn’t put there intentionally.

Semantic Model

Programming languages define what is meant by each language element and thus which tasks are easy to specify and which tasks are harder. This is hugely important; even the corner-case nuances of a language often impact the ordinary programmer in significant ways. I’ve personally been known to abandon a familiar language and learn another completely from scratch simply because some tiny element of language design made what I wanted to say painfully difficult in the old language.

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.

The Long-Overdue Divorce

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.