A recent essay about why natural language isn’t computer code has been making a few rounds through the PL community. It seems to celebrate the precision required in computer languages, the differences between coders and writers. The article concludes:
Fundamentally, good writers are empathetic, human and stylish. Good coders are literal, formal and algorithmic. To take the coding-as-prose analogy too far is to misunderstand the essence of both.
I’d love to develop software that is mostly empathetic, human, and stylish, with just a few stilted algorithmic bits where I really need them. And while state-of-the-art languages don’t support it today, all the components necessary for it have been developed in different systems. Here is what I believe we can do to make programming languages more natural:
- Use probabilistic or weighted grammars, to allow for programs that contain possible errors.
- Leverage constraint systems and searches for code that achieves goals. This allows the user to underspecify the code, and the compiler to fill the gaps with something that is at least moderately sane. When we don’t like the compiler’s results, we refine our constraints, much like we refine searches to any search engine. This allows us to sketch our code and still achieve something useful.
- Support rough fitness heuristics – soft constraints and weights, cost-benefit analysis, a user model of known preferences. This allows us to push towards “better” models that fit the user’s intention.
- Leverage paraconsistent logics, which allow us to constrain the propagation of inconsistency. This can allow us to program by analogy and metaphor, without following those analogies “all the way down” to the extremes where they fail in silly ways. This could allow a much richer model for mixins, traits, compositions.
- We can develop semantics that reduce commitment to action, i.e. allowing users and developers to understand the consequences of their programs (not just locally, but in a real system) without committing to those actions, allowing opportunity for refinement. I.e. allow takebacks.
- Our programming models, IDEs, and UIs can better provide explanations of how they are interpreting the code. This allows users to know when the computer knows what the users mean, with less guesswork and greater confidence. In return, this refines a communication skill in users, who will learn quickly what to clarify up front and what can be left to search.
- We can extend to live and interactive programming, with a real dialog in both directions, where the computer itself can ask for clarification in the case of ambiguity or unknowns. Live, interactive programming is also a very viable approach to UI in the future age of ubiquitous computing.
No strong AI is necessary, though something like a domain-specific AI tends to be a natural consequence of any programming model that utilizes heuristics, searches, and a few caches or traces for performance and stability (which models learning).
I believe that, one day, even our written words won’t be static, opaque things only for humans to read. The documents we write will be live documents, capable of composition and gathering information resources, providing explanations, include interactive examples and training exercises, interactive fiction, etc.. But this won’t happen unless it is easy to write such documents – i.e. just as easily and imprecisely as we hack English today.