Re: "Any system that grows large enough to clearly define an architecture technically is object oriented, so long as it's passing messages among stable interfaces."

@straws: I'm curious, why do you think that the situation you mention above implies that such a system is 'technically' object oriented?

If I'm understanding your claim, I disagree. All you need are mechanisms for:

(1) function-calling or message-passing (I don't think you were trying to emphasize an extremely rigourous definition of 'message passing' were you?)

(2) namespacing

(3) validating a 'stable interface'

There are many definitions of OO, but this is one is good enough for my point: "Objects, which are usually instances of classes, are used to interact with one another to design applications and computer programs" (from http://en.wikipedia.org/wiki/Object-oriented_programming)

You don't need object-based inheritance (e.g. Java) or prototype-based inheritance (e.g. Javascript) to build large systems in this way.

For example, you can build very large systems in Erlang (passing messages too!) without any kind of OO.

There are lots of examples of how functional languages can enforce interfaces without classes, including Haskell.

This. I think the debate between "OO vs. FP" is such a fallacy because it's clear you can do both. I attempt to program as functionally as possible within the OO framework that I use, but I also really like extracting functionality into classes and modules when I need to. It just makes sense to do both at once.