Slashdot Mirror
Anthropomorphism and Object Oriented Programming
An anonymous reader writes: We've all been warned about how anthropomorphizing animals and machines can lead us astray. But Edsger Dijkstra once cautioned (PDF) developers against thinking of their programs that way as well. "I think anthropomorphism is worst of all. I have now seen programs 'trying to do things,' 'wanting to do things,' 'believing things to be true,' 'knowing things' etc. Don't be so naive as to believe that this use of language is harmless. It invites the programmer to identify himself with the execution of the program and almost forces upon him the use of operational semantics." A new article fleshes out Dijkstra's statement, providing a good example of where an anthropomorphized analogy for Object Oriented Programming breaks down when you push it too far.
Dijkstra spends time building an analogy, then explains how it's flawed, and uses that to argue against 'anthropomorphizing'.
That's nice, and I certainly agree that the analogy can only go so far, but he was the one to build that analogy in the first place. This is not a valid argument against anthropomorphizing at all.
I do agree with the conclusion that anthropomorphising is not a reason to call OOP better than procedural.
---
"I don't know how many of you have ever met Dijkstra, but you probably know that arrogance in computer science is measured in nano-Dijkstras"
Object oriented programming, the "crystal healing therapy" of computer science.
EOF
I used to have a procedural toaster which cooked the bread until it became toast. Then I upgraded to a much more elegant OO toaster, which simply sends a "toast yourself" message to the bread. Unfortunately, bagels don't have a self.toast() method, so i still have to have a backup procedural toaster to handle the older API.
Ya, sure. It is so much better to use the phrase: "The program contains a variable that stores your name", instead of: "The program knows your name". English, ect. all was not designed to work that way. Unless you want to take a week to describe a single program, it really helps to anthropomorphise it.
Troll is not a replacement for I disagree.
My code wants to be antropomorhized!
For me, I prefer OO programming (c++/java) to functional programming (C-lang), just due to encapsulation. I like having an object, with methods for its attributes, public/private methods, and such. Then having the objects interact in my program. It kinda makes sense to how I think.
However, I also think that if a team or individual programmer can release software that serves a useful purpose, and is maintainable, then those are the only things that matter. Which language, functional or object-oriented 'way' that was used to get there? Seems less important.
Uh, Linux geek since 1999.
...they hate that.
OO isn't about anthropomorphism, it's about isolation and providing a clear API. If this was a large scale project with fifty people working on code that could move students, I don't want them implementing fifty different versions of move_student that will break whenever the Student or Classroom model changes.
I know it's trendy to hate on things that have been around a while, and OO indeed isn't the answer to everything, but it's still a useful way of keeping a complex program from getting out of control.
How can I believe you when you tell me what I don't want to hear?
Dijkstra makes an argument about what he calls object oriented programming, but doesn't really use OOP. That he happens to base his argument around two styles of coding, one that is clearly procedural, and one that happens to use objects, is merely accidental. His argument is centered around poor code organization, plain and simple. He passingly slaps down some code modeling Student as an object, neglecting to mention anything about why one would do that (e.g. encapsulation), and completely fails to even mention other OOP ideas such as composition, inheritance, polymorphism, etc. In short, he bashes horrendous code organization, and calls that OOP, without addressing a single reason typically given in favor of OOP. Frankly, that article was awful.
I think what this article highlights is that not everything Dijkstra said was gold. Nor does slavishly following his missives make you a better programmer.
One of the more stupid blog-level postings I've read. I use "blog-level" as an insult, btw. because blogs are generally a source of shallow thinking, because it just is too convenient to publish some thoughts. When it is more trouble, you're also forced to polish them more.
Firstly, to understand the difference between trying to do and "trying to do", read some Dennett. If correctly understood, anthropomorphisms like the attribution of intention to a non-intentional entity can be extremely helpful.
Secondly, not even his example is anywhere near what he's trying to explain. Yes, the analogy breaks down but it has nothing to do with the convulted reasoning he's applying. The cause for the analogy to break down is that there's no equivalent to walking to the classroom in his example. All of his code simply assigns a classroom number, without any equivalent of the walking part. As soon as you add that - magic ! - the analogy works again.
Assorted stuff I do sometimes: Lemuria.org
Oh FFS. Look on the bloody Bagel packet before you buy. If it doesn't say 'implements toastable' then don't buy em. Yeh , they may be a few bucks more, but thats your own fault for getting a toaster that is made by the same people who make the bagels.
This is why I like Python. Python allows object-oriented programming styles or procedural, or a mix. Python has a lot of warts, but it's really refreshing to me to use. Every time I look at Java, I'm turned off by the forcing of class-based object-oriented programming for everything, even when the program is really just procedural with a static main. Perhaps this tends to make programmers try to shoehorn OOP when it's not the best fit.
OOP is a tool, and like any tool it has places and times where it is useful, and places and times where it is not. Knowing when to use it and when not to is part of the art and craft of programming. Does OOP improve the overall organization, reading, and flexibility of a given portion of software to change? If you don't have a good answer, then consider skipping it.
All-or-nothing zealots are usually full of squishy stuff. In the past, one was told to model all domain nouns as objects and/or classes (depending on language flavor). That doesn't always work well, especially if a database is being used. Domain nouns are often poor candidates for OO-ness. Objects seem better suited, however, for computing-domain nouns, such as GUI's, report columns, files, sockets, security profiles, etc. That's my experience.
(However, lately GUI's seem to have outgrown OOP, as multi-factor and situational grouping and searching becomes more important for managing mass attributes and event handlers, and I'd like to see research in database-driven GUI engines, perhaps with "dynamic" relational or the like.)
Table-ized A.I.
nonsense, procedural code cooks until the toasted flag is true.
A dash of anthropomorphism is actually quite helpful to a programmer - the trick is that people are just not applying it in quite the right way; instead of considering a program or objects as a rational kind of being that does what you tell it, instead consider that code and objects are all malevolent entities that exist only to twist what you tell them to do into the most horrific possible result.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Anthropomorphism is degenerate no matter the situation.
True. Anthropomorphism is always trying to get into trouble and ruin other people's lives.
I often don't like the choices people make, but I like the fact that people make choices. That's why I'm a conservative.
Don’t anthropomorphize computers, they hate that notes that most developers do use anthropomorphic language. I think there are probably a variety of good reasons for it, too. Here's one speculation: When we communicate with a human, we must use some language that will be more-or-less understood by the other human. Over the years people have developed a variety of human languages that do this pretty well (again, more-or-less). Human languages were not particularly designed to deal with computers, but languages have been honed over long periods of time to discuss human behaviors and their mental states (thoughts, beliefs, goals, and so on). In any case, the problem isn't anthropomorphic language, it's the use of a bad analogy.
- David A. Wheeler (see my Secure Programming HOWTO)
"The program doesn't know to check for" is in fact more accurate than "The program wasn't designed to check for". The second statement could mean that it wasn't designed to do something, but might do it anyway - what the program ACTUALLY does is left somewhat ambiguous (this is a technique lawyers will often use answering in court). In the first instance the statement makes it quite clear the program DOES NOT KNOW HOW to do what you are talking about.
You can shorten something so far for clarity, but if you go to far you end up with less clarity.
The "thinks" part at the end could go though, removing that does no harm to clarity.
The thing is, writing clearly is just plain hard - being able to use anthropomorphic kinds of terms helps make it simpler to add clarity to description at the cost of somewhat wordier sentences... kind of like how sometimes you make a program a little more verbose so that a different programmer coming across the code later can understand it.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
This has been going on since before object-oriented programming existed. In Unix, for example, processes have "parents", "children", and can be "killed".
Lets say you're a traveling auto salesman, and you would like to sell your cars to different stores around the state. You could either drive each car, one at a time, to each assigned destination and hitchhike back to your starting point (always with a towel). Or you could come up with an algorithm for taking all the cars, putting them into a truck, and finding the shortest path that visits each auto store, saving gas and giving you the street credibility to comment on the appropriateness of OOP vs procedural languages. Then, after having spent a more fulfilling life than most people by being so efficient, you can watch as people invoke your name, and come up with a poor analogy which doesn't really explain OOP vs procedural languages that shows up on Slashdot.
Humans are bad at abstract logic. Not just bad, but shockingly, horribly bad. It requires many years of teaching to get them to learn how to reason according to logical principles and to avoid logical fallacies. Most people never get there at all.
OOP is a step in the right direction, for some kinds of programming. You don't always need to tell a story about your concept space. Sometimes what you're doing is so simple, and so shortlived, that it doesn't matter. However if you want long term maintainability and something that other people are going to be able to learn as quickly as possible, OOP wins. Consider the following example:
English:
John loves Sally. People like to spend time with others that they love. Does John like spending time with Sally?
If you are human and not deeply mentally impaired, you will quickly answer "yes" to the above question
Symbolic logic:
Derive Q (John likes spending time with Sally)
P (Assertion)
P -> Q (Modus Ponens)
Did you immediately think in your brain the following:
Q (Consequence of premises 1 & 2)
A lot of people who stare at that sequence of symbols will require a few moments to process it. Very few will read it as trivially as they read the English expression, although both expressions communicate the same relationships and information. Why is that? It is because the logical derivation is an abstraction above the English expression (which itself is of course an abstraction of something else). Every level of abstraction adds to how difficult it is for a human to comprehend something. It doesn't mean they can't get it, it means it will take longer (though depending on the person it might mean they can't get it).
Do you want people to be able to read your code in the future? The best chance of them succeeding is to use object oriented programming, and to create a class model that closely resembles what most people intuitively understand as the concept space you are working in.
Humans did not evolve to process information regarding Ps and Qs. They evolved to process information about Johns and Sallys. They are much better at the latter than the former.
> Anthropomorphism is degenerate no matter the situation.
a) Man is the measure of all things.
Anthropomorphism is something we cannot really ever abandon -- be it regarding our tools and even regarding what goes around us.
I always got upset with people who are Biology Nazis and go like "you cannot say that organism wanted to lose its teeth". Well, this is obvious! And yet (IMHO) it's a perfect valid way to state a fact -- either for youngsters who cannot grasp the way evolution really works and for adults, as a figure of speech.
b) The discourse at the end of The Great Dictator, by Chaplin, would also be useful. If you abstract enough, a good part of morality is lost. You are not machines...
c) OOP was never about anthropomorphism. One model entities, which might be humans or not. The article author didn't like an anthropomorphic example. Fine, do it with bacteria. Analogies now and then break. This has nothing to do with OOP as a method for problem specification and treatment.
d) Sometimes we get fed up with things and the current trend of flat designs is an example. We got tired of anthropomorphic controls. Very nice. And it shall pass, too. And we'll be back to more human-adapted designs, futurely, and will be touted as a novelty. Hah!
e) I've read both articles: the author has a much narrower aim at how one analogy broke; EWD says anthropomorphism fails (with what I agree) in a text written by hand (I had the pleasure to read another some months ago, he even let some text he stroke through remain. It's obvious he's not against anthropomorphism de per se, but he cautions us about the dangers of using it (like in the expression "restless waves").
f) OOP has its place, and in some niches it may not be as useful, so procedural might be better. But then this can be said about the car and the bicycle. Where I disagree with the author is about OOP being syntactic sugar, since OOP happens at an earlier stage -- before syntax takes place. The implementation of OOP might be seen as that, but then again an implementation is not the idea itself.
g) The author is way above my knowledge level; but then, this might be the source of his problems. I'd humbly suggest he backs away of his expertise and try a more conventional big picture view. There's a reason why OOP was invented and it will be debunked by a better knowledge model -- not by a previous one.
Btw, in reality procedural and object oriented are just two different views and controls on the exact same datastructures and process-flows.
'Object oriented' just means that you can extend the type system of the language which is completely orthogonal to procedural programming. It doesn't matter if you use only base types in your sub-routines, or add some custom types made with oop. So those approaches aren't even mutually exclusive. Just some common language constructs, which some languages implement and some don't.
An analogy that breaks down if you push it too far?
Ridiculous! You cannot push analogies. They are not tangible things.
OOP doesn't want to be anthropomorphized
What gets me is this:
If you don't draw analogies (like anthropomorphism), or abstractions, how the hell do you choose your names in a way that lends itself to understandable code? The author should take his own argument one step further and realize that calling a string of bits a "student" is likewise anthropomorphising the data, and calling another memloc a "Classroom" is applying an anology to what is really going on. Then he could reduce is argument ad-absurdium to requiring that all identifiers be randomly chosenstring to avoid installing unintentional meaning into data structures and procedures/functions.
Someone had to do it.
I always got upset with people...go like "you cannot say that organism wanted to lose its teeth". Well, this is obvious! And yet (IMHO) it's a perfect valid way to state a fact...
It's what Daniel Dennett calls the "intentional stance." I agree with Dijkstra, that anthropomorphizing code is frequently problematic, but the intentional stance can be quite useful in general. Most of the systems we build and encounter in our daily lives are "intentional systems", designed to achieve specific purposes in an external physical reality, and the intentional stance is really parsimonious for these cases.
.: Semper Absurda
Anthropomorphizing is not this ridiculous caricature. It is a very effective process by which we relate new information to information we inherently have. Would you rather relate new information in a way you and others can readily understand or in a way you and others can't readily understand?
Sure, it's not perfect, but usually you're looking for good enough, not perfect. For example, consider this example from my neighbor, Yellowstone National Park. You are tourist and come across a bull (male) elk. It's a 600 pound member of the deer family with an antler spread around two meters wide. There are correct and incorrect ways to anthropomorphize the behavior of that bull elk. The following is the incorrect way which unfortunate, real world tourists use each year: "That's a pretty elk. I know he wants me to pet him, because I would like being petted if I were a pretty elk too!" Their world gets rocked as a result. Consider the alternate approach: "That's a big elk in the middle of rut season. I bet he'll be pissed if a crazy human tries to touch him. I would if I were running around hyped up on hormones." Look! No headbutt Ma! Obviously, neither approach captures what it means to be elk or those elk sensibilities. There is this certain lack of nuance of the elk point of view. But one approach, which I would go as far as to label an entirely correct approach to understanding in this scenario, keeps you from finding out what pointy antlers backed by 600 pounds of enraged elk can do to a person.
My view is that humanity and our behaviors are sufficiently complex that one can shoehorn any understandable phenomenon into an anthropomorphic basis. The real problem is not the process, but insufficient understanding of the problem needed to come up with a sufficiently correct anthropomorphic model.