In this blog and elsewhere, you’ll often see the statement that some advanced Mathematica feature is just another application of symbolic programming. It’s the kind of idea that seems too powerful to explain in a single blog post, yet simple enough that I am tempted to try. So, here goes. Symbolic programming is based on the concept of recasting core features of human language into a computationally active form. What does it mean to have a human-language-oriented programming language? Our cognitive model of computation is typically a three-stage process: 1) describing the computation; 2) executing that description; and 3) outputting the results. The “language” part of most programming languages begins and ends with stage one. Linguistic structures are erected to describe the program. But the execution of the program is typically oriented around an entirely different system of types and objects; and likewise, the program’s output structure tends to resemble nothing particularly language-like. Symbolic programming uses linguistic structures as the foundation of all aspects of computation. From a computation’s description, to how the computation executes, to how humans interface with the results, the exact same basic tree structure is used throughout. This is a powerful unification, making possible many useful computations that in other systems range from cumbersome to practically impossible. We’ll see examples along the way, but let me first describe what these linguistic structures actually are.

I’ve been a “professional” user-interface programmer for 20 years. In that time I’ve written a grand total of three little apps just for the fun of it. Two of them I snuck in as hidden buttons in the Mathematica About Box, because it was just too difficult to start a new application from scratch. All of them can be replicated in a few minutes using Version 6. In my experience, writing GUI (graphical user interface) applications in C or Java or Visual Basic---or whatever---is fine if you plan to spend weeks or months on a program, but prohibitively horrible if you really only have a few minutes to dedicate to the task. You have to allocate windows, store pointers to them, then allocate controls or read them from some kind of resource file, store pointers to them, blah, blah, blah. It might be two or three pages of code before you can even start thinking about what this program is actually supposed to do. Cocoa and other such frameworks make it marginally easier. I enjoyed programming in NeXTSTEP (which is what Cocoa was called before Apple took over NeXT). It’s the environment in which I wrote RealTimeAlgebra in 1989, the one just-for-fun app I wrote not as an About Box button. (RealTimeAlgebra was basically what we now call Manipulate.) But it is still a pain. Instead of starting by writing pages of code to deal with windows, you start by using an annoying graphical tool to lay out controls and define who is connected to whom. Then you get to write pages of code defining the actions of all these controls before you can start working on the actual content.

Symbolic programming has been a core idea in Mathematica since the very beginning. But it is a big idea and an abstract idea. And people understandably just want to know what the bottom-line benefit is, and could care less about what went into making it happen. Fortunately, Mathematica 6 is making it a lot easier to illustrate ideas about symbolic computation in visual and interactive forms.

High-Level Functions

For starters, illustrating the core programming primitives with visual examples is a piece of cake with the new graphics and typesetting functions. For example, Map will take a function and apply it to each element in a list: NestList will take a function and apply it over and over again to the initial seed, returning a list of all the iterations: Programming in Mathematica is based on transforming trees. The built-in function TreeForm allows us to visually represent the tree backbone of Mathematica programs and data structures: