Comparison of UIs as languages

Communication uses languages. Communication involving computers (human-computer and computer-computer) is no exception.

The languages that are used at the "lowest level" are usually called programming languages: the machine language on the bottom, and general purpose languages, GPLs, right above it. This blog analyzes "higher level" languages, usually called user interfaces or domain-specific languages, using the following attributes:

• Expressiveness: a measure of how well the language covers ideas and concepts of its domain i.e. how "much" can be said in the language.
• Ergonomics: a measure of how "easy" it is to use the language. An ergonomic language has little noise (high "semantic density") and redundancy.
• Integratability: a measure of how easy it is to use the language from other languages.
• Implementability: a measure of how easy it is to implement such a language.

Internal textual languages (APIs)

Internal API

• All functionality is implemented by this so no other language can be more expressive.
• Inherits unfiltered noise from the implementation GPL, which may reduce ergonomics significantly.
• Integration is possible but laborous and introduces hard dependencies on volatile implementation details.
• As an essential part of every program requires no extra implementation effort.

Public API

• Some unsafe or otherwise unwanted expressiveness is removed when publishing an API; something essential may be lost, too.
• As a tidier version of the internal API this language may be somewhat less noisy, but not much.
• Integration is easier and more robust than using the internal API, since accidental details are hidden. The type system of the GPL often makes API-level integration the preferred form of integration, but only within the same GPL.
• Implementation is usually quite straightforward, but requires some "distilling" to make a good API.

API bindings for another GPL

• As another version of the public API this language should be as expressive.
• Depending on the new GPL, this language may be either more or less ergonomic than the original public API. And since this language is probably implemented later, it might be possible to learn from the mistakes of the original public API.
• Increasing integratability is the motivation for creating this language, but this way it happens one GPL at a time.
• Implementation is straightforward but dull and technical.

External textual languages

A language based on the Command Line Interface framework

• Expressiveness may be reduced due to the restrictions of the framework: only one line can be used, and its length may be restricted.
• The framework (shell) introduces some noise, like whitespace escaping, but this is often relatively minimal.
• The shell makes it easy to generate sentences for this language so integration is easy.
• CLI argument parsing is usually easy to implement.

A language based on some other metalanguage

• Proper metalanguages don't restrict expressiveness.
• The metalanguage may introduce some noise, but it is usually on the concrete syntax level.
• A common metalanguage makes it easier to integrate languages. Furthermore, if the producers and consumers of this language utilize streams instead of files, integration is very easy and powerful via pipes.
• Implementation requires work on the abstract syntax and semantics level, but the metalanguage helps a lot.

A fully custom language

• There is no restriction for expressiveness.
• This is potentially the most ergonomic language, since its design can be completely dictated by domain-specific concerns.
• The lack of a common metalanguage or framework reduces integratability somewhat, but textual format helps a lot.
• This is the most laborous textual language to implement.

Non-textual languages

GUI

• This is usually the least expressive language, since many ideas cannot be expressed as gestures.
• If the domain is expressible as gestures, the mapping is usually very intuitive and ergonomic. The gesture metalanguage introduces certain noise, though, and long sentences are laborous and slow to express.
• Integration is often virtually impossible: GUI gestures are difficult to automate, manipulate and reroute reliably.
• Certain "standard" solutions may be relatively easy to implement, but often GUI tweaking takes a lot of time. One reason may be that there are often many stakeholders with their subjective opinions about good GUI design.

Other languages

Speech interface is a variation of a custom textual language, but not yet practical to implement. It's interesting to see what other language types emerge.