I’m trying to start blogging more about the work that I’m doing. Here’s a short essay I wrote yesterday introducing the idea of non-symbolic programming. The essay is below the fold.
Programming is traditionally thought of as a symbolic endeavor. The programmer creates a string of symbols (or, sometimes, as in the case of parallel programming or visual programming, a network of symbols). And those symbols represent structures in machine code. This approach is immensely powerful. Very simple symbolic languages can be Turing complete. More complex languages can facilitate all manner of wonderful software engineering practices. And in fact the symbolic nature of these languages is what gives them much of their power. Symbols allow for massive nested, highly interdependent, human comprehensible computational structures.
However, symbolic languages have their weaknesses. One of these weaknesses is that they are difficult to learn. There are significant benefits for people to learn how to do “computational thinking”, but the boundaries to doing so are quite high. It simply does not come naturally to many.
Many creative solutions to this problem are being explored. Graphical programming environments like Alice make syntax management much easier, and provide better incentives to try to learn how to program. They also remove the necessity for system administration tasks like setting up a build environment. Programming by demonstration (PBD) systems like StageCast can be much easier to learn and use. And pseudocode parsers like [Allen Cypher's Project] make languages much more forgiving while providing powerful scaffolding for useful web applications.
However, all of these are symbolic languages. Pseudocode in [Allen Cypher's Project] represents API directives, which represent bits of machine code operating in a web browser. PBD systems are essentially graphyical representations of if-then loops. But if we step back from our currently rigid definition of programming, a world of alternatives opens up.  Instead of thinking of programming as manipulating strings of computational symbols, I would like to propose another definition: programming is intervening in a computational system in such a way that the future behavior of that system is substantially different.
The definition of “substantially different behavior” is, of course, problematic. Clearly bolding a word, while leading to slightly different behavior (the next time the user clicks the bold button, it will *un*bold) is not a *substantial* change. The fact that the button toggles boldness remains. On the other hand, a user installing an application leads to a substantial change, and could be considered a very simple kind of programming. And obviously writing a PERL script creates entirely new behavior. There is no clear line between these categories. They lie on a spectrum, and that makes this definition of programming much fuzzier than the traditional definition.
However, therein lies its power. Along this new spectrum lie a vast set of possibilities for programming systems which balance power and human comprehensibility. By wedging a trash can between a door and its frame, the behavior of a computerized security system is catastrophically (or helpfully) altered. Such an intervention cannot be reduced to a change in a symbol string. Yet, it alters the behavior just as powerfully as a carefully concocted line of code.
And the power of this particular kind of intervention–jamming a trash can in a door frame–is that it’s completely transparent to almost everybody. It’s easy to discover, easy to learn and easy to do. It’s my hope that throughout
