🚀 go-pugleaf

I think the following long question deserves to be clarified, as it
mixes up several concepts that we as Computer Scientists should understand:

*In article <313@bnr-fos.UUCP> schow@bnr-public.UUCP (Stanley Chow) writes:
*>In article <881@sceard.UUCP> mrm@sceard.UUCP (M.R.Murphy) writes:
*>  [Mike Murphy tells us about a list of programming errors that he has 
*>   kept over the last ten years and asks for additions.    SC]
*>>
*>>  1) Is the argument count correct?
*>>  2) Is the spelling correct?
*>>  3) Is the argment type correct?
*>>  4) Is the variable initialized correctly?
*>>  5) Do "ends" match "do"s?
*>>  6) Is the correct register used?
*>>  7) Is a previous equate, using, or define in effect?
*>>  8) Is the level of indirectness correct?
*>>  9) Are the defaults correct?
*>> 10) Is the array large enough to hold the data?
*>> 11) Is the index out of range?
*>> 12) Is reentrancy, reusability, refreshability preserved?
*>> 13) Did you let something go by that you can't explain? Fix it now.
*>> 14) Does the program have anything remotely to do with the requirement
*>>     for the program?
*>> 15) Did you start to code before thinking?
*>> 16) Did you read the manual?

SYNTAX, SEMANTICS AND FAITHFUL EXECUTION

Before going further, we should ask:  What characterizes a language?
We have to understand that a language defines a
SYNTAX (what strings are considered to be programs) and a SEMANTICS
(what do programs mean or do).  A great deal of confusion arises from
the fact that one of the most popular languages, C, has a muddled semantics
(we're not sure what pointers can do and mean; we're not sure what
variable numbers of parameters do and mean; etc).  This muddle shouldn't
detract us from the fact that languages such as Turing have exactly
specified semantics (it is mathematically clear what every construct
does, independent of any implementation).  OK, with that behind us,
we can ask: does the implementation really follow the semantics.  Before
you say "of course", ask questions like: what are the semantics of
dangling pointers, overflows, out of range subscripts, etc.  The concept
of FAITHFUL EXECUTION is defined to mean: the implementation is
required to follow the semantics exactly, or else to halt and notify
the user of the failure.   With the default checking enabled, Turing
gives you faithful execution, stopping and giving you an error
message if ever anything occurs that is outside of the language's
explicit semantics.

DIRT AND DANGER

Now let's go on to DIRTY language features, which by definition have
their meaning determined by underlying implementation details, such
as what's in a particular register (as opposed to CLEAN features, which
are mathematically defined).  Dirty features can be DANGEROUS, meaning
they can cause remote corruption (eg, emitting assembly language by
user control can cause arbitrary corruption that the language 
implementation has have almost no control over).  The Turing Plus
language introduces dirty features, in a controlled fashion, because
these are needed for certain applications.
The problem with dirt and danger is they put a tremendous responsibility
on the programer, which would otherwise be born by the language
implementation.  My guess is that C's degree of dirt and danger
costs 50% in terms of programmer productivity compared with programming
in a faithful language.

SPECIFICATION, CORRECTNESS, STYLE AND METHODOLOGY

Add to these the concepts of SPECIFICATION (what's a program
supposed to do) and CORRECTION (does the program do it) and STYLE
(can you easily read the program and figure out how the program
does it).  METHODOLOLGY means do
you know how to get from a specification to a correct program.

In languages that are generally like Turing (Ada, Modula, Pascal, maybe
	C, etc)
we have:  SYNTAX - enforced by compiler
	  SEMANTICS - produced by compiler and runtime support
	  FAITHFULNESS - enforced by generated code and runtime support
				(depending on language)
	  STYLE - depends on skill and patience of programmer
	  CORRECTNESS - depends on programmer and methodology used
 Now, the questions are categorized using these concepts:

 1) Is the argument count correct?  SYNTAX
 2) Is the spelling correct?  SYNTAX
 3) Is the argment type correct? SYNTAX
 4) Is the variable initialized correctly?  FAITHFUL, CORRECTNESS
 5) Do "ends" match "do"s? SYNTAX
 6) Is the correct register used? DIRTY
 7) Is a previous equate, using, or define in effect? SEMANTICS (DIRTY?)
 8) Is the level of indirectness correct?  SEMANTICS, FAITHFUL
 9) Are the defaults correct?  SEMANTICS, FAITHFUL, CORRECTNESS
10) Is the array large enough to hold the data?  FAITHFUL, CORRECTNESS
11) Is the index out of range?  FAITHFUL, CORRECTNESS
12) Is reentrancy, reusability, refreshability preserved?  SEMANTICS etc
13) Did you let something go by that you can't explain? Fix it now.
				CORRECTNESS, though language design
				helps tremendously to avoid shoot-in-the-
					foot-features.
14) Does the program have anything remotely to do with the requirement
    for the program?   CORRECTNESS
15) Did you start to code before thinking? METHODOLOGY
16) Did you read the manual?  METHODOLGY

The above categorization of questions shows how the corresponding
questions are handled in Turing-like languages.

HOW DOES A LANGUAGE HELP?

A language designed for productivity and
reliability maximizes the degree to which problems are eliminated or
detected by the computer, as opposed to by raw programmer acumen.

As the language becomes less faithful and "dirtier" (Turing
to Pascal to Turing Plus to C to assembler) you sacrifice productivity
and reliability (as a rule).  Similarly, as the language becomes
more interpretive and dynamic in nature (Turing to Basic to APL to
LISP) you get less syntactic help from the computer, as restrictions
designed to help you are put off to run time or eliminated altogether.

		Ric Holt