Before digital designers "invented" the stored program (reinvented, actually — the concept had already been put to use in things such as player pianos and weaving looms), the only way to give a circuit functionality was to form connections between components. Algorithms were expressed completely in terms of those connections. The more complex the algorithm, the more connections required. ICs (integrated circuits) were a stopgap measure in slowing the proliferation of space-hungry connections. But ICs did not really solve the complexity problem. Since they were not programmable, and could not be produced economically except in mass quantities, they were designed to solve only general problems. Designers still had to resort to "glue" chips to create specialized functionality.
Then along came the stored program, a godsend to digital system design. It provided a way to achieve nearly unlimited functionality with a limited, and even small, number of interconnections. In simple terms, a physical barrier to computation was broken. It was good cause for celebration.
Today we seem to have come full circle, and then some. Industry pundits are now talking about a kind of "programming-by-assembly," which involves snapping together software components as if they were Legos, or, if you will, ICs. Recent advances in object technology have certainly made this scenario more plausible. DCOM and CORBA offer language-independent components. JavaBeans offers, at least in theory, components that will run on any platform. A revolution seems to be at hand.
But a problem with revolutions is that they tend to demonize as well as liberate. The chief victim of the nascent component revolution is procedural programming. Its close companion, the algorithm, has been put on notice; even the executable statement is suspected of being an enemy of the people. Procedural programming is a method that expresses solutions in terms of processes. A program is a process containing a sequence of subprocesses, themselves containing subprocesses, and so on. We are now given to believe this view is passé, if not downright unhealthy. A recent article in another magazine has even suggested that new programmers not be taught procedural programming, lest they be hindered in their journey toward object-oriented programming. I think that advice is misguided.
the new programmer, nothing illustrates the modular nature of programming — of "boxes within boxes" — as simply and directly as procedural programming. It was this modular nature, so easily seen in a Fortran subroutine, that hooked me forever on programming. I dare say that if my first programming class had launched into a stuffy discussion of attributes, interfaces, polymorphism, etc., I might have sworn off computers right there and then.
idea that programming-by-assembly will be less complicated than other forms is probably wishful thinking. Recall that circuit design with non-programmable components was severely limited — just hooking together chips, no matter how elaborate, eventually hit that old wall of complexity. I expect software components to fare no better. The only workaround is to a) write more glue code (probably procedural code) or b) resort to component customization, and its attendant headaches of software configuration management. You just can't get nothing from something.
Component-based programming actually looks to me like a good thing. But to suggest that procedural programming must now be a bad thing is shortsighted. Programming is still a mixture of process- and object-oriented concerns. Maybe someday we'll be rid of the "burden" of writing executable statements. I fear that what replaces this burden will be an enormous amount of bookkeeping. For now, I'll enjoy the things that drew me to programming in the first place — the problem solving, the step-by-step coding, the algorithms. Programming is still a heck of a lot of fun, and I aim to keep it that way as long as I can.
Marc Briand
Editor-in-Chief