3 ms·
The consistent interface point is well taken, and I think that's the main reason for OO's commercial success. If you force everyone to be verbose in their inter
by throwawayplz 15y ago
The consistent interface point is well taken, and I think that's the main reason for OO's commercial success. If you force everyone to be verbose in their interface definitions, code is far less likely to break across distributed teams of devs.
I take issue with your "functions/methods are data." remark. They are not. If they were, they'd be mutable, and I could process them, make copies of them, and change them the way I do other data. This is the wannabe lisper in me getting out, but there's a world of difference between treating your methods as data that you can pass around, and having them be data items that you can actually transform.
In C I can pass function pointers around, and do with some regularity, without making everything in my programs objects.
I realize that some OO languages have this ability, but the mainstream ones (java, C++, python, ruby) generally do not.
- jinfiesto 15y agoI worded that wrong. I'm a lisper as well. I should have said "The interface for functions/data is uniform across both." That's much more verbose. It's why I quoted the "are" I used in my initial post. My original post was also incomplete. When I said "everything is an object," I meant in a scope larger than the language itself. If you've ever played around in a smalltalk environment, you quickly realize how powerful the OOP idea is, when the programming language becomes a uniform interface for EVERYTHING. You can literally send messages to the objects that make up the environment. I can create and modify a GUI program live simply by sending messages to the Window class. OOP is very powerful when it's turtles all the way down. To be fair, I didn't "get" OOP until I did Smalltalk. Honestly, everything else SUCKS compared to it. All the same, learning Smalltalk gave me an appreciation for the paradigm and I grokked it in a way I hadn't before. Also, since you're a Lisper, the third chapter of Structure and Interpretation of Computer Programs is implicitly about Object Oriented Programming. It's surprisingly helpful. It focuses on "message passing" and how it affects program design. It also addresses how OOP creates an informal type system and the problems associated with that. It manages to do all of this without ever talking about OOP by name, or bringing up anything stupid like inheritance. I can't really comment on your C comment. While I "know" C, I've never done any extensive programming in the language (sadly,) so I'm not really qualified to comment.
- throwawayplz 15y agoThanks for the info - I'll give Smalltalk a look.