On Tue, Jul 19, 2011 at 1:36 AM, Ken 'classmaker' Ritchie <
[email protected]> wrote:
> Break the program free from its representation? How, other than by
> transforming one representation to another? Actually, certain
> transformations might yield great benefits, in perception or execution!
>
That's the entire point of our current complier / editor technology stack:
- The human interprets a program in the context of their knowledge of the
programming language, its libraries, and general culture.
- The compiler interprets a program in the context of a specific machine
architecture and instruction set.
- The computer interprets a program as a sequence of electrical impulses
traveling through the system.
The limits of each layer in the stack force certain compromises on the realm
of possible transformations. Since human computing power is still
relatively more plentiful, we shift the majority of the burden to the human
layer for understanding. But as computing becomes more ubiquitous in the
material world we can start entertaining programs like:
to toggle is to turn the led on for 1000 ms and then turn it off ;
Now this program is understandable by even my 4 year old. She helps me
build circuits for fun and she's loves playing with leds and motors. The
hardest thing for her to grasp is ms but she calls that "really really fast
fast", but she knows what a second is. Now if I add a little color to this
program, I actually have one programming environment that can interpret it
as is:
to toggle is to turn the led on for 1000 ms and then turn it off ;
If you notice, I've highlighted the salient terms. And I'm cheating here
because this code is taken directly from Chuck Moore's Colorforth Primer
http://colorforth.com/primer.htm but with embedded comments making it into a
more literate style. The colorforth system can interpret this code because
some of the semantic information is tagged on each word to describe its role
in the representation. But there is no reason that a sufficiently complex
system could not do the following:
- perform a statistical analysis to determine the probability that each
term in the sentence is significant
- compile the most probable variations into object code
- ask a human which one does the right thing
If you apply a similar rigor to the definition of test code you could
engineer reliable software systems for which there is no program in the
traditional sense. The specification of the system is informal, subject to
vagaries in interpretation, and in effect not a lot different from handing
off a spec to a bunch of programmers in another country who don't speak your
language :)
While it might be helpful to have a formal language and jargon to talk about
specific constructs. And it might be better to write everything in a more
formal linguistic style to improve the odds of getting the correct
interpretation, it would not be a prerequisite for use. While you are
transforming one representation to another, a sentence to object code, the
gap between the human mental model and the computer is bridged through
artificial understanding.
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
