On the definition of object oriented programming
I don't care.
I realized that while I was thinking about William Cook's recent comments about the definition of objects and object oriented programming and the subsequent discussion. If you are designing a new language, then you absolutely do need to know this sort of thing, and to think about it rather deeply, at least if you're interested in knowing what the hell you're doing. But I'm not designing a language, at least at the moment. [Whoopsie. Almost wrote "But I'm not" (period), implying "...interested in knowing what I'm doing". Which may be true, too.]
Here at present, I am mostly concerned with existing bodies of code in existing languages. Here's a simile for you: a chunk of code is like an organism, and a programming language is like a species. Organisms and species have at least some kind of real existence in the world. Other, higher level, taxonomic categories like family and order, not so much. They are abstractions that may or may not be useful for other purposes, but they don't have much to say about any specific situation. Remember, a panda is order Carnivora.
So, as I am interested in code in an existing programming language and in the idioms of that language (which you should be, if you're trying to write code), the question of whether or not the language can be described as "functional" or "object oriented", or "mauve", is supremely uninteresting to me. If I am solving a problem in code, whether the code is "object oriented" by any definition is completely unimportant, compared to whether or not it is idiomatic in my particular programming language and culture. Whether it satisfies the given defition, or not, no matter how valid or important the definition, has no real informational power, it doesn't cast any special light on anything necessary to a given language and body of code.
I'm just sayin'....
Postscript: Upon re-reading, it seems an important part of my introduction stayed inside my skull. I have chiseled it out here:
It is not the case that I do not care about the definition of object oriented programming. I do care about that definition. Cook's comments are very compelling, especially on the distinction between abstract data types and objects; mixing the two leads to a confusing morass. But, much of the energy in the reddit discussion, as well as a goodly chunk of Will's post, goes towards asking how the definition applies to existing languages. Unfortunately, the answer is almost always, "poorly". Especially since the result is frequently counter-intuitive: Erlang is object oriented while C cannot be.[1][2][3]
1. Ignore all the comments about Class Construction in C and C++ being about C++; as I recall, very little of the book concerns C++.
2. Whatever happened to Roger? Oh.
3. See the final paragraph of Objection 4 of Joe's Test Page.
Comments
Hi Tommy, I completely agree that the definition isn't very useful to you. But the definition of "zebra" isn't very useful either. I don't mean to be snide, I'm just agreeing that different tasks need different information. When using a particular programming language, it doesn't matter very much how the language is described or categorized, as you point out.
Will Cook
'2012-07-15T10:20:28.203-05:00'
