I was thinking about Mandelbrot sets again today, as a metaphor for the difference between the static and dynamic aspects of programming. The static equation of the Mandelbrot set (Z <- Z2 + C) is relatively simple, while the dynamic behavior (a fractal) is relatively complicated.
Suppose you wanted to write a program to calculate a Mandelbrot set. It's a lot easier to just write down the static equation in your program than it is to try to write down what the resulting fractal should look like. "Well it's symmetric, of course, and it also has lots of spirals and branches and tendrils, and they're all connected to each other, and... well... it's hard to describe".
On the other hand, sometimes it's easier to describe the dynamic behavior instead of the static behavior. For example, if you're dealing with a client-server system, it's easy to say "no request should ever cause it to crash or hang". But it's difficult to write code in such a way that this is guaranteed.
In other words, fractals have simple specifications but complex behavior. In contrast, distributed systems have simple behavior, but complex specifications.
A holy grail of programming would be to be able to work on whichever side of the static/dynamic divide is most appropriate for the problem you're trying to solve. Sometimes it's easier to just write the code in some imperative language than it is to specify the emergent behavior. Other times you want to specify constraints on the emergent behavior without bothering with the implementation details. And in most programs, you'd like to be able to do both, and have both sides influence each other.
I think it would be interesting to explore the interplay between these two ways of seeing programs. The yin and the yang, as it were. I find it intriguing that most of the successes in CS so far seem to be based on describing the dynamic behavior of a program by examining the static code. Type theory fits into this category, as does static optimization, formal verification, etc.
We've had much less success (or maybe just less research effort) going the other direction: specifying constraints that the dynamic behavior of a program should fulfill, and then deriving a static implementation automatically. This category includes logic programming, constraint programming, etc.
It's not obvious to me why it seems to be easier to deduce dynamic behavior from a static specification, than it is to interpolate a static specification from dynamic requirements.
Posted on November 28, 2003 12:21 AM
More programming articles
Interesting thought. Pardon the levity of my response, as I'd really like to give it a little more thought, but the first thing that came to mind was a parallel with the logical process: producing dynamic behaviour from a static specification is a process of deduction, ideally an isomorphism (well, barring compiler bugs, language ambiguities, environment interactions and so forth); producing a static specification from dynamic requirements, though, is an inductive process, isn't it? Wouldn't the largest difficulty come from automating the creation of a potentially ambiguous static specification, then incrementally refining that into a state of workability (if not unambiguous representation - but, as noted above, even the result of the inverse process is not free of potential misinterpretation in practice)?
This seems similar to the theme explorered in the book "Watch What I Do", a book about programming by demonstration (the full text of which is available at the above link) which I picked up some months back but which has remained unread since then. Have you looked into this at all?
Posted by: Gnomon at November 29, 2003 02:36 AMYou're right, it is a matter of induction versus deduction. And I suppose it's always possible to handle deduction -- if you don't have a theory of how a set of rules will play out, you can simply brute-force it by running them manually, and find out. And computers are really good at that.
Induction, on the other hand, requires that you come up with some theory of how to proceed. In the general case, it requires creativity and inspiration. And computers are really bad at that :)
As for programming by demonstration, I have come across it a couple times but never really gotten interested. I think I just haven't seen any applications of it that are sufficiently general, and sufficiently powerful, to cross my threshold of interest.
