全部博文（230）
分类：
2009-09-26 22:07:07
To ease the process of construction of high quality programs (especially in what concerns correctness), it is not enough for a programming language to have all or most of desired mechanisms; the way they are put together and their usability are also essential.
On language design Hoare [Hoa73] notes that programming languages should help the programmer in the most difficult aspects of programming: program design, documentation and debugging.
The first fundamental rule presented by Hoare for good language design is simplicity, which can be stated as follows.
Rule 1 (Simplicity) A programming language should be simple to understand and use.
Of course a programming language is a tool to express solutions of problems, so although simplicity is essential on the implementation of its fundamental properties and mechanisms it is not a reason to ignore them. Otherwise an elusively simpler structure in the programming language may cause a much higher complexity in the programs. This leads to another essential rule: completeness.
Rule 2 (Completeness) A programming language should implement the mechanisms, and have the properties considered essential to its methodology of problem solving.
The second essential rule presented by Hoare regards safety on language constructs usage.
Rule 3 (Safety) Programming language mechanisms should be prevented from producing meaningless results.
This rule justifies, for example, the use of a static type system – which prevents the occurrence of type errors at run time – and it will also be essential for evaluating the proposed concurrent mechanisms.
Other less essential rules should be taken into consideration when designing programming languages. That is the case of efficiency, which promotes the language use in resource demanding applications.
Rule 4 (Efficiency)
The programming
language should not compromise the automatic generation of programs
which make
an efficient use of system
resources (CPU,
memory, etc.).
Meyer [Mey92, appendix B], presents two other rules.
Rule 5 (Uniqueness)
The language design
should provide one good way to express every operation of interest;
it should avoid providing
two.
Rule 6 (Consistency)
The language design should
never depart from a small number
of powerful ideas, taking them to their full realization.
Other guidelines can be formulated which go along with these rules.
Rule 7 (Abstraction)
Programming language constructs
should be completely defined using only their external abstract behavior,
regardless of implementation.
This rule promotes simplicity. The external abstract behavior of programming language constructs should be made simple, regardless of their possible implementations. Simple mechanisms are sometimes hard to implement correctly. For example, the ability to covariantly redefine feature signatures in Eiffel (which is a simple and useful behavior), is difficult to implement in order to ensure a safe system [Coo89][Mey97, page 621].
Rule 8 (Orthogonality)
Programming language
constructs should be made as orthogonal
as possible, in order to make them work correctly regardless
of being used
together with others.
The observance of this rule simplifies the language semantics, and is a guarantee that no undesirable side-effect will occur when its mechanisms are jointly used. It is important to note that orthogonality applies to the constructs essential semantics, not to their eventual implementations. The implementation of a language mechanism may depend heavily on the context in which it is used. For example, the uniform inter-object communication mechanism (feature call or message passing using Eiffel or SmallTalk terminology) can be reused in a concurrent system for either of the two types of processor communication: shared memory or message passing.
