8 perceptual metaphors for OOP objects

Why Learning F# Is So Difficult at got net? (I compliment the blog's subtitle "Kevin Hazzard's Brain Spigot") has an insightful explanation for why functional programming code is so confusing at first: usually, programmers don't have the necessary perceptual primitives, the prototypes, that would enable rapid recognition/comprehension of the code. They're expecting mutable variables, not immutable lists. They're expecting "foreach", not "map". They're not expecting statements, expressions, and functions to be somewhat synonymous. They're not expecting functions to be inputs or outputs of functions, nor are they expecting partial function evaluation. They're not expecting recursion to play a large role, perhaps because they assume it will blow the stack (which is a good opportunity to explain tail-recursion optimization). And, naturally, they're not expecting the operators to look and act so differently.

That said, the need to learn new perceptual prototypes as part of adjusting to a different programming paradigm applies to OOP, too. My experience of switching to OOP had its own moments of bewilderment, such as "Huh? Invoking a subroutine on this data type runs code two levels up in an 'inheritance hierarchy'?". I know of no less than 8 ways or metaphors for perceiving the most fundamental concept of OOP, objects:

• Supervariables. The supervariable metaphor is most applicable to small classes that don't do much more than provide a handful of convenience methods for representing and modifying abstract data types. "Supervariable" emphasizes that an object not only stores a small conglomeration of data but also provides prefabricated code for common tasks on that data. An alternative name for this metaphor is "smart variable". A ComplexNumber object that has a produceConjugate method fits the supervariable metaphor.
  
• Miniature programs. The miniature program metaphor is most applicable to classes that, like a control panel, expose intricate, full-featured capabilities. "Engine" in the class name could be a clue. (In practice, objects that are closest to "miniature programs" probably employ I/O and various other objects internally.) The point is that creating an object and running one or more of its methods can be similar to starting a program and directing it to carry out actions. Of course, the metaphor is explicit when a program specifically furnishes an "API object" interface in addition to GUI or command-line.
  
• Nouns. The noun metaphor is the most straightforward and the most taught. The object represents a noun and simply consists of the noun's attributes and activities. It's a Car, a Square, a Dog (that inherits from Vehicle, Shape, Animal, respectively). It's an abstract simulation of its real counterpart in the problem domain. Since in nontrivial problems 1) the problem domain overflows with too many irrelevant nouns and 2) not all necessary parts of a program have real-world analogues in the problem domain, the noun metaphor isn't seamless nor self-sufficient. It's a good starting point for analysis and design, however.
  
• Memo senders. One of the tricky mental shifts for OOP beginners is decentralization of control flow, especially when it's event-driven. Each object has its own limited, distinct responsibility and role, so the way to accomplish a larger purpose is collaboration and communication among objects. No object is inherently primary, though execution must start at one particular method. In OOP, the metaphor of object interaction isn't a top administrator dictating orders or stage actors enacting a script; it's a cooperative group of employees who send memos to one another in order to complete individual assignments. And "employees" shouldn't need to "send memos" to every other employee in the "building" - see Law of Demeter.
  
• Lieutenants. From the standpoint of the memo-sending metaphor, the "lieutenant" metaphor is about the contents of the "memos". A lieutenant (or vice-president) isn't told exactly what to do (the "how") but the goal to be met (the "what"). The value of the lieutenant is in delegation. Objects shouldn't need to know much about other objects' work, as long as the objects do their "jobs". There's a good reason for this advice: the more an object knows and therefore assumes about other objects, the harder it is to modify and/or reuse each object independently. Effective error handling often requires a delicate compromise of an object knowing just enough about possible errors to respond the way it should - no more, no less (should the object abort, retry, ignore, fail?).
  
• Instantiable scopes. Unlike the noun metaphor, the "instantiable scopes" metaphor is not likely to be included in introductory texts. It's one of the more obvious metaphors to seasoned programmers but one of the least obvious to novices. This is a rather literal and stark "metaphor", which is why it's of more interest to compiler and interpreter writers than to analysts. An object is a "bundle" of functions and variables whose implementation involves "this" (or "self") pointers and vtables. Sometimes, people involuntarily learn this metaphor when a serious problem occurs. Developers who are trying to add tricksy feature extensions to a language may need to think of objects in this way.
  
• Data guards. Substitute "bouncers" for "guards" if desired. In this metaphor, objects are protective intermediaries between code and data. The object somehow mitigates the downsides of direct data access: checking that indexes are in-bounds, tying the disposal of acquired resources to garbage collection, etc. Like the lieutenant metaphor, a data guard object can separate an accessing object from dangerous knowledge, because the accessing object knows only as much about the data as the guard allows. This means, for instance, that the guard could change to obtain the data from a different source, or the accessing object could be reused in several different contexts at once as long as its data guard functions consistently. The obvious downside is that superfluous guards and multiple layers of guards complicate and slow the program.
  
• Sets of behaviors. This is the most abstract metaphor of all. Many OO design patterns use it. According to this metaphor, objects represent actions instead of, well, objects. The object's focus is the execution of a specific algorithm, and not the expression of data. Therefore, the typical name of a behavioral object refers to the role it serves in the program: bridge, adapter, factory, iterator, strategy. Viewed through this metaphor, the important difference between all objects is behavior. Objects that have the same behavior shouldn't require multiple classes. The behavior of subclasses shouldn't violate the behavior expectations of the superclass. An object is what an object does.
  

something worse than missing sarcasm online...

...is assuming the online statement is sarcastic when it's actually sincere.

"My mistake. I figured that he or she couldn't possibly be so ignorant|silly|dumb|unoriginal|hateful|presumptuous|arrogant."

It also has happened when I try to adjust to common interpersonal communication after passing time reading forums. People think I'm acting arch just because I look at them quizzically after they say something that's flatly ridiculous and I'm genuinely unsure whether to take them seriously.

Tale of the Self-virtualizing Robot

Imagine a smart robot that can interact with its environment in complicated ways akin to a human. This robot is so smart that its mental model of the world is at a similar level of sophistication. Its senses, goals, and calculations all are different from a human's, but nevertheless it's more than capable of devising plans of action or correcting itself based on past mistakes, for instance. It also can theorize about the future.

Moreover, the clever robot can employ these abilities to perform a great trick: it can project its own thoughts and actions. That is to say, it has a perfectly accurate internal concept of its operation that it can apply to hypothetical data to determine what it will think and do. After successfully doing this once, it recognizes the value of incorporating self-prediction into its long-term considerations. It proceeds to run the self-prediction task more and more frequently, as data comes in. It's executing its program as part of its program. In effect, it's self-virtualizing.

But now the story takes another twist. Sooner or later, the self-virtualizing robot discovers that the computed action its "virtualized self" will take is suboptimal, or that the computed answer its virtualized self will produce is incomplete. It duly notes and accounts for this new information, thereby shifting its current and future thoughts and actions accordingly, as surely as the sum of 4 and 6 differs from the sum of 8 and 3 . Yet doesn't this mean that the robot perfectly predicted itself wrongly? Is this possible? Through bypassing and modifying its programming to decide differently, does this robot have as much freedom to choose as any human?

I think so. I'm convinced that the phenomenon that we experience as "choice" isn't a peculiar loophole in causality but instead a complex interplay of factors such as emotion (drives), reason, and creativity. The complexity is the first reason people assume it to be causeless, i.e. free. Second, the factors change within each person, sometimes gradually, sometimes abruptly (e.g. "the last straw" or psychoactive substances). Third, awareness of one or more factors can function as a factor--feelings about feelings, perceptions about perceptions. Fourth, people can ponder ideals, in a fact-value distinction. Fifth, they want to believe that they are in control. Sixth, they want to believe that their motives have superior subtlety.

If the self-virtualizing robot sufficiently mastered language to claim it could act independently of its programming, how would anyone convince it otherwise?

questions about Truth in endlessly astounding reality

Truth was defined in the previous entry as nothing more than the measure of correspondence between specific ideas and reality. This (singularly unoriginal) stance provokes follow-up questions, whose answers serve to clarify what I meant. I wish I could properly categorize my concept of Truth, but I don't have sufficient technical knowledge and/or scholarship; pragmatism's seems similar.

• Q: For someone to accept this definition of Truth, isn't he or she forced to assume the truth of the definition itself? A: Yes, but all definitions of Truth have the same "shortcoming". All definitions of Truth are statements, thoughts, etc., whose truth cannot be accepted except on "their own terms". Truth definitions can't be logically derived. However, one can assume the truth of the Truth definition and then apply it to itself. In my encounters with reality, to define Truth as the measure of accordance with reality is to define Truth in a way that has a high measure of accordance with reality, i.e. this definition of Truth hasn't been misleading. Hypothetically defining Truth as what Simon Says would fall apart as soon as Simon said something impossible, such as a self-contradiction (bad Simon!).
• Q: What about the truth of "32 - 15 = 17"? A: That exact statement is neither true nor false. It doesn't correspond to reality--it's about "mental realities", symbols, generalizations. A remarkably similar statement like "separating 15 pennies on this table from the original grouping of 32 pennies will result in a grouping of 17 remaining pennies" is either true or false, but my reason suggests it is true. The utility of math, or any other formalized system of reasoning, is thanks to a human discovery: the assumption of an exceedingly small set of true statements and (formal) rules for truthfully combining statements enables an explosion of creative proofs of other true statements, "theorems". As long as the formalized reasoning system's symbols and rules indeed correspond to reality, the theorems produced should, too. The ideas known as quantities happen to correspond so easily, so well, so unambiguously, and so consistently to reality that we forget their existence is purely mental.
• Q: Can't a proposition be true, and therefore part of the Truth, regardless of whether anyone is convinced it is true? A: Nope. If truth is the measure of correspondence to reality, that measurement (or judgment, etc.) must be executed and evaluated by someone who comprehends both reality and the proposition! No individual truth is "substantial", since it's a characteristic of the relationship between an idea and reality. Reality is "substantial". Reality is. In other words, reality doesn't "depend" on propositions. Reality's "realness" isn't contingent on the thoughts of humans. Truth is the extent by which people's thoughts succeed at agreeing with reality, not the extent by which reality succeeds at agreeing with people's thoughts.
  
• Q: Given that Truth is this flimsy, and the people like us who judge it are known to make so many mistakes, how can any belief have "solid" truth? A: Quite right. This question has no easy answer, but that's expected in the face of endlessly astounding reality. The fact is, both the observation of reality and the accompanying checking of truths proceed using a plethora of methods and degrees of reliability. (A few are in wikipedia is not an epistemology silver bullet, the 12th blog entry.) As a result, some truths are more "solid" than others. The criteria to rank them is a procedural matter, not a philosophical or foundational one. Just as children learn to be skeptical after playful adults tell them lies for amusement, people continue gaining (heuristic) expertise at weighing truth. Even those who say they rely predominantly on reason to obtain truths aren't immune to making mental mistakes or starting from the wrong premises.
• Q: To define truth's domain as the combination of thoughts and reality, doesn't that presume thoughts must be distinct from reality, i.e. thoughts are unreal? A: The terse answer is that, yes, thoughts are unreal, regardless of how true. The more elaborate answer is that although thoughts are unreal, thoughts that more closely correspond to reality (more truthful) are more "real", figuratively speaking. Note that thoughts that are at least somewhat true can still be useful, through analogy. True thoughts can act as close "simulations" of reality. In the most extreme case, thoughts that prove to be very true are what people designate as reality.
  
• Q: Hey, wait a minute, now you're double-talking--if people's experiences of reality are thoughts themselves, how can people ever really determine the truth of all their thoughts versus "reality"? A: This is a variant of the age-old question "How can I know for sure that all of my experiences aren't illusory?". The absolute answer is "You can't". The practical answer is "Thoughts you can't ignore, thoughts that are most consistent, are the most true, i.e. the closest to being real and the most deserving of the convenient label 'reality', if only temporarily". Essentially, thoughts are the unreliable messengers of reality, and all people can do is compare the messages, assign degrees of truth, and in so doing compute a semblance of reality that's meaningful and usable. Think of it this way: if one thought is of a winged horse while a much more vivid second thought is of a computer screen, the second thought is likelier to be more true and "real". If turning one's head causes the thought of the computer screen to shift position, then the thought is considered still more true--among thoughts, direct sense perceptions are usually treated as true representatives of reality. But not all sense perceptions are true, and even the least ambiguous require significant interpretation...which reemphasizes the point that the heuristics of judging truth can't be simple and free of exceptions, due once again to reality being endlessly astounding.
  
• Q: By defining truth as secondary to reality but refusing to unequivocally define reality, in what way does this scheme clarify what Truth is? A: Er...huh. The thinly-veiled motivation behind this standpoint isn't primarily to pronounce Truth's composition, but to promote reality through demotion of other philosophical items such as Truth. Reality is real; to be true (and figuratively "real") everything else must be based on reality. That which bears no relation to reality shouldn't be thought of as true--perhaps beautiful, good, even "correct" according to some standard, but not true. And reality itself needs no underpinnings.
  

defining Truth in endlessly astounding reality

The most incomprehensible thing about the universe is that it is comprehensible. -Albert Einstein

I'll start with the reminder that philosophy is neither my vocation, hobby (avocation), or education. But my college degree did include snazzy liberal arts classes. (The only course I disdained was art, in which I received low grades for my art criticism. My excuse could be either the indeterminate basis for evaluation, the capricious professor, or the unmitigated subjectivity of the "correct" answer. Yeah, I'm bitter.)

My definition of philosophical Truth is straightforward if ridiculously unoriginal: Truth does not exist. In more precise language, truth isn't transcendental. It's a common noun, not a proper noun (notice the capitalization difference?). It's never found alone because it's the measure of the correspondence between specific thoughts and reality. Where there's no thought, there's no truth. Where there's no reality, there's no truth.

This definition of Truth has the advantage of matching the way that all people learn what truth is. Truth is not lying. A lie is detected by comparing the statement to ascertained reality. Even the fictional truth of a fictional statement uttered by a fictional character can't be judged without reference to the fictional world it's from. A statement that cannot be disproved is neither lie nor truth. When people have wondered out loud to me whether reality is "really" the Dream of an unknown Dreamer, my reply has amounted to "So what?"

Another reply I could make to the same conjecture is "For being a Dream, reality is much more ordered than what I experienced when I was sleeping last night". And this reply also expresses something about the discovered nature of (common, not transcendental) truth. Reality is experienced as orderly. It's also unfathomably complicated from moment to moment, but orderly nonetheless. In fact, as creatures who have developed to productively interact with our environment, we're "hard-wired" to quickly generalize and then apply patterns, a strategy that would fail if reality had none. Thus, we repeatedly confirm the applicability of patterns to reality so often that it's strange to mention it. Since the patterns correspond to reality, by definition the patterns have truth. Moreover the pattern-making process must have truth for it to produce so many truthful patterns. But what is the usual philosophical term for the patterns and the pattern-making process? Reason. Reason has truth because it produces thoughts that correspond to reality, but reason couldn't produce those true thoughts from other true thoughts unless it operated in a way that corresponded to reality. For instance, predicting an object's future location based on its current trajectory works because objects don't change trajectory without cause. Reason works because it has truth. When reason stops working it's no longer (perfectly) corresponding to reality, and by the definition no longer has (the same amount of) truth.

However, since transcendent truth is nonexistent, transcendently-truthful reason is nonexistent, too. Similar to truth, reason is a lower-cased common noun. Put simply, reason doesn't always yield truth. Reality doesn't guarantee a confirmation of reason, seeing as how it doesn't guarantee a confirmation of any proposition or statement or thought. Reality overwhelms the capability of every example of reason sooner or later. Reality is not perfectly predictable. It's not computable in its totality, not even by an impossible all-knowing demon. Reality is endlessly astounding.

Nevertheless, I'll attempt to reason out anticipated questions in a second part.