What is an “object” in object-oriented programming?
It’s a clump of name->value mappings, some functions that take such clumps as their first arguments, and a dispatch function that decides which function the programmer meant to call. This reality is usefully obscured by the language so that programmers can, without thinking, do wonderful things, blissfully pretending that the pictures in their head are what the computer is really doing.
From Functional Programming for the Object-Oriented Programmer, in the appropriately named chapter “Objects as a Software-Mediated Consensual Hallucination.”
16 thoughts on “What is an object?”
I guess the foundings of OOP came out of Metaphysics: Ontologies and Reification. What does a PropertyBag class say about Substance Theory vs Bundle Theory – is there such thing as objects or are they just illusionary collections of properties ? As opposed to physical reality, in software an object can have no properties !!!
“… without thinking … blissfully pretending that the pictures in their head are what the computer is really doing”
I dislike this kind of condescending tone from functional language apologists. And I don’t get what the author thinks the computer is *really* doing? Shifting bits around ? I would argue that the “pure” functional equations in his head are much farther removed from “impure” reality.
OO has just-enough abstraction so that relatively new programmers can pick it up, and with some discipline, be productive in very large projects. Since the economics/enviroment of software development has largely remained the same (often inadequately concieved/scheduled/staffed), I see no signs of OO development going away anytime soon.
C. S. Lewis coined the phrase “nothing butter” for reductionist statements of the form X is nothing but Y. He also said that if you “see through” everything then you can’t see anything.
I don’t mean only to say objects are nothing but bits. Of course they’re ultimately nothing but bits, as far as the computer is concerned. But objects provide a useful abstraction that helps code fit more easily in human minds.
What I find interesting about the quote is that the author goes slightly below the object level abstraction, not all the way down to bits, and reminds us what it is made of. In context, he’s saying that objects are one way of helping humans think about code, but not the only way (contrary to popular belief). In particular, he’s advocating functional programming.
Donny: The author is not as partisan as I may have implied by picking out one provocative quote. He explores the advantages and disadvantages to object oriented and functional programming, and parts of the book are a synthesis of functional and OO approaches. He comments, for example, that although the book’s examples are written in Clojure, he more often has applied the techniques in Ruby projects.
I would say that I know an object when I see it.
Yes! OO AND Functional. Not OO OR Functional. Functional principles can go a long way toward increasing the expressivity and reducing the technical debt of all that imperative code in methods.
Donny: It’s not condescending. It’s admiring. Or: what John said.
The intro to chapter 13 is even worse.
Thanks a lot for the context, John :)! It is a really important point to make that OO is not the only way.
Brian: ha ha .. All the best for your book.
This sort of thing is enabled by the early OO advocates trying to remove all procedural language from their descriptions of OO. An ‘object’ just ‘knows’ what to do with things. Things happen ‘automatically’. And if you don’t get this, then you’re not thinking in ‘objects’ and you just don’t get it (implied: you ignorant procedural thinker, you).
The death of Ada, and conglomeration of C++ and Java, has lessened this a bit. Now describing what Objects are doing as collections of Object-and-verbs, or Object-and-messages, or even Objects-and-methods, is a bit more acceptable. Steve Yegge’s “rant” on “Execution in the Kingdom of Nouns” is still one of the best explanations about why treating EVERYTHING as an Object (making Verbs ‘second class citizens’) really doesn’t match reality, and is a weakness of OO designs.
AllanL5 I agree with you, it reminds me of the Alan Kay quote:
“I’m sorry that I long ago coined the term “objects” for this topic because it gets many people to focus on the lesser idea.”
The foundations of OOP actually came from biology. Alan Kay was thinking of biological systems, where self-contained cells pass biochemical signals to each other. In that sense, Erlang is probably the most OO language in existence.
As John indicated, the quote is correct, but too limited in scope. What it says is true of everything in computer science.
Think of operating system abstractions. Processes, threads, file systems, network communication… they are all software-mediated consensus hallucinations. The laws of optics or electromagnetism don’t know anything about connection-oriented streams, error detection, rate control or routing tables. Rather, computer networks are a social contract which states that we all agree to interpret physical signals in a certain way.
Computer science is fundamentally about layering abstraction. We build domain-specific abstractions on top of object. Objects are an abstraction on top of structures-and-pointers, which in turn are an abstraction on top of virtual memory, which is an abstraction on top of physical memory, which is an abstraction on top of logic, which is an abstraction on top of electronic components, which is an abstraction on top of quantum physics. And even that is probably an abstraction on top of something that we don’t know about yet.
You can’t be a good engineer without knowing something about the next layer down. I’ve had to rip out and replace whole data structures and algorithms because of that one instruction where 20% of the time is being spent. Common culprits include the modulo-a-prime instruction in naive implementations of hash tables, and that one unpredictable branch in the middle of binary search. Thankfully, I haven’t had to dig down to the transistor level to debug my software yet.
The second sentence of the quote illustrates beautifully how we use (or misuse) language to obscure the distinction between our minds and the world, on the one hand, and computing, on the other. I wonder if this is a crass example of what Wittgenstein meant by the bewitchment of our intellect by language?
@Dave Tate: perhaps you are right. I’ve had human language rather on my mind lately, so perhaps I misread the quote in line with my own thoughts.
Interesting; I interpreted the cited quotation to be saying something very different. I see now that this is because I interpreted “the language” in the phrase this reality is usefully obscured by the language to mean the subset of English we use to describe OOP — whereas everyone else seems to have correctly grokked that it refers to the OO programming language being used…
I’m still intrigued, though, by the idea that the metaphors we use to describe what OOP is doing both lie about what’s really happening and enable “wonderful things”…
“Language” was meant to be “programming language”.
Dave: one thing I’ve learned from doing a lot of writing and presenting — and programming — is that lies are good when they smooth the path of learning or acting. Many people hate that claim.
(Though, really, the word “language” can also be usefully interpreted as “natural language”.)
I’m probably more influenced by “the new theory of metaphor” (Lakoff and Miller) than by Wittgenstein (whose work I barely know).