Procedural does not mean "has a main()". It means that the code within a procedure (or method, or function) is always a sequence of steps, i.e., a procedure. OO is a procedural paradigm. doThis(that) is replaced by that.doThis().
The point is, OO does not require that your code be executed any more sequentially than does a functional language.
OO does not require that your code be executed any more sequentially than does a functional language.
If by "OO", you mean mainstream OO languages like Smalltalk or Java, then they absolutely do have a more operational definition than a pure functional language does. Objects send messages to other objects; as a result of receiving a message, the internal state of an object changes.
An object-oriented program is not required to be expressed in terms of a "sequence of steps" any more than is a functional program. You can instantiate objects that talk to one another, asynchronously or otherwise, to collaboratively do work.
Anyone who has worked with a pure OO language knows that there's nothing inherently imperative about the approach.
Can you provide some examples of how you might write "non-imperative" programs in a mainstream object-oriented language?
An object-oriented program is not required to be expressed in terms of a "sequence of steps" any more than is a functional program
A functional program is not a "sequence of steps"; in principle, it is just a mathematical expression that can be evaluated (via some means) to yield a value (think of a SQL query or a Prolog program).
Go back and read my post -- I drew a distinction between "mainstream" OO languages, and pure OO languages. If you want to genuinely understand object-oriented programming, don't look at C++ or Java. Look at Smalltalk or Simula.
"A functional program is not a "sequence of steps"; in principle, it is just a mathematical expression that can be evaluated (via some means) to yield a value (think of a SQL query or a Prolog program)."
I know what you're arguing -- the platonic ideal of the functional program is stateless, and methods within that program have no side effects. In reality, all programs store state somewhere, and even "pure" functional languages store state (albeit at a higher level).
What I'm trying to explain is that object-oriented programming doesn't require side effects. Where functional programs use closures and monads to pass state around, you could just as easily use a functor to do the same thing. Thus, you aren't compelled to write object-oriented code in an imperative style. The difference is that OO code tends to be more explicit about the location of state variables, and calls them what they are. Functional programs, in contrast, just tuck the stateful bits into closures, and pretends that they aren't really state.