Nouns and Verbs
Sun Nov 5 20:04:26 EST 2006
Recently I have been reading "The Structure and Interpretation of Computer Programs" by Abelson and Sussman, (or "the wizard book" as it is also known). This describes the fundamentals of computer programming, using the Lisp dialect Scheme as the example language due to its ability to treat functions as data and vice versa. The ability to treat functions and data on the same footing leads to a whole new way of programming, since programs can be designed that work by functional composition rather than operations on data structures.
Why is this fundamental? It boils down to how we as humans use language. We use language to describe the world around us to ourselves and other people. While it is a fallacy that tribes having no word for the colour blue are unable to see that colour (for example) there is a grain of truth - the ability to translate perception into different sensory channels reinforces events and brings different processing mechanisms into play. Consider the different ways you would process a conversation presented as a sound recording, visual waveform or transcript.
Concentrate on the narrative channel. Think of the fundamentals of language. Nouns and verbs - objects and actions on objects. That is all that data oriented or procedure oriented programming means. The fundamental question is either "What stuff is there in the system?" or "How does the stuff in the system interact?".
One approach is to tie down what the nouns are and then write the program focussing on the verbs. "Here is a brick. We can combine bricks in this way to make a wall. Here is a wall. We can combine walls this way to make a room. Here is a room. ...". The key concept here is defining the combination operators for the underlying datatypes at each level.
The other approach is to focus on what we want to ask the objects to do. We say "This object is like this other type of object, so we can ask it the same questions as the other object as well as these extra questions". "Here is a shape. We can ask the shape where its centre is. Here is a circle which is a type of shape. We can ask where its centre is by asking its parent type, or we can ask the circle what its area is. Here is a shape container. We can ask the container where all of the shapes inside it have their centres (it will ask them itself)".
So which approach is better? It seems to me (I was going to say "obviously" but that is usually a keyword that you're missing something) that both approaches are valid, and at some levels of abstraction one may be more appropriate than the other. This means that a method of converting from one [idiom|paradigm|model] to another can be useful. One way of doing this is to introduce an abstraction layer between layers of different type (boundaries are also fundamental. Walls make good neighbours.) to act as a glue layer between the two concepts. "Here are bricks. We can ask each brick where it is located. Here is a group of bricks. We can add a brick to the group of bricks so long as it does not collide with a brick already in the group (so the group of bricks will ask every brick inside it where they are before adding a new brick). We can combine groups of bricks to form walls".
- Sidenote: Communications channels seem to be fundamental glue layers. Objects must be converted into serialised data on one side of the channel, taken from place to place by the channel and then converted from serialised data back into an object that can respond to queries and commands. Does this mean that all glue layers can be thought of as communications channels?
[permlink]