Language Design: Familiarity

Familiarity is a tie-breaker, not a self-sufficient argument

In the past, many languages did not pick up easily adoptable language design improvements and opted for familiarity instead, often in a misguided attempt to keep perceived language complexity down.

Examples include¹:

• C’s broken operator precedence² spread to many other languages, most of whom have little in common with C.
• C++’s use of <> for generics, which was adopted by languages that – unlike C++ – had better options available.³
• C#’s design of properties, picked up by languages that did not suffer from C#’s legacy of fields and methods.⁴

The benefits of familiarity (“it is easy, because I have seen it before”) are limited to those who “have seen it before”, while the benefits of simplicity (“it is easy, because it was designed this way”) apply to everyone, regardless of experience, schooling or development history.⁵

Therefore, it’s best to treat familiarity as a tie-breaker: to be used sparingly, only when the pros and cons of different design options have been fully explored, and it has been determined that no design has an edge above the other.

But if one design has arguments for it, and another design has only familiarity on its side, language designers of the future are implored to pick the former to stop propagating the same language design mistakes further and further into the future.⁶