Objective Thinking for Fun and Profit
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.
Now, there are some subtleties about this whole “objectivizing” business. A big part of the art is knowing just how much information we allow different objects to “know” about each other. For instance, if the PickupObject is an open-bed truck, the RailroadObject engineer might see the DoghouseObject. And he might even be able to “guess” that there’s a FidoObject enclosed within. Depending our final intent, this could be a desirable or undesirable property. Knowing how to control the information flow between objects is what separates the true code poets from the “script kiddies.” It’s an extremely difficult, but very rewarding science. And despite my “linear” upbringing and late entry into computer programming, I’m far better at doing this than I ever thought I’d be, though I still have a long way to go. I’m probably not in the category of a “code poet laureate” yet, but perhaps qualify as a “code lyricist.”
Let’s return to the linguistic aspects of this for a moment. We may look at Chinese and ask, “How can a language with nearly 4,000 fundamental characters not even have parts of speech?!” (It takes about 1200 characters just to clear one’s throat in Mandarin…not too much of an exaggeration!)
It’s a matter of linguistic priorities. Chinese may seem like a very inefficient language, not to mention imprecise at best and ambiguous at worst. In “our” linear thinking, linguistic priority means clearly defining our parts of speech.
In Chinese, words (characters) are not “sorted” according to parts of speech but rather according to “functional” groupings. For example, Chinese characters that have any connection with emotion have a “heart radical” (pictogram) associated with them. There is a huge “library” of “heart radical” words, both those we would consider nouns and those we would deem as verbs. The heart pictogram is immediately recognizable in Chinese script…even for a Westerner who’s never attempted to read Chinese before! Likewise, there is a “water” radical which has anything to do with law or teaching. Again, another pictogram that any westerner can recognize with a few seconds of training. There is another huge “library” of “water radicals.”
Again, these Chinese “radical” groupings have no connection with our concepts of parts of speech. To paint or to weld are both verbs, but what “functional” connection do they really have? Wouldn’t grouping “To Paint”, “Paint brush” and “Turpentine” be a much more logical grouping than “to weld” or “to paint” simply because they are both verbs. Likewise, why not group “to weld” “welding rod” and “torch” together? This is the object oriented (and Chinese!) way of doing things.
In object oriented programming, objects are always defined by what they are and what they can do. Fido is a pretty pointless dog if he is not allowed to chew a bone. Not many people would want a dog that’s incapable of chewing a bone. The bone-chewing function is integral to the dog’s function. Most people would prefer to own a FidoObject than a functionless Fido, truth be told.
From a practical standpoint for the programmer, this has tremendous advantages. It allows the reuse of countless useful objects that other programmers have written. As much as some of us programmers would like to thinks, there are very few “primitive” functions we can write that someone else hasn’t written before. Just like Chinese radicals, we have huge libraries of prefabricated objects, “logical nouns” and their associated functions that we can “plug into” our programs.
When I was writing procedural programming for the UCLA plasma lab, very little if any of what I wrote was of any conceivable application outside the walls of our lab…or even to the guy at the bench across the room! While there is still a great need for such application specific programming, (some of which is becoming a lost art in itself, hence the recent surge of new interest in programs like FORTRAN), general purpose programming lends itself much more readily to OOP concepts.
First of all, modern computer programs are HUGE. It would take hundreds of lifetimes to write most common present day programs from scratch. The first Windows operating itself (not including any functional programming) took around 200 MAN YEARS of labor to put together. There were no objects to “plug in.”
Fortunately, most of the biggest programs imaginable today are largely made of reused code, using many many encapsulations of previously created objects as described above.
We humans perform this information encapsulation all the time without even thinking about it. Human language is extremely compressed. The objects of English language, namely words are encapsulations of yet other objects. For example, what if you had to define the word “a” or “an” every time you used it in a sentence! The word “a” encapsulates a huge amount of information. If we were to even try to define “a” without actually using it in the definition…we would be doing very well!
How about more complex “objects”? What if we had to define house every time we used it in a sentence? The definition of the word house has nearly innumerable encapsulations within its very definition! Just look up the word in an unabridged dictionary and then look up every word in the definition in the same dictionary! You’ll probably never get to the bottom of the “matrix”…at least not without running into a circular definition at some point!
“Fiddling around” with OOP programming causes one to “think about how one thinks”…normally a pretty involuntary process. It’s a tough job, but it’s a lot of fun too.
Causes Eric Nichols Supports
Free Burma Rangers, Partners Ministries (Thailand), Literacy council of Alaska, Access Alaska.