When we think of user interfaces, we normally think of what’s\u00a0provided to\u00a0“end users” of software or devices.\u00a0But programming languages are also user interfaces, because programmers are people. In this regard,\u00a0textual programming has been the overwhelmingly\u00a0dominant user interface for creating software.<\/p>\n
We know that different\u00a0user interface techniques are better and worse for different tasks.\u00a0For example, text editing\u00a0is an efficient user interface for writing email. Graphical drag-and-drop\u00a0interfaces are efficient for creating graphics and illustration. Spreadsheets are efficient for calculating many rows of numbers.<\/p>\n
It’s not at all clear that text\u00a0editing is the best imaginable user interface for creating software. It may be optimal for\u00a0some<\/em> of the\u00a0aspects 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\u00a0using 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\u00a0abstract tasks such as\u00a0algorithm design may be significantly improved with visual tools for designing, debugging, iterating, and testing. Which<\/em> specific user interface is most useful depends on the details and purpose of the component being built.<\/p>\n In traditional programming, each component has a purposefully-limited “application programming interface” (API) that defines what the component can do.\u00a0To a programmer, a component’s application programming interface is also its user interface. That is, the tools that a component provides\u00a0to a\u00a0programmer consist\u00a0of the component’s API\u00a0plus any\u00a0accompanying documentation (typically, all in text format).<\/p>\n What if such components \u2014\u00a0intended for software engineers \u2014 also came with purpose-built user interfaces? For example, a\u00a0component that performs\u00a0statistical computations could come with user interfaces for inputting data sets, tweaking parameters, and testing outputs. A\u00a0networking\u00a0component could come with user interfaces that\u00a0simulate 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\u00a0customize the widget’s behavior and appearance.<\/p>\n Today’s software is built with\u00a0one graphical interface for end users and\u00a0many layers of textual programming below. The vision here is for an alternate\u00a0programming environment that consists of arbitrary many layers of rich user interfaces<\/em>\u00a0\u2014 each interface intended for those\u00a0who are\u00a0using that\u00a0component. Lower-level interfaces (e.g. memory allocation or signal\u00a0processing) would be designed for engineers who are dealing with those layers; higher-level interfaces (e.g. graphics or\u00a0widget libraries) would be designed for engineers dealing with those<\/em> components; and finally, the top-most interface would be\u00a0the traditional one that end users of the software product actually see and use.<\/p>\n What prevents\u00a0this vision from unfolding? Perhaps the most\u00a0significant 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\u00a0to do it! So the first steps forward would be\u00a0slow and clumsy,\u00a0as 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\u00a0built\u00a0by repeatedly compiling with earlier, less capable versions of C.)<\/p>\n Of course, there is also no guarantee that this richer programming system would actually make software\u00a0more\u00a0cost-effective, high quality, fun, or other desirable qualities. It’s easy to imagine that\u00a0software engineers steeped in the current system may\u00a0never be as efficient in a less text-heavy environment. Perhaps this whole idea has already been tried and failed.<\/p>\n Yet improving the user interface of each component clearly makes the whole system more humane<\/em>. It provides an opportunity to augment\u00a0the logical-verbal-dominated software engineering\u00a0process with a fuller range of human visual, kinesthetic, social, and emotional skills. Who knows where that might lead?<\/p>\n","protected":false},"excerpt":{"rendered":" When we think of user interfaces, we normally think of what’s\u00a0provided to\u00a0“end users” of software or devices.\u00a0But programming languages are also user interfaces, because programmers are people. In this regard,\u00a0textual programming has been the overwhelmingly\u00a0dominant user interface for creating software. We know that different\u00a0user interface techniques are better and worse for different tasks.\u00a0For example, text … <\/p>\n