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)

- (
**Unambiguity**) Every well-formed expression in the concrete notation should correspond to a single instantiation of the abstract syntax. - (
**Expressiveness**) Conversely, every abstract syntax instantiation should be describable in at least one way using the concrete notation. - (
**Preservation of quality, I**) Every “natural” concept in the abstract syntax should be easily expressible using the notation. - (
**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. - (
**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). - (
**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. - (
**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. - (
**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.

ICREA Research Professor at Internet Interdisciplinary Institute (UOC). Leader of the SOM Research Lab focusing on the broad area of systems and software engineering. Home page.

I like the bit ‘… principles we should almost follow..’ I suspect it’s a typo, but somewhat universal practice.

I’m sorry, I close the door on way out

I suspect my subconscious mind introduced this typo 🙂

“by relieving the brain of all unnecessary work,

a good notation sets it free

to concentrate on more advanced problems”

– Alfred North Whitehead (mathematician and primary author of Principia Mathematica with Bertrand Russell)

It feels like it would be prudent to also bring Wittgenstein and his view of context and knowledge to the table.

That on the table, the relativity of criteria like ‘natural’ and ‘suggestive’ might be worth reflecting further upon.

While I intuitively agree much to the list above, I found myself repeatedly in a situation where a language I love (be it foreign- or self-designed) and feel highly productive with does not induce the same feelings in others – and vice versa.

This happens on an individual level, but also with social groups of various sizes – technical languages, jargon. But then, that’s already implied in mentioning Wittgenstein.

I wonder, if there is, next to obviously working field testing, a way to qualify/quantify these criteria in advance while designing languages, to reduce trial-and-error-loops.

Adaptability of languages also comes to mind, and surely these criteria apply to the adaptability-meachnisms themselves.

I think it comes down to agreeing what the common language is for a given area of knowledge. That agreement essentially becomes the context. E.g. a modern aircraft needs to support both navigation and propulsion – completely different areas of knowledge, each with its own unique set of terms, expressions and jargon. Were I think debates about languages gets lost is that discussions focus on weather French or English is the best language for expressing the knowledge of e.g. navigation. The critical point is that the terms used in navigation are useful to efficiently discuss and communicate the important things that constitutes the subject matter of navigation. French or English can be equally efficient in this regard. However, trying to discuss propulsion using navigation lingo will probably be very difficult.

So, to exemplify with a useful MBSE-rule; The same word/term/expression can’t be present in two different contexts/domain specific language, having the exact same meaning. If there is a need, Separation-of-concerns will be broken and the model is missing something of vitality.