Language principles
John Hascall
hascall at cs.iastate.edu
Sat Feb 3 08:29:25 AEST 1990
[Note: this has nothing at all to do with #define OR || argh!!!]
**** Hopefully that horse has had enough, so I offer up my own. ***
Inside the front cover of "Principles of Programming Languages",
by Bruce J. MacLennan is the list:
ABSTRACTION: Avoid requiring something to be stated more than
once; factor out the recurring pattern.
AUTOMATION: Automate mechanical, tedious, or error-prone
activities.
DEFENSE IN DEPTH: Have a series of defenses so that if an error
isn't caught by one, it will probably be caught be another.
INFORMATION HIDING: The language should permit modules designed
so that (1) the user has all of the information needed to use
the module correctly, and nothing more; (2) the implementor
has all the information needed to implement the module correctly,
and nothing more.
LABELING: Avoid arbitrary sequences more than a few items long;
do not require the user to know the absolute position of an item
in a list. Instead, associate a meaningful label with each item
and allow the items to occur in any order.
LOCALIZED COST: Users should pay for what they use; avoid
distributed costs.
MANIFEST INTERFACE: All interfaces should be apparent (manifest)
in the syntax.
ORTHOGONALITY: Independent functions should be controlled by
independent mechanisms.
PORTABILITY: Avoid features or facilities that are dependent on a
particular machine or a small classs of machines.
PRESERVATION OF INFORMATION: The language should allow the
representation of information that the user might know and taht
the compiler might need.
REGULARITY: Regular rules, without exceptions are easier to learn,
use, describe, and implement.
SECURITY: No program that violates the definition of tha language,
or its own intended structure, should escape detection.
SIMPLICITY: A language should be as simple as possible. There
should be a minimum number of concepts with simple rules for
their combination.
STRUCTURE: The static structure of the program should correspond
in a simple way with the dynamic structure of the corresponding
computations.
SYNTACTIC CONSISTENCY: Similar things should look similar, different
things different.
ZERO-ONE-INFINITY: The only reasonable numbers are zero, one, and
infinity.
What I am curious about is:
How do you think C scores using this list as a measure?
Specific examples? Counter-examples?
What do you think of the list? What's missing? What's
extra? What's insightful? What's just plain wrong?
Everyone wants to be a language (re-)designer...hopefully with this list
we have the framework for a rational discussion.
John Hascall / ISU Comp Ctr / hascall at atanasoff.cs.iastate.edu
Ante mare et terras et quod tegit omnia caelum unus erat toto naturae
vultus in orbe, quem dixere chaos: rubis indigestaque moles... Ovid
More information about the Comp.lang.c
mailing list