February 2003

I was programming and I noticed a pattern; meta programs are really slow.

My DBOS project is about abstracting a computing system. Each level of abstraction made the DBOS run slower by an order of magnitude. Recently, once I demanded the "next level" of abstraction from the DBOS (specifically being able the execute its own code), the slowdown was another order of magnitude! This was unacceptable, not just for my patience (and the users) but from the point of being able to debug such slow-running code. I have wasted too many hours, days (?months?) of my life just waiting for the damn machine to get to my break-points. With 90% of development being debugging, any code speedup will also speed development proportionally.

There are two solutions to my problem. First, being able to run code backwards is very interesting and helps with debugging for sure, but does not help with the user experience. The second solution is to have a dynamic code optimizer. The "dynamic" nature of the optimizer is necessary because the program will still be changing while I am in the process of debugging. It would be nice to run optimized code until I get to the frame that I have my break-point in.

My problem with the DBOS is only one instance of a greater problem that the whole software industry must contend with. Computer science needs to create the Dynamic Partial Evaluator (DPE) in order to solve and inevitable speed crisis that will stall software innovation.

Machine speed will not keep increasing as it has in the past. (See http://firstmonday.org/issues/issue7_11/tuomi/index.html that shows Moore's law has been changing definition over the years to fit the observations). A limit to Moore's law may not be technical, but financial in nature. The millions of average consumers are the only ones capable of funding the aggressive chip enhancements that we have seen though the 90s. Unless there are alluring applications that demand better machines, there will not be the need investment in faster processors, and machine speed will not increase. We see this happening now, with reduced computer purchases. Machine speeds may halt completely in 10 to 20 years.

Lisp (a macro system) makes writing high level code easy to write, but the result runs wretchedly slow and is useless as an actual system. Java Beans (a component system) is designed for first order data management but can only be used at the application level, or run too slow to be useful. Both types of programs can be made to run faster, but only if code length is increased exponentially. Without machine speeds increasing we have to depend on software optimizations, but this is an area of computer science that is still in its infancy.

In general, patterns (macros and components) are an excellent form modular programming. By having a set of abstract patterns to choose from, the application programmer can develop much faster. Unfortunately this can only be done in theory because current compilers can not optimize the calls between the pattern objects. We will need a high level optimizer in order to take advantage of pattern programming. DPE is needed to perform those high level optimizations so that high level specifications are able to run on limited hardware at reasonable speeds.

Without DPE we will not have a continued increase in computing speed, and we will not be able to take advantage of pattern programming. Faster programs will be necessarily larger programs, imposing a financial limit on what our society will be able to create. The end of software innovation is nigh. That means no more cool discoveries into what computers can do. No non-obvious optimizations. Definitely no AI.

I am not saying that all innovation will halt, only software innovation. For example, we can still expect prototype tools to reduce software project time-line variability (an interface innovation). The Semantic Web is still an infant, but is not a software innovation, but rather a development in formalizing taxonomy to the masses.

DPE will, of course, be "discovered", and software innovation will continue.

And then what is possible when all we build now can be built in the same time it takes to make a prototype? What patterns will we see in the code that allows us to abstract to an even higher level? I want to see this next level of abstraction, and so I am building the DPE.

April 2002