DAVE'S LIFE ON HOLD

Thoughts on the Future of Programming

> On Tue, Jul 19, 2011 at 1:36 AM, Ken 'classmaker' Ritchie 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 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.