Primary Design Goals

• Modern — Meet today’s programming requirements.
• Correctness, reliability and safety may not be sacrificed.
• Prohibition of magic — Intuitive explicit syntax instead of magic implicit syntax.
• Clarity and maintainability of source code through literate syntax, especially for readers other than the author.
• Obsolescence when necessary, non-interference of backwards compatibility concerns with any of the above principles.

Targeted Areas of Application

• Suitability as a safe alternative to C in systems development.
• Suitability for mathematics, engineering and mission critical systems.
• Suitability as a core language for domain specific supersets.
• Suitability as a general purpose application development language.
• Suitability as a teaching language to teach engineering principles and best practises.

Simplicity Guidelines

We followed the Einsteinian simplicity principle “as simple as possible, not any simpler.” but we did not elevate simplicity to the status of dogma. Simplicity is a means to an end, not an end of itself. The end must be one of the primary design goals. Simplicity may thus sometimes be sacrificed for correctness, reliability and safety. Orthogonality of syntax is desirable when possible, but not at the expense of simplicity and clarity.

Safety Guidelines

All built-in facilities must be type safe by default. Where type safety needs to be broken, it may be facilitated through explicit unsafe features. These must be marked unsafe and enabled by import from pseudo-module UNSAFE or optional pseudo-module ASSEMBLER. No other source of unsafe facilities shall be permitted.

Feature Omission Guidelines

In the context of modern programming practise, if we found the omission of a feature to be reasonable and justified then we considered its removal. Conversely, if we found its omission to to be unreasonable and unjustified then we rejected its removal. We aimed to avoid oversimplification.

Feature Addition Guidelines

We considered a new feature for adoption if a clear need could be demonstrated and if we found it to be reasonable and consistent with the overall design philosophy. We put a particular emphasis on suitability for systems implementation and systems programming as well as interfacing to C. We aimed for the ability to replace C as a systems implementation language.

When considering the addition of a feature, we looked at it in the context of the weight of the entirety of features, not in isolation. We observed an imaginary baggage allowance, whereby items had to be removed to make space for others to be added. Our aim was to avoid feature creep.

Backwards Compatibility Guidelines

If a certain practise is outdated, such as the use of octal numerals, then a feature that has no other use than to support that practise can no longer be justified and consequently we removed it without any regard for backwards compatibility of source code. Instead, a source to source translator tool should be seen as a suitable solution to backwards compatibility issues that arise from removal of outdated features.