When we think of user interfaces, we normally think of what’s provided to “end users” of software or devices. But programming languages are also user interfaces, because programmers are people. In this regard, textual programming has been the overwhelmingly dominant user interface for creating software.
We know that different user interface techniques are better and worse for different tasks. For example, text editing is an efficient user interface for writing email. Graphical drag-and-drop interfaces are efficient for creating graphics and illustration. Spreadsheets are efficient for calculating many rows of numbers.
It’s not at all clear that text editing is the best imaginable user interface for creating software. It may be optimal for some of the aspects or tasks that are involved in software creation, but probably not all or even most. For example, it’s relatively clumsy to design, debug, and iterate on graphical front-ends using a textual representation. That’s why Apple and others provide tools like Interface Builder to help with some of these tasks in a more visual way. But even more abstract tasks such as algorithm design may be significantly improved with visual tools for designing, debugging, iterating, and testing. Which specific user interface is most useful depends on the details and purpose of the component being built.
In traditional programming, each component has a purposefully-limited “application programming interface” (API) that defines what the component can do. To a programmer, a component’s application programming interface is also its user interface. That is, the tools that a component provides to a programmer consist of the component’s API plus any accompanying documentation (typically, all in text format).
What if such components — intended for software engineers — also came with purpose-built user interfaces? For example, a component that performs statistical computations could come with user interfaces for inputting data sets, tweaking parameters, and testing outputs. A networking component could come with user interfaces that simulate network performance over a range of conditions and help programmers choose appropriate settings. A component that provides a front-end widget such as a button or slider could provide convenient user interfaces so that engineers can easily customize the widget’s behavior and appearance.
Today’s software is built with one graphical interface for end users and many layers of textual programming below. The vision here is for an alternate programming environment that consists of arbitrary many layers of rich user interfaces — each interface intended for those who are using that component. Lower-level interfaces (e.g. memory allocation or signal processing) would be designed for engineers who are dealing with those layers; higher-level interfaces (e.g. graphics or widget libraries) would be designed for engineers dealing with those components; and finally, the top-most interface would be the traditional one that end users of the software product actually see and use.
What prevents this vision from unfolding? Perhaps the most significant factor is the difficulty and cost of building rich user interfaces. This is a chicken-and-egg problem: building rich user interfaces is hard, in part, because we are using text editors to do it! So the first steps forward would be slow and clumsy, as we start building richer components without good tools to do so. However, over time, as we use the tool to build the tool, we would expect to start receiving dividends. (This is analogous to how the C language was built by repeatedly compiling with earlier, less capable versions of C.)
Of course, there is also no guarantee that this richer programming system would actually make software more cost-effective, high quality, fun, or other desirable qualities. It’s easy to imagine that software engineers steeped in the current system may never be as efficient in a less text-heavy environment. Perhaps this whole idea has already been tried and failed.
Yet improving the user interface of each component clearly makes the whole system more humane. It provides an opportunity to augment the logical-verbal-dominated software engineering process with a fuller range of human visual, kinesthetic, social, and emotional skills. Who knows where that might lead?