On Nov 4, 2008, at 17:26, Mark H. wrote: > 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.
Vars are also mutable, even if that mutability is local to a thread. I guess one could write state-modifying code in Clojure just like in most imperative languages, it is merely discouraged and made hard to hide. That looks like a very reasonable compromise to me. > 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. Even in the absence of threads, changing state can be a cause of trouble, in particular if it is well hidden under a few layers of nice-looking APIs. On the other hand, I am not sure that all important algorithms already have purely functional equivalents that are sufficiently efficient for real life. Is there an efficient purely functional algorithm for matrix inversion, for example? Konrad. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
