One thing to say is that OO doesn't mean no-functional and functional does't mean no OO. For instance, Python's String is functional since you can't alter it.. 'test'.replace('t', 's') will always return something new and does't not depend of anything but the string itself. I'm not saying python by itself is purely functional.. (as scheme is not purely functional).
I'm saying that because I've had great success recently by using immutable objects in languages that aren't.. how to say, functional friendly?
I always trie to explan that to people its not about FP vs. OO. You can have a very functional OO language (dylan or scala come to mind) or you can have a imperativ OO Language (Java).
The real importend fight is FP vs Imperative. If the language is OO or not does not really matter.
It's hard to use functional paradigms without closures and first class functions. But, more importantly, I would say it's more about the mentality of API designers and java programmers.
I've once used high level functions in PHP in a real production environment and it caused so much political problems that I had to rewrite everything in an imperative style. Not that the code was badly written.. it's just a different style that not everyone is used to.
I'd totally agree with the mentality bit, but it's not hard (although it can be unwieldly) to write functional-style code in Java if you're disciplined.
Imperative programmers will write imperative Scala, too.
For OO you have to have state. Objects should have identities which distinguish them. That means that two objects are distinct even if all their properties are equal.
This break referential transparency. Two runs of "new Integer(2);" will be different.
So you cannot have proper functional language with OO. Even if all your objects are immutable.
Doing stuff based on identites is bad. Two runs of "new Integer(2) may be diffrent but I don't care about that as long as "equality" checks are based on guess what "equality" and not identety. What address on the heap the objects live on is an implementation detail.
If I remember correctly in Dylan you have two operators = and == the first checks for equality the secend for identety.
"identity is the basis for polymorphism in object-oriented programming."
In a purely functional object-oriented programming you don't need identity. But then that practice is almost indistinguishable from usual pure functional programming we have for at least 20 years with Haskell.
Forgive my insistence, but, what kind of problem does the ability to differentiate objects from one another solves? What kind of programs are made simpler by this ability?
Besides, I don't see how you would need identity in the sense of being structurally-equal-but-not-the-same for class based polymorphism. You could perfectly do this without any side effect, despite what the `final` keyword in Java might mean.
By "identity" Wikipedia probably means something like "you think I'm a Foo, which is right, but underneath, I'm a special kind of Foo: a Bar. By the way, there are others special kinds of Foo: the Baz, the Fiz, the Buz…". In other words, subtyping is the basis for polymorphism in OOP.
>Forgive my insistence, but, what kind of problem does the ability to differentiate objects from one another solves? What kind of programs are made simpler by this ability?
Oh, I don't know. I am not an expert in OO* at all.
All I know is that for something to be true OO it has to have objects with identities. I was told so. ;)
All I know about OO is Liskov substitution principle. Where it is unnecessary I tend to use State monad and immutable objects.
>subtyping is the basis for polymorphism in OOP.
Which can be solved by several means, interfaces and inheritance being two of them.
Please, list object-oriented systems with objects with identities and object-oriented systems without those. Count both. Discuss. ;)
Alan Kay, who coined term "object-oriented" described object-oriented system as an assembly of objects communicating by message passing. Message passing requires identities (and state, except in severely reduced form).
Message passing does require a sender, a receiver, and a message. You can have those in purely functional programming.
No identity needed. But if you really want one, you can have it: Two objects are identical, if they react to all messages in the same way. You can also explicitly define equality ==, and then say that a and b are identical if a == b.
My Ocaml code is not pure, but we can easy remove any occurrence of `ref`, and restricting oneself to pure methods, which produce a new fresh object instead of modifying `this` in place.
Sorry, I am not very fluent in OCaml. Also, I didn't find word "message" in the link above.
I am experiencing limitations of pure objects and message passing almost right now. In my spare time I am currently developing dynamic data flow CPU which is based on immutable "objects" and message sending. It is quite unusual style of programming, very unlike anything else, including Smalltalk, Erlang and everything.
I'm saying that because I've had great success recently by using immutable objects in languages that aren't.. how to say, functional friendly?