[ihsw]

Personally the only point of contention with FP vs OOP is immutability, or more directly managing state. The distinction between 'simulating people behavior' and 'measuring people behavior' is probably intentionally vague to spur the imagination, but it's quite apt.

Many languages implement multiple flexible looping/filtering structures to discourage shoving everything into for/while loops (which are susceptible to confusing and messy continue, break, goto, yield statements strewn about). Furthermore the rationale behind Clojure[1] is stateful objects are a new kind of spaghetti code, and managing state across scopes requires breaking mental boundaries.

[1] http://clojure.org/rationale

[bascule]

I think the larger problem is referential transparency: most OO languages allow two objects that represent the same states to have distinct identities, even if compare-by-value claims they're equal.

Of course, it's not impossible to have referentially transparent objects. I wrote such a language (Reia)

[groovy2shoes]

    > most OO languages allow two objects that represent the 
    > same states to have distinct identities, even if 
    > compare-by-value claims they're equal.

You can do this in languages that offer only compare-by-value by attaching a unique ID to every object. Of course, you may have to write your own equality relation if you want compare-by-value semantics in addition to compare-by-identity semantics.

[fogus]

This kind-of hearkens back to simulation I think. That is, if two objects have the same properties then it might be useful to identify them as distinct things because they are in fact distinct entities. That they happen to have the same properties is a matter of fidelity only.