4 ms·

In my opinion you're seeing it wrong. The beauty of FP is that from your code's point of view there is no mutation. Everything is immutable, everything is clean

In my opinion you're seeing it wrong. The beauty of FP is that from your code's point of view there is no mutation. Everything is immutable, everything is clean and beautiful. But then the compiler is able to tell that your variable that's used as an argument to a tail-recursive function is actually being redefined on every recursive call and treats it as a mutable variable in the output assembly. Similar ideas are applied throughout those languages. For example, in OCaml you have the notion of "functional record updates". Basically you update structs by getting a whole copy back with the modified fields changed accordingly. Under the hood though, what you get is just the changes and the other fields point to the original struct. Basically there is a difference between what your code says and what the compiler outputs, but in the end the result is the same, the compiler is just smart enough to rewrite it for you. You're right that it's further from the computer, but only for what you type in your editor. I highly recommend the book Functional Data Structures (it's on Amazon) if these sort of brilliant compiler optimizations interest you.

theseoafs 12y ago
> The beauty of FP is that from your code's point of view there is no mutation. The beauty of pure FP is that from your code's point of view there is no mutation. The only functional language you mentioned in your post is OCaml, which is impure and supports ad-hoc mutation, like every other language in the ML family, and like every other functional language except for a select few like Haskell and Miranda and their derivatives. Moreover Haskell supports other kinds of mutation besides fusion and tail-call elimination; it just does it behind a pure interface. See, for example, http://hackage.haskell.org/package/array-0.1.0.0/docs/Data-Array-IO.html http://hackage.haskell.org/package/array-0.1.0.0/docs/Data-A... . So we're back at the same place: obviously mutation is useful since even Haskell goes out of its way to make sure you have access to it.
- AnimalMuppet 12y ago
  I think the pure interface is the useful part. If there's mutation, but I can firewall it behind a (non-leaky) pure interface, then I don't have to reason about that mutation if I'm looking at code outside the interface. That's a huge win. Now, OO tries to do the same kind of thing - hiding things behind an abstraction that you don't have to think about from outside the abstraction. The problem is, all the abstractions leak. Does Haskell's hiding mutation behind a purely functional interface leak? I don't know enough to say, but I think it's a critical question.

theseoafs 12y ago

> The beauty of FP is that from your code's point of view there is no mutation. The beauty of pure FP is that from your code's point of view there is no mutation. The only functional language you mentioned in your post is OCaml, which is impure and supports ad-hoc mutation, like every other language in the ML family, and like every other functional language except for a select few like Haskell and Miranda and their derivatives. Moreover Haskell supports other kinds of mutation besides fusion and tail-call elimination; it just does it behind a pure interface. See, for example, http://hackage.haskell.org/package/array-0.1.0.0/docs/Data-Array-IO.html http://hackage.haskell.org/package/array-0.1.0.0/docs/Data-A... . So we're back at the same place: obviously mutation is useful since even Haskell goes out of its way to make sure you have access to it.

AnimalMuppet 12y ago
I think the pure interface is the useful part. If there's mutation, but I can firewall it behind a (non-leaky) pure interface, then I don't have to reason about that mutation if I'm looking at code outside the interface. That's a huge win. Now, OO tries to do the same kind of thing - hiding things behind an abstraction that you don't have to think about from outside the abstraction. The problem is, all the abstractions leak. Does Haskell's hiding mutation behind a purely functional interface leak? I don't know enough to say, but I think it's a critical question.