Version 14 of Thoughts on OO, Natural language, human thinking

Updated 2006-02-19 06:34:23

By vkvalli.

Why we need to understand Natural language? Natural languages evolved. The ability to express something is in a language has high correlation with brain structure. Natural language studies revealed that nearly all languages have a similar structure/grammar, but superficial differences. This I remember was based on some Chomsky's findings, but don't have reference off-hand. The evolution of natural language was based on the cognitive limits of human mind.

This insight may help in the design of programming language so that the man-machine interaction does not cause too much cognitive load and the resulting stress.

Most of the interaction of man-computer would fall under imperative statement type. Typically computer languages are classified as imperative and declarative. XML is more of a declarative language. The general thought is imperative languages are like procedural languages and object-oriented languages are different.

In imperative statements, there are three entities involved. Subject, Object, predicate. "John! close the door," is an example of an imperative statement. Here "John" is the subject. "door" is the object. "close" is the predicate.

More simply, the subject acts on the object, the predicate denotes the action. Most of the time, the state of the object gets changed as a result of the action. One could see an analogy here. The new Security-enhanced linux gives more fine-grained access control in linux. There, when writing authorisation rules, we talk of 3 entities, subject, object, action. A joe user opens a file for reading. "joe user" is subject , file is object, reading is action.

Most of the times, when we are programming, the subject is the computer. We ask the computer to do xyz things. So instead of saying "computer open this file", "computer close this file", we simply say "open this file", "close this file" etc.

Th order in which subject, object, predicate appear varies in different natural languages. In English, it is "subject, predicate, object". For example, in the Asian language Tamil, it is "subject, object, predicate". But what is important is a language consistently adopts one style.

Now let us see how object orientation comes in natural language. It is instinctive to see that predicates are like verbs, and the equivalent in programming languages is a "command" or "procedure". But there is a slight difference. A "procedure" maps to unique sequence of sub-actions/actions. But natural language verbs need not. To understand this, let us take the statements, "open the door", "open the letter", "open the computer". Let us say, we are instructing a robot to do this. Then the robot needs to know the sequence of actions for "open". But the sequence of actions for "open the door", "open the letter", "open the computer" are very different. For clarity, we can consider two kinds of verbs, specific verbs and generic verbs. Specific verbs map to unique sequence of actions, but generic verbs do not. In this case, let us have these additional verbs, "open_door", "open_letter", "open_computer", which maps to unique sequence for door, letter, computer. Now it is clear that open is kind of generic verb. Now, the robot to accomplish the task, will map the generic verb to specific verb based on the type of object on which it has to act.

Now a new entity is introduced, object-type. This is what is happening implicitly in our mind, when we speak. We use generic verbs. The subject to carry out his action, determines the object,object-type and maps the generic-verb to the right sequence of action(or specific-verb).

Therefore many new products keeps flooding the world but the verbs in the language do not explode. An imperative language like Tcl natively supports specific verbs with procedures (they map to unique set of sub-actions). If they support generic verbs/commands, then we accomplish the same effect as object-oriented paradigm. To do this, the language needs to support object-types, and a way to determine the object of a command.

To accomplish this see OO libraries

Now most OO languages seems to have gotten it wrong. They all try to simulate Smalltalk, which views things differently. Instead of subject acting on object like natural languages. In Smalltalk, one passes messages to objects and it acts on them. "door open" - one requests the door to open. Basically objects receives commands and act on them and change their state accordingly. I believe the Smalltalk way of viewing is inconsistent with our natural viewing. In Smalltalk, there is no subject. (Or may be you are the subject.)

I feel there is no need for Tcl to emulate Smalltalk notion of objects. Tcl could emulate natural language way of viewing objects, "open door", "open computer" etc. By doing this Tcl can consistently maintain the "predicate-object" sequence rather than "predicate-object" for non-OO and "object-predicate" for OO.


Lars H: An interesting argument, but I don't agree with the conclusion (that the language needs to support types), and indeed the argument is based on an incorrect premise. Nonetheless, it is interesting.

The error you make is that you implicitly assume that the objects of natural language grammars are equivalent to the objects of object-oriented programming, but OO-objects are in fact more like the subjects of natural languages. (In order to keep them apart, I'll write G-objects for the grammatical kind and CS-objects for the computer science kind.) The key difference is that of encapsulation -- CS-objects are supposed to hide their internals from outsiders, whereas the subject acting on a G-object needs both access to and understanding of this G-object. Since the only entity (in a pure object system) that is allowed access to the internals of a CS-object is that CS-object itself, that CS-object will grammatically be the subject that performs the action.

The examples "John, open the door!" and "John, open the letter!" can be taken as an example of this. For John to perform these actions, he both needs to understand doors and letters respectively -- how to turn the doorknob or rip open the letter -- and have access to the object in question. While perfectly sensible, this is not the OO way. An OOified letter would instead have an "open" button, which when pressed would cause the letter to open itself. (Similarly an OOified door would have a "open" button, so that its users neither needs access nor insight into such complicated machinery as locks, doorknobs, and hinges.) As it is the CS-object that is executing the predicate of the sentence, it is grammatically the subject, not the object.

From a grammatical point of view, the idea of OO can actually be seen as making programming more subjective, by introducing entities (the CS-objects) that can serve as subjects. Instead of having the programmer instruct "the computer" what to do, the programmer is instructing windows, documents, devices, etc. to do stuff, and by doing stuff they grammatically become subjects. Hence the usual "object method argument" order of OO programming is exactly the same as the English "subject predicate object"; the only difference is in the terminology.


vkvalli Thanks for giving this clarification. Infact after this post, I dwelled on what is a subject in smalltalk world. I more or less came to the same conclusion.

Here are some more thoughts on this. The following is with reference to Natural languages/real world. There are "things" in the world. Few "things" can take the role of "subjects" and most "things" take the role of "objects". The criteria is - Those "things" which are capable of inflicting state-changes on themselves and others, can be "subjects". Other "things" are "objects". Therefore we can communicate with only "subject"-able things.

In real-world, human-beings, robots, computers are "subject"-able things. Therefore they can be subjects in imperative statements. In computer-world, in a simple view, computer, a running program, process can be "subjects" and rest are objects. Hence in SE-linux, they categorize users, processes as subjects, for authorization framework. (I am not sure, whether in computer world, a hard-boundary can be placed on what can be "subject"-able things)

Now, in small-talk world-view, everything is a subject. It looks every object like a tiny computer or process. I remember Alan kay phrasing something like this on his introductory paper on smalltalk system. This world-view is different from real world-view and the world-view of imperative language. They say OO as a different paradigm because of this difference in world-view. Now the issue is - whether this world-view is required to achieve OO benefits like data-encapsulation,type,sub-type system . -? My feeling is, this world-view of everything is "subject" is not mandatory to achieve OO benefits. It is just small-talk's world-view.

By having a world-view of not everthing is a subject but by supporting typed-objects, an imperative language can achieve OO benefits without a paradigm shift. For that imperative languages, needs to support generic or polymorhic commands.(I am not very sure, polymorphic is the right-term).

[ Category Object Orientation ]