Engineering Principles

Le Chatelier's Principle

Principles of Language Design

One of the better phrasings of Le Chatelier's Priniciple is:

If a stress is applied to a system at equilibrium, then the system readjusts, if possible, to reduce the stress.

M. J. Sienko and R. A. Plane, Chemical Principles and Properties, 2nd ed., McGraw-Hill, New York, NY, 1974, p. 216.

Technically, this priniciple applies only to chemical reactions. However, experienced practioner's will recognize its applicability to a wide range of domains.

Henri Louis Le Chatelier was a French industrial chemist from the turn of the 20th century (1850-1936). In 1884 he published the following observation:

Any system in stable chemical equilibrium, subjected to the influence of an external cause which tends to change either its temperature or its condensation (pressure, concentration, number of molecules in unit volume), either as a whole or in some of its parts, can only undergo such internal modifications as would, if produced alone, bring about a change of temperature or of condensation of opposite sign to that resulting from the external cause.

H. L. Le Chatelier, Comptes rendus, 99, 786 (1884).

Another version, 1888 is a bit more concise:

Every change of one of the factors of an equilibrium occasions a rearrangement of the system in such a direction that the factor in question experiences a change in a sense opposite to the original change.

H. L. Le Chatelier, Annales des Mines, 13 (2), 157, (1888).

From: B. J. MacLennan, Principles of Programming Languages, CBS College Publishing, 1983, pp 526-527.

1. Abstraction: Avoid requiring something to be stated more than once; factor out the recurring pattern.
2. Automation: Automate mechanical, tedious, or error-prone activies
3. Defense in Depth: Have a series of defenses so that if an error isn't caught by one, it will probably be caught by another.
4. 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 of the information needed to implement the module correctly, and nothing more
5. Labeling: Avoid arbitrary sequences more then 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.
6. Localized Cost: Users should only pay for what they use; avoid distributed consts.
7. Manifest Intefaace: All interfaces should be apparent (manifest) in the syntax.
8. Orthogonality: Independent functions should be controlled by indepedent mechansims.
9. Portability: Avoid features or facilites that are dependent on a particular machine or a small class of machines.
10. Preservaton of Information: The language should allow the representation of information that the user might know and the the compiler might need.
11. Regularity: Regular rules, without exceptions, are easier to learn, use, describe, and implement.
12. Security: No program that violates the definition of the langauge, or its own intended structure, should escape detection.
13. Simplicity: A language should be as simple as possible. There should be a minimum number of concepts with simple rules for their combination.
14. Structure: The static structure of the program should correspond in a simple way with the dynamic structure of the corresponding computations.
15. Syntactic Coinsstencey: Similar things should look similar, different things different.
16. Zero-One-Infinity: The only reasonable numbers are zero, one, and infinity.