Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!mips!apple!rutgers!deimos!dino!cs.iastate.edu!hascall
From: hascall@cs.iastate.edu (John Hascall)
Newsgroups: comp.lang.c
Subject: Language principles
Message-ID: <490@dino.cs.iastate.edu>
Date: 2 Feb 90 21:29:25 GMT
Sender: usenet@dino.cs.iastate.edu
Distribution: na
Organization: Iowa State Univ. Computation Center
Lines: 64


   [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@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