What Is This?
Today I’m writing about the embryo of a crazy idea I’ve had. It hasn’t yet passed the tests of usefulness and feasibility. I can’t yet clearly visualise what the implementation of the idea looks like. I’m writing about it in order to clarify my thoughts, and perhaps to spark your own related crazy ideas.
Prelude
I believe in improving the tools and processes that we use. As a software engineer, one tool that I use is a compiler. When writing software, my role is to communicate to the compiler enough about what a program should do; the compiler’s role is to understand my communication and, from that, construct the actual program. In an ideal programming language, the process of communicating the program internals to the compiler (that is, writing the source code) should be as smooth and intuitive as possible. (Another trait of an ideal programming language is that a developer should be able to quickly understand any piece of source code, but I’m going to put this trait on a shelf until I’ve developed my idea a little bit.)
In normal life, the most natural and intuitive way that I communicate a concept, however complicated, is through a conversation. If I want Ashley to understand my idea, I start by explaining the most basic points of my idea. He gives me some indication that he understands, so I explain a few more points. He draws some inference from what I’ve explained, and he asks me, “So does that mean that the discombobulators would need to be defenestrated?”. I see his line of reasoning and reply, “Yes, but only until the phase nebula has set.” At this, he’s totally confused and asks “What’s a phase nebula?”.
The Idea
My idea is this: mightn’t it make development smoother if we could build up our software through a conversation with a programming language? Put aside for the moment everything you think you know about programming languages. Imagine what it could look like at a first pass:
Welcome to [insert name of language]. > when user says add task to (workspace) with (description): … * create task with description, workspace … * append task to tasks to review of workspace … Confirm: task is object with description, workspace [y/n]? y Confirm: workspace is object with tasks to review [y/n]? y I don't understand what description is. >
In this example the interaction is English-like, but it doesn’t have to be. It might be quicker for a developer to enter some symbolic short-hand that resembles source code for an existing language. But as you communicate with the language, it builds up its own model of what you’re trying to express. It may make assumptions on the way. Some assumptions may require your confirmation. The language may be so certain of other assumptions that it only asks for your confirmation if it stumbles upon an apparent contradiction. For this idea to work properly, the language would need to keep track of which parts of the program internals are its assumptions and which parts you specified. There’d need to be a way for you as the developer to correct or refine something that you’d previously said. And there’d need to be a way for the language to repeat back to you what you’ve said in its own “words” (this is likely to be more succinct and precise than your original words).
But IDEs Already Do All That
Sure, there are IDEs out there that give you feedback about the inconsistencies in your code, and even ones that will, at the click of a button, make some attempt to correct your mistakes. But if you think that that’s all there is to my idea, you need to go back and reread the bit where I said “Put aside for the moment everything you think you know about programming languages.” Existing IDEs are focussed around the single way we currently write software: by editing text files. Let’s explore the possibility that there’s another way to write software, a way that complements good developers’ thought processes and improves the efficiency of software development.
Feedback
In any sort of endeavour, your cognitive feedback loop is important. Unless you enjoy the thrill of flying blind, you want to be able to see the results of your actions. The shorter the time between initiating an action and seeing its results, the better. A drawback with reducing programming to a conversation is that this feedback loop is using only a fraction of the available bandwidth, and isn’t taking advantage of the possible media. That is to say, if you explain some of your program to the language and the only feedback you get is “Ok” or “Yep”, then we’re regressing to the days of BASICA and GW-BASIC, and we’re certainly not utilising the graphical potential of modern devices.
Wouldn’t it be clever if the language displayed some sort of graphical representation of the part of the program internals that you’re currently describing—perhaps some sort of mind map, perhaps a flowchart, or perhaps something else? The display should be presented in such a way that it’s easy for you as a developer to judge how well the program internals correspond to your own mental model of the program. This means that the language’s “mental” model of the program should be structurally as close as possible to yours. (This raises the question of what exactly is a developer’s mental model of a program. Does the developer’s mental model change between first inventing software and maintaining it?)
Of course, once the program internals are visually displayed, why shouldn’t the developer manipulate those internals visually? This strikes me as a really good way of making minor tweaks to a program. But the way that we’re used to communicating as humans is verbally, and so I’d guess that that’s how we’d be best at expressing things like what a new section of the program should do, which part of the program we’d like to edit, and possibly even changes of the program’s behaviour.
Maintaining Software
Way back in the prelude to this article, I said that in an ideal programming language, a developer should be able to quickly understand how a part of a program works by looking at the internals (I actually said “source code”, but by now you should have got the idea that a language may not have source code as such). The reason I temporarily put this language trait aside is that programming languages which aspire to this ideal usually do so by having source code which is succinct, neatly laid out, and explicit rather than implicit. But here we have the idea of a language without real source code. All things considered, I think that having a visual representation of program internals as described in the previous section would go a long way towards making programs maintainable. The language would also need to have ways for a developer to quickly navigate through the program internals. From my experience the three most important navigation tools would be: (a) a way of seeing the the definitions of symbols (to do the job of ctags); (b) a way of finding all uses of a symbol (to do the job of grep); and (c) a way of navigating to the part of a program that performs a particular action, calculation or decision.
What Now?
This is still only the embryo of a crazy idea. There are many details to be filled out. I can’t yet say for certain whether implementing the idea would be feasible. If it is, I can’t yet say how useful the implementation would turn out to be. I can’t yet clearly visualise what such an implementation would look like. I can’t even say how much time I’ll spend thinking about this idea before another crazy idea demands my focus. If you like this idea, please let me know! I spend more working on projects when I know others are interested. And perhaps you’ve got some time on your hands. I hear collaborative projects often last longer than individual projects.
