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.

Comments

Strawman

[Anonymous Coward]

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"

Summarizing

[ofranja]

Object oriented programming, the "crystal healing therapy" of computer science.

Re:Summarizing

[NoNonAlphaCharsHere]

Don't anthromorphize your objects. They don't like that.

Procedural vs OO

[NoNonAlphaCharsHere]

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.

Re:Procedural vs OO

[kjots]

By the same token, now you have to implement pie.toast() and cake.toast() and lots of other useless and irrelevant methods, even though you're never ever going to use them, simply because they extend the isBakeable() interface.

Unnecessary, since the IsBakeable interface provides a default implementation of the toast() method that throws an exception if you attempt to toast something that is not toastable.

The real issue is why the IsBakeable interface has a toast() method in the first place...

Ya, Sure.

[wisnoskij]

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.

Missing the point

[pushing-robot]

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.

Re:Programming languages are not really "language"

[skids]

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.