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. In fact after this post, I dwelled on what is a subject in the 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 criterion 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 the Smalltalk 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 is 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, subtype system? My feeling is, this world-view of everything is "subject" is not mandatory to achieve OO benefits. It is just Smalltalk'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).Thoughts on Unified view of data and program
NEM There are several senses to the word polymorphism. In one sense it means having the same code operate on values of different "types". One way to do this is to have a universal type (in Tcl's case the string, in Java it is java.lang.Object mostly) which everything fits into. Another way is to have operations be parameterised by types (parametric polymorphism) as supported by several typed functional programming languages such as Haskell or ML. For instance, one such operation might be to find the length of a list. To do this, we do not need to know the types of the elements of the list, but only that the list is indeed a list. In Tcl this is done like (assuming we had no llength command):
proc list_length list {
set length 0
foreach item $list { incr length }
return $length
}In Haskell this would be done as:list_length :: [a] -> Int list_length [] = 0 list_length (x:xs) = 1 + list_length xsThe first line above gives the type declaration, where [a] means a list of elements of any type, a. So, here we have polymorphism in that the same code can be called with several different types of arguments (lists of integers, lists of characters, or even lists of heterogenous types in the Tcl version). This is also the sort of polymorphism offered by generics in Java or templates in C++.A different sort of polymorphism is what is sometimes known as overloading or ad-hoc polymorphism. In this sort of polymorphism, each type can provide a separate implementation for the same operation. This is the sort of polymorphism that is usually referred to in OO programming. This is what $object method ... syntax supports quite well, as it allows the object to decide how to interpret the message depending on its type. For instance, in Snit you could do:
snit::type Person {
variable name
constructor n { set name $n }
method say msg { puts "$name says '$msg'" }
}
snit::type Dog {
variable name
constructor n { set name $n }
method say msg { puts "$name barks 'Woof! Woof!" }
}
Person neil "Neil"
Dog fido "Fido"
foreach object {neil fido} {
$object say "Hello, World!"
}Here the say method is overloaded for each type and acts differently depending on the type of the object it is called on.Both types of polymorphism are useful. Tcl supports the first fine on its own, and supports the second through the convention of having objects be commands which you pass messages to. In some OO systems, such as TOOT, you can also explicitly call a particular implementation, via an ensemble or some other means, thus I might be able to do:Person say $neil "Some message"What syntax you prefer is really quite a minor point compared with supporting the various semantic options for polymorphism.One final point, it is not a straight-forward claim that having a programming language be similar to a natural language decreases "cognitive load" on the person learning that language. Indeed, the whole move towards more formal languages (e.g. with notations for logic, maths, and now programming) has been motivated in part because natural languages are so ambiguous, thus increasing confusion when talking about very specific topics.
TJK Very interesting. I agree with NEM's last point but putting that to one side, I've always thought OO research wasn't broad enough in its investigation of how to improve the human computer interface. As an example a lot of the really interesting things that computers can do have to do with time yet no one has tried to draw the parallel between grammatical tense and action dispatching. For instance wouldn't it be great to have these concepts available programmatically: uncertainty, frequency, completion, duration, possibility, and even whether information derives from experience or hearsay.DKF: That last item tends to go by the name “provenance”[1]. I know people who work on this sort of thing.
[Alan] - 2009-07-19 14:08:52Interesting misinterpretation here: that between human commonsense and science. The former (and the semantics of many natural languages) were formed before modern science, and think e.g. of rocks as inert things to be acted by actors. Modern physics sees cause and effect as the result of objects receiving messages which they respond to -- everything is local. One way to look at this is that cave humans can get confused if they are able to kick a rock -- they might get the wrong idea and be surprised that they can't just kick a boulder and have it move (the boulder "doesn't want to"-- thinking of the cave person as a "causer" is a very naive view). Smalltalk was set up to have a simple uniform semantics that could be like science at all levels. Polymorphisms can help to limit the number of concepts that have to be contemplated. And so forth.Best wishes,Alan Kay
