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.
I think there is a layer there at which point it's useful, and one at which it's not. It's fine to anthropomorphize a program when explaining to an end user why it's broken, e.g. "The program doesn't know to check for the start date of a new lease when the old one expires, it just thinks it should activate it regardless." (Actual problem we're having to fix right now.) But of course the developer shouldn't think that the program is confused; it's doing exactly what we asked of it in a nightly stored procedure, and not bothering to check start dates because it wasn't programmed to do that in the first place!
Occasionally living proof of the Ballmer peak.