Part I, II
In Part I, I argued that software construction should be strictly compositional and modeled on a hierarchical framework. I wrote that every computer application (or sub-component) will be organized like a tree and will be a branch in the universal tree of all applications. In this post, I argue against the linguistic approach to computer programming and I explain why the tree is the perfect organizational model for software composition.
No Fun For You
Many have argued that the linguistic approach to programming has adequately proved itself in the last half-century and that there is no reason to change to a new approach. My response is that the linguistic approach is what is keeping the computer revolution from reaching its true potential. The reason is that language is purely descriptive in nature and, as such, forces the application designer to learn a complex set of description rules that have nothing to do with application design. The designer’s freedom to create is limited by the non-interactive and tedious nature of the process. Worse, there is no quick and easy way to reuse previously written code in new programs. The end result is pages of code that are hard to decipher and debug because the relationships between objects are not obvious. Creating things is supposed to be fun but writing code is anything but; unless, of course, you’re a computer geek. Is it any wonder that certain cultures and women in general are under-represented in computer programming? The stuff that is out there is boring, ugly and painful. Some of us have no patience for it.
The Other Way Around
Computer programming, as it is now practiced, consists of communicating one’s intentions to a computer via a special language that is easy for the computer to interpret. From my perspective, this is primarily what is wrong with the linguistic approach. A tool should accommodate the user. That is to say, the programmer should not have to learn how computers think in order to communicate with them. I think it should be the other way around. I think it is the computer that should be trying its best to understand the programmer’s intentions and react instantly and intuitively. Consider that humans learn best through trial and error, through direct manipulation and interaction. This is the reason that video games and programs like Google Earth and graphic editors are such a pleasure to use. My thesis is that, since programming is a constructive activity and since humans enjoy using parts to build bigger parts, the programming environment should look and feel like an interactive video game for constructing things. The computer should make it as easy as possible for the programmer. While focusing on the task at hand, the programmer should be able to forget that there is a computer somewhere doing its magic to keep the interface working flawlessly. Programming should be fun.
Masters, Slaves and Hierarchies
Nature teaches us that the best architecture for composition and classification is the tree. The proper function of governments and other organizations is possible only because they are hierarchically structured. My thesis is that the main reason that compositional programming tools have not revolutionized software construction is that there are no master/slave relationships between components. The effective control of behavior (turning an object on or off) among cooperating entities is impossible without such relationships. Object-oriented class hierarchies, as a counter example, are not organized with behavior control in mind. Objects are really of the client/server type, which is not the same thing as master/slave since neither controls the other. Constructing a hierarchical tree of concurrent behaving objects is impossible unless there is a clear understanding as to what controls what. That is to say, every object must be designed in such a way as to form master/slave relationships with other compatible objects.
Another problem with current compositional tools has to do with locating the right components from the component repository. A keyword-driven component database can quickly turn into a horrible mess. The trick is to have a system that automatically organizes the components in the database. That is to say, the system should automatically position every component at its correct level and correct branch in the tree. This is possible only if master/slave complementarity is consistent from top to bottom. It suffices to count the levels in the hierarchy. For example, an object may interact (via a gender-enforced lateral connector) with another object inhabiting the same level in the hierarchy but can neither control it (turn it on or off) not be controlled by it. Thus a designer can quickly locate a component by traversing the appropriate branch.
Proper component factoring is essential to effective reuse and composition. Factoring consists of breaking down a component into two or more smaller components that can be used separately. This should not be the responsibility of the programmer but should be handled automatically by the classification mechanism. This can be done by comparing components to see if certain parts of a component are repeated in others. The system can instantly and autonomously break the components into smaller parts. This eliminates redundancy and atomizes parts into the finest possible granularity at a given level of abstraction. Fine granularity makes for easier composition by broadening the choice of components.
The Universal Tree
I foresee the need to maintain a single universal tree of all software components somewhere on the Internet, preferably with the branches distributed throughout the Cloud.
The figure above depicts a hierarchy of components. This could be a single branch within a larger universal tree of applications. As the tree becomes populated, new applications become easier to compose using existing components. Organizations and individuals can still have secret components on their own private servers, if they so desire, but they should make sure that their component repository is properly synchronized with the free global tree. Additionally, it should be possible to insert a component into the public tree without publishing its internal composition. Having a public tree will encourage reuse and eliminate frequent reinvention of the wheel. It goes without saying that all software development tools should have access to the universal tree. More to come.
COSA, A New Kind of Programming
Why I Hate All Computer Programming Languages
How to Solve the Parallel Programming Crisis
The COSA Control Hierarchy