[DanielBMarkham]

No rhetorical trick intended.

It's a definition thing, sure. But it's important to realize that there's no trickery going on here. There's a very important point.

I get this all the time, and from all aspects of software engineering. As an example, it's become quite fashionable to say something along the lines of "use-cases suck!"

However use-case analysis is just a way of thinking about system functionality. Most people, when pressed, actually mean "we hate these monstrous word templates and rigorous bullshit that people make us do and call them use cases"

To which I do not disagree. But that's confusing the application with the tool again. To insist that they are the same is to throw out huge hunks of software engineering simply because a few people got into them and made them overly-complicated and onerous to use.

Or put another way: I'm sure some folks would like to describe OOP in terms of overly-complex class diagrams, lots of wiring, un-manageable systems, yadda yadda. Some other folks would like to describe OOP in terms of small systems pragmatically created bottom-up. It can be any or all of that. OOP is actually constructing solution code in a pattern that supports encapsulation, polymorphism, information hiding, etc. The idea is a conceptual tool, a code construction pattern of thinking. The implementation can be all sorts of things. Various implementations suck to more or less degree. But that's really not important. What's important is whether this tool is useful right now, do I know how to use it, and which parts work and which parts get in the way of where I'm going.

I understand that this can sound like sophistry, but it's not.

[stonemetal]

OOP is actually constructing solution code in a pattern that supports encapsulation, polymorphism, information hiding, etc. The idea is a conceptual tool, a code construction pattern of thinking.

Yeah except Alan Kay, you know that guy who invented OOP, says everything you mention there is the overly complex BS unOOP. OOP is late binding and message passing. It isn't the hair splitting you seem to think it is, it truly different philosophies about programming. What you are calling OOP is more like Structured Programming Redux, strong on the structure and light on the dynamic message passing and late binding.

[loup-vaillant]

In his own words (from HN, I think): http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-...

The way I read this, he should have called his paradigm "Message Oriented Programming", and Erlang is actually closer to his views than Java.

[DanielBMarkham]

Alan Kay? Well gee, you should have said something. Here I was using working definitions and Alan Kay already had the answer.

Either you understand how silly you sound or you do not. I suspect the latter. Perhaps you and Alan could continue the discussion.

[stonemetal]

What can I say a silly response to a silly post. Information hiding, encapsulation,polymorphism, have been Software Engineering principles before OOP was invented Using X == good software engineering then X is the true definition of OOP no matter how you program it, and all that bad OOP code is just wolves in OOP clothing is humorous. Good clean structured code may look similar to OOP code. If the author was not Oriented on Objects then it isn't OOP code. OO is more about how you get there than where you end up.

[loup-vaillant]

> No rhetorical trick intended.

(I suppose you refer to the "just a tool" sentence.) I'm sure of that. It's just that its an easy sentence to throw up while not really thinking about it. I see it often, and it rarely actually says something. And its effect, whether intended or not, is often the rhetorical trick I spoke of.

About the rest, I agree: when (if) disagreeing parties manage to set definitions straight, they often find that they actually agree.