Applications Are Languages

An application program can be seen as defining a language, or rather, two languages, one internal and one external. Internally, the functions which make up the program can be seen as application-specific extensions of the core language, meant to facilitate the expression of the application. Program libraries are themselves a type of mini-language, which the ClientProgrammer uses to perform basic tasks which are not part of the core language.

Externally, the program interface provides a sort of 'language' with which the user communicates his or her intentions; even in the case of system services, they have an interface (a program name) which the system has in turn been scripted to use. An application's language in a GUI system may be composed of menus, icons and so forth, and may overlap heavily with that of the operating system (which has it's own language), but it is nonetheless a programming language of sorts.

Would this perspective improve usability? What would happen if we apply the lessons learned about language design - orthogonality, modularity, consistency, and so on - to UserInterfaceDesign? Is it feasible to try and design the internal language so that it closely mirrors the external design, and would it help either the programmer or the user to do so? -- JayOsako

Yes, it would improve usability. Yes, you should apply lessons learned from language design to UI design, though there are peculiarities to UIs that add their own constraints (for instance, the total number of methods in any class must be constrained). And yes, you should absolutely always make the internal language not merely "closely mirror" but actually BE the external language because it would GREATLY help the user/programmer to do so. -- RK

---

I'd propose a better title: InterfacesAreLanguages?. 'ApplicationsAreLanguages' irks me a bit; it's like saying 'HousesAreDoors?'. But that isn't really what is intended here.

---

Perhaps, though I would argue that doing so would be to take the idea too literally. What I am proposing is not so much the creation of an actual language a la the InterpreterPattern (though it would lend itself to that) so much as using language design as a model for interface design. While it wasn't what I originally was thinking in terms of, it occurs to me that I am really proposing a formalism for UI design, in the way that UML is a formalism for object relations.

Let me elaborate upon this. The idea here is to view the interface - either for the programmer internally or for the user externally - as a series of possible expressions, and rules for how to combine and automate them. For example, if I were writing a text editor, I might model the set of operations with something like this:

 Primitives:
     file:
       create new file
       load to current buffer
       save from current buffer
       close

     display:
       refresh display
       scroll display up
       scroll display down

     edit:
       create new buffer
       insert char
       delete char
       replace char
       set insert/replace mode
       move insertion point forward one char
       move IP backwards one char
       move IP forward one line
       move IP backwards one line
       select area
       copy selection to kill ring
       delete selection
       paste from top of KR

     search:
       compare text
       match regular expression to text
       find next match in buffer

... and so forth. I specifically chose text editing because it has been specifically modelled as a language in the past (eLisp) and is known to be amenable to this approach; I am uncertain how general this approach is at this time, nor have I worked out all the details of how to represent what.

I realize that this is not a new concept, and that I have not fleshed out this particular approach yet. I do not know if it is a viable approach or not. Any constructive input on this would be welcome, as would be any pointers to relevant existing work. -- JayOsako

EditHint: Merge with LittleLanguage. ''I disagree; that page is already too large and this is a sensible sub topic of it. -- .gz