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.
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.
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.
"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".
An analogy that breaks down if you push it too far?
Ridiculous! You cannot push analogies. They are not tangible things.
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.