It’s always interesting to see how other fields talk about modeling. We have already discussed how modeling principles go beyond software, so  we can clearly learn from them (and conversely, bring our expertise to try to solve their issues better when possible).

A perfect example is this MathOverflow post, where Terence Tao, one of the most prestigious mathematicians, discusses the quality of a good notation. Indeed, choosing the right notation (or “notations”) for a new language is crucial to ensure its adoption by the target set of end-users. And while there is no universal strategy to come up with such notation (e.g. an approach could be to let the users themselves vote the notation they prefer) there are a few principles that we should all follow. As an example, the Physics of notation does a good job in elaborating on some of such principles for graphical notations. Or, more generally, the Cognitive Dimensions of Notations framework is an approach to analysing the usability of information artefacts.

Tao’s post goes in this same line of notation principles to respect and even if he does so focusing on mathematical notations I think what he says is also perfectly applicable to our modeling language / DSL notations. Let’s review them (note that I rephrase the text to make it closer to our terminology)

1. (Unambiguity) Every well-formed expression in the concrete notation should correspond to a single instantiation of the abstract syntax.
2. (Expressiveness) Conversely, every abstract syntax instantiation should be describable in at least one way using the concrete notation.
3. (Preservation of quality, I) Every “natural” concept in the abstract syntax should be easily expressible using the notation.
4. (Preservation of quality, II) Every “unnatural” concept in the abstract syntax should be difficult to express using the notation. [In particular, it is possible for a notational system to be too expressive to be suitable for a given application domain.] Contrapositively, expressions that look clean and natural in the notation system ought to correspond to natural objects or concepts in the abstract syntax.
5. (Error correction/detection) Typos in a well-formed expression should create an expression that is easily corrected (or at least detected) to recover the original intended meaning (or a small perturbation thereof).
6. (Suggestiveness, I) Concepts that are “similar” when expressed as instances of the abstract syntax should have similar expressions in the concrete syntax notation, and conversely.
7. (Suggestiveness, II) The calculus of formal manipulation on the language should resemble the calculus of formal manipulation in other languages that users of the language are already familiar with.
8. (Transformation) “Natural” transformation of concepts in the abstract syntax (e.g., change of cardinalities) should correspond to “natural” manipulation of their symbolic counterparts in the concrete syntax notation

Some of these properties are especially important when the concrete syntax we choose is not something brand new but icons and keywords that users may already associate a semantic with. In that case, we should avoid surprises in the way the DSL behaves even at the concrete syntax level. He also recognizes that we can have more than one notation for the same abstract syntax, depending on the application scenario and user profile.

Tao also comments on the costs of a notation:

• “one-time costs” of a notation (e.g., the difficulty of learning the notation and avoiding standard pitfalls with that notation, or the amount of mathematical argument needed to verify that the notation is well-defined and compatible with other existing notations)
• “recurring costs” that are incurred with each use of the notation.

As usual, whether one type of cost is predominant over the other has to do with the number of people and projects where the notation will be used.