On Nov 3, 6:44 pm, cwyang <[EMAIL PROTECTED]> wrote: > So, I understand as follows: > - OOP: keeping objects, which has states and methods. > methods are encapuslated to the corresponding object. > - FP: keeping objects(or structs or variables, whatever it is called) > and functions on the objects. > functions does not encapsulated to specific objects, for some > reasons.
To me, FP is all about the lack of side effects, or about limiting side effects at least. A program's output is a _function_ of its input, which means that the same input always results in the same output. This is very helpful for reasoning about the correctness of your program, because it means that a particular function's output does not depend on the state of your program. It's especially helpful for multithreaded programs where the threads share state, because one thread's state won't ever be changed without its knowledge. Of course sometimes you need side effects in order to accomplish useful work, and a good FP language will provide abstractions that help you limit side effects and reason about them. Clojure does this by means of refs, agents, and transactional updates. refs are different than regular values so that you know they are mutable. An object-oriented program may also use FP. OOP and FP are not opposites. However, a lot of OO programming these days involves changing the state of opaque objects (therefore, not purely functional) via member functions. I've heard this characterized as "the new spaghetti code" because it's hard to reason about thread- safety when objects are being modified all the time, and when these modifications aren't syntactically obvious. For example, the member function call y = x.f() might modify x, so you have no idea whether f() is thread-safe (unless you look at the source code and try to reason it out yourself). f() might modify x in nonobvious ways which the authors of f() might not have documented. For example, f() might write to a temporary buffer inside the x object. Calling f() on the same object in multiple threads without the appropriate locking may corrupt that buffer and cause f() to return an incorrect value (or worse; f() might overrun the buffer). OOP doesn't have to do this, but a lot of OOP code does this. mfh --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
