[TYPES] Declarative vs imperative

[Mark Janssen]

> But one man's specification is another man's algorithm.
>[...]
> Similarly, a C program is a specification for a hundred different
> machine code algorithms that manage memory, register allocation etc.

It is so odd that the field is so amiss regarding terms.  It mirrors
some of the turmoil I've been experiencing in the programming arena.
The c2.com wiki shows this also.  It seems a new "renaissance" is
needed where the field can re-evaluate where it's been and start
staking down terms which have been bandied about and either diluted or
misused.

A C program is not a specification in any sense (if it's even
appropriate to call C source text a "program", prior to compilation
into an executable).  Only the theorist who has never gotten "close to
the machine" could ever say that.  I strongly suggest actually trying
simple assembly language programming on a common CPU architecture to
understand the path between Programming Languages and actual
implementation to get a clear understanding of the very concrete
relationships between source code, machine instructions, memory
pointers, and execution.   A C program is something that is actually
*executed*, after the compiler transforms it, from the language
definition/specification, into hardware instructions specific to the
CPU (ex. Intel386), on hardware implementing a binary logic
architecture.   One never executes a specification, at most, one
applies it.

Further, unless one is a hardware engineer, one never talks about
"machine code algorithms".  In the software world, one only talks at
most about machine code instructions.  Outside of the days where
programmers flipped switch banks to make a computer do things, there
is a very clear boundary between *hardware* and *software* and they
are completely orthogonal.   I feel this is where the theorists of
lambda calculus have crossed a boundary into machine execution where
things are completely different and governed by strict binary logic
(not parsers or lexical definitions), implemented, further, by
electrical circuits which have to obey the *laws of physics*.   The
relationship between program language definition and actual hardware
is important and not something that can just be ignored.  It is
something informed by math of binary logic (AND/OR/and NOT gates) and
governed by the laws of physics.  One does not have to sacrifice the
pure world of math and theory.

It's like confusing the trees for the forest or the program on a
Turing Machine from the linear symbols on the tape.  They are both
perfectly clear (at least to the programmer), but also completely
different from each other.

Sorry if my words are a bit blunt, but I'm trying to make clarity out of chaos.
-- 
MarkJ
Tacoma, Washington