Objective Thinking for Fun and Profit
By
Eric P. Nichols, Proprietor
AlasKit Educational and Scientific Resources
By
Eric P. Nichols, Proprietor
AlasKit Educational and Scientific Resources
Back in grammar school, I was really good at diagramming sentences. In fact, I think I was the only one I ever knew that actually liked doing this. The logical, rational approach to “thinking about thinking” that this skill involved seemed perfectly natural to me, far more so than the more right-brained exercises in creative writing that I had to endure later in high school English. From what I understand, they no longer teach sentence diagramming in elementary school…which, I suspect, is why they no longer call it grammar school, either.
It has been said that language is the currency of thought, an assertion that is difficult to deny. However, only recently have I fully appreciated the huge variations in the denominations of this thought currency. In fact, in many cases, there is no known “exchange rate.” Allow me to elucidate.
I got a rather late start in computer literacy. I was 41 by the time I used an actual computer, a baptism by fire as a “retooled” development engineer at HIPAS Observatory, an ionospheric research facility in Interior Alaska operated by the UCLA plasma physics department. My first task was to do some complex antenna modeling, using a program written in FORTRAN, which was already quite “mature” at the time, to say the least. I also learned how to write my own control software (that is programming that actually DID real physical tasks) using C language.
Both of these computer languages, as complex as the written code often appeared (especially for scientific applications), were very straightforward “procedural” languages. You told A to do B to something C. You may have had to tell A to do thing B to item C thousands of times, but the logic was always very…logical…as well as very grammatical. Writing complex computer programs with procedural computer languages is not much different from diagramming sentences. Each instruction had a subject, a verb, and an object. You have a “doer” doing something to a “doee”. Mathematically, these terms are, respectively, the “operator”, the “operation” and the “operand.”
We perform these operations all the time without even thinking about it, in our everyday speech. We may not like diagramming sentences, but we intuitively understand the concept of “parts of speech” each of which always serves the same function. A verb is always a verb, a noun is always a noun, and life is wonderful. Even if you speak and write Spanish, or French, or Italian, or Romanian, you use pretty much the same linear grammatical concepts. One gets the feeling that despite the small variations in grammatical “currency” around the world, we all pretty much think the same way.
And then you run into something like Mandarin Chinese. In Mandarin Chinese, there are no parts of speech. At least, not in the same sense that the Romance languages have. In Chinese, the “role” that a word plays in a sentence is determined entirely by its position in the sentence. A word is subject, an object, or a verb, entirely based on context.
In English, we do have a few rare polymorphisms in this regard, but they are the exceptions. The word “shop” in the sentence, We shop in a shop is one such polymorphism. It’s a verb and a noun. We punsters and other players-of-words enjoy these sorts of sentences because they’re unusual.
But in Chinese, every word is polymorphic. In fact, in most of the world, the uniquely Western concept of parts of speech is quite alien. Because it seems natural to us, we just assume that everyone thinks in this sort of linear mode. Frankly I would hate to try to diagram any Chinese sentence…or Thai sentence, for that matter.
The demarcation between matter and motion, one of the chief tenets of both “natural”
language and mathematics, is, as it turns out, a rather arbitrary distinction, as we shall see.
Nearly all modern computer languages, probably the most familiar of which are C++ and Java, are object oriented programming (OOP) languages. By object-oriented, we mean that every logical “part of speech” of the program is a polymorphic object. In other words, a small block of code can be an operator, an operation, or an operand, dependent entirely upon where it appears in the overall computer “sentence.”
It’s probably no “OOPS” that Chinese are so good at programming in OOP computer languages! On the other hand, learning how to program in Java was a major jolt to my “sentence diagramming” bent. But I’ve really learned to appreciate the flexibility of OOP languages, and in addition it’s caused me to reevaluate some of my preconceived notions of language itself! Let’s look at how object oriented programming works, using a very “folksy” example.
Let’s take a dog named Fido. Fido is a noun. He can be either a subject or an object, just as most other nouns. For the time being, however, let’s start him out as a subject. Fido has a bone. The bone is also a noun. Since the bone is an inanimate object (at least in its current state) it’s probably going to be an object, though this is not always necessarily true. An apple can fall out of a tree, in which case the apple is the subject.
Let’s add some verbiage….chews. We can now construct a conventional English statement, Fido chews bone. Our sentence has the clearly delineated “Western” functions of matter and motion, or matter and action. We can add some embellishments, of course, describing the bone by means of adjectives, such as large, slobbery, ancient, etc. But these adjectives don’t change the structure of the original statement, Fido chews bone.
In OOP programming, however, we have a much more integrated approach. A dog chewing a bone is such a natural association that there really is no need to separate the dog from the bone, or even what he’s doing to it. Let’s consolidated “Fido chews bone” into a single object, and give it a name: FidoObject.
We can even go a step further. We can move our bone-chewing dog, our “FidoObject” into a doghouse. Grammatically, we do this by means of an adverb…Fido chews bone in doghouse. We can “encapsulate” our FidoObject inside the doghouse. In turn, we can rename the entire entity DoghouseObject. If the doghouse is high quality, it really doesn’t matter what happens outside the doghouse from Fido’s point of view. He’s still merrily chewing away on his bone inside. He is still “FidoObject” regardless of what we do to the doghouse
Now from our point of view, we don’t know or care what Fido is doing inside “DoghouseObject.” There may be verbs, nouns, adjectives inside the DoghouseObject, but as far as we know “DoghouseObject” is a simple grammatical object. We can treat it as such. We can load DoghouseObject onto the bed of a pickup truck and drive it across town, thus creating a new logical statement, “Pickup drives DogObject.” DogObject has been “polymorphed” from a complete sentence to the mere object of another complete sentence.
Let’s “repackage” our pickup truck with the DoghouseObject on its bed as yet a newer object; PickupObject. Let us now drive “PickupObject” up a ramp onto a flatbed railroad car. Does Fido know this has happened? No, he is obliviously chewing his bone, totally unaware of the pickup truck or the railroad car! Likewise, the railroad engineer hasn’t a clue about what’s even inside the doghouse, and possibly the very existence of the doghouse itself.
We can now repackage our railroad car with the pickup truck with the doghouse, with Fido as a new object and call the entire entity RailroadObject. If we have enough resources, we can, furthermore, load our RailroadObject onto a freighter ship, and send it to Sri Lanka. We can create a new statement: Freighter ships RailroadObject to Sri Lanka.
As you might suspect, there are no theoretical limits to how many statements one can convert into objects, and then “operate” on them by a yet “larger” subject entity, similar to a set of Russian nesting dolls. This concept of progressively “encapsulating” data statements into objects is the core of all OOP programming.
Last edited: