When I recently criticized Processing’s lack of object orientation I seemed to have hit a sore spot. The majority of the responses have emotionally defended the current syntax as sufficient and most suitable for beginners. At the same time they dismissed my insistance on OO principles as strictly unnecessary and considered these proposed methods as mere “niceties” which can easily be lived without. I think that’s missing my point completely!
Object orientation is not to be mixed up with “nice” looking, cleanly formatted or easy-to-read source code. Even though all those things are more than often features of software developed that way, practicising an object oriented approach has far more fundamental differences, techically as well as conceptually. What I consider to be those differences is explained in more detail below.
Another related and still consistently misunderstood point of my critique was that I claimed Java to be more expressive than Processing. Expressiveness is not just the result of a statement, but also how it is communicated. I was purely arguing Java’s language constructs to be better suited to express complex abstract concepts by means of OOP. Of course Processing wins hands down when it comes to quickly producing sketchy prototypes, yet I wished Processing syntax would not so much focus on this “instant gratification” part. As teaching tool it should be able to grow with the user and “gently”, yet consistently introduce core concepts from the beginning, since often it’s easier to learn something than to unlearn it.
A programme is a step-by-step description of a process. However I am arguing we should not separate the act of encoding the step-by-step instructions from the actual act of decomposing the structure of the process in question. OO is not primarily concerned with syntax. It is all about reaching an optimal design solution as result of decomposition and abstraction of an idea. It itself is an iterative process and a more than useful “tool” to engage with bigger and more complex ideas in order to encode them as software. Aiming for literacy in this field will have (and has had for most) direct impact on the conceptual quality and complexity of work produced. If this is not the aim of teaching people programming then I don’t know what is. I sincerely wished Processing would have embraced this further and I still can’t see any why it shouldn’t be possible to marry an easy-to-use syntax with those more conceptual aspects of structure and means of expression.
So I still don’t really buy the arguments presented so far that OO thinking is too hard to grok for novices without any background in computing. Object thinking is all based on a certain perception and assumptions of the world. It does require certain skills to abstract and translate observations, but these are skills needed as much in other disciplines like design or philosophy (or art) and so have not much to do with requiring a Maths degree as prerequisite.
The world around us
A helpful, yet pretty simplistic view for the sake of argument below could be: We all live in the same world and to some extend share and agree on some aspects of this reality. One of them is that this reality is filled with a multitude of “objects”: Your notebook, pen, mobile, toothbrush, dog, boy/girlfriend, iPod, power plugs… In the same way we can consider more abstract things as objects too: the Internet, an mp3 file, ski trip, club night, video game, story, softness, theatre play… All those objects, physical or not, have something in common: each one of them can also just be considered as “idea” or “concept” and as such they all can be mentally isolated and treated on their own and yet they are somehow related to each other and anchored into reality (well, that’s the common assumption at least). The question’s is, what is it which ties each of these objects into reality.
We humans use our various languages to refer to and communicate ideas (concepts) with each other. To simplify that process of communication we slowly (over millennia) have developed symbols for frequently used concepts. Those symbols are called “words” and we’ve been conditioned to associate each one of them with a more or less stable meaning/concept since the day we were born (Behaviorist theory). But remember each of our words only is a way to refer to an idea or concept. Each concept itself “exists” on its own, regardless if there’s a word for it. Words form the basis for only that part of our description of the world which we all agree on, with an infinity of ideas (and their corresponding symbols) outside of it. By means of our own aquired private symbol collections and thought processes we mentally can construct any number of new ideas or concepts (with the restriction we can’t think of anything using symbols unknown [to us]).
In order to avoid ambiguity or to communicate concepts (incl.entirely new ones) to others, we have to use a set of known established symbols (words) and put them into the “right” sequence (syntax) to communicate and explain the new concept each other (I’ve put “right” in quotes here since in theory we’ve got quite a choice of languages to express ourselves in). That necessary expansion of symbols to statements means our languages are self referential. We make use of this feature to create semantic layers: Once a new idea is becoming popular enough a new symbol will be introduced by someone familiar with the concept to refer to it more directly. A side effect of the sheer existence of this new symbol/phrase is that it now hides level of detail of the original (longer) idea to its new users. (AJAX as a recent example). In many modes of conversation this is desired and sufficient. The new symbol provides a higher level of abstraction of the idea and at the same time encapsulates its deeper knowledge.
As general principle it can be said that in order to (re)gain this “hidden” knowledge we’ll have to inspect and engage with the underlying ideas, which again means nothing more than undergoing a potentially recursive learning process to recover the full extend of the bigger idea - or in Newspeak reverse engineering. This is true for your own ideas as much as for external ones. As a sidetrack: This also is a strong argument for Open Source when considering code as extension to language.
Object anatomy
By all means I’m not proposing this to be a correct theory of language, but taking this simplified theory as starting point we can see object orientation as idea is not as alien to most of us as it may seem. If we treat objects as ideas we can come to the following conclusions:
- objects can be analyzed in isolation and are based on a number of properties (sub ideas) which are “hidden” by default. This is called encapsulation.
- objects are nested (a novel is a specialized idea of a story). This is called inheritance.
- nesting causes objects to have manifold appearances based on current context (my wife is my friend but also is a female, a mother, daughter, is human etc.) This is called polymorphism.
- some objects (remember: as ideas) are used as prototypes/interface: for example “female” is a specialization of gender, which ultimately can be reduced to the idea of “binary” or opposition. Those special types of objects are also called interfaces and are employed on many levels across languages/cultures/contexts: ying-yang, on-off, black&white, male-female, plugs and sockets (to reference an example from the initial list of objects above) etc.
Okay, some of those might be a bit contrived, but I hope you get my point…
Since this is no tutorial about OOP I won’t go into much technical detail here, but for some reason more than often discussion about OOP quickly locks in on the topic of inheritance. It’s true it’s one of the pillars of OOP yet IMHO a more suitable way of introducing object thinking to newcomers is by focussing on encapsulation, polymorphism and the interface metaphor since their basics can all be explained without deep understanding of the inner workings of inheritance.
To be continued…
