5 ms·

Mutable state won't eat your children if you know how to handle it in a disciplined manner. Pure functions and immutable datatypes are definitely preferable in

Mutable state won't eat your children if you know how to handle it in a disciplined manner. Pure functions and immutable datatypes are definitely preferable in a variety of cases. However, just because you discover one day that there are better tools for driving screws than a hammer doesn't mean you have to start banging your nails in with a screwdriver and wearing a saffron robe and preaching to your friends that you have achieved liberation and that they won't be free until they also throw away their hammers. The softwareverse (and he universe, for that matter) is still full of patterns and constructs that are inherently stateful, and need to be constructed such that they behave as if they were stateful. Heck, some constructs simply can't be made to work efficiently in a purely functional manner. Hash tables come to mind. Fortunately we already have a tool that's proven to be excellent for efficiently and effectively modeling state. No, it's not monads. It's state. And it does the job so well that even Haskell was forced to resort to it for its hash table implementation. (Though admittedly not until after much sound and fury to the effect of, "Nobody needs hash tables; trees are Pure and just as good!" I'll say this for silver bullets - people sure can cling to them.)

gnuvince 15y ago
I don't think anyone says that mutable state should be completely eliminated; the argument is that it should (1) not be the default, and (2) be made explicit through the type system.
- jinfiesto 15y ago
  While you're right, I think that's kind of obscured by the language that a lot of functional evangelists use. I myself prefer FP (Lisp first, now Haskell,) but most people who are coming from an imperative programming languages tend to see Functional languages as uselessly pure. As a matter of fact, in LYAH, the author states that Haskell is totally 100% pure. Which of course, is true in a sense, but false in another, at least in that we still model and use mutable state. (It's just marked by the type system, as you mentioned, and it's done in a functional way and usually heavily sugared.) In Haskell, I'm disregarding the IO monad.
jfoutz 15y ago
Haskell is more about inverting the responsibility. Just code up whatever in Haskell and it might be slow, but there are a whole bunch of errors that code just can't have. When you need the big unsafePerformIO hammer, it's there for you. Anybody can write fantastic threaded code in any language if they think real hard about it. Haskell just makes you say, "Yes indeed i did think really hard about it. I'm not just checking this in on friday afternoon so the boss doesn't bug me." I'm not real familiar with erlang, but IIRC it has very similar appeal to a higher power semantics. This may or may not be useful, depending on the kind of work you do. I ,for one, am often undisciplined but occasionally very clever. Given that, the Haskell model is very enjoyable ; I've never used it to make money though. So there's that.
jberryman 15y ago
The argument is that while a good programmer can manage and perhaps reason about mutable state in a single threaded program, this becomes impossible when concurrency is added to the mix.
- bunderbunder 15y ago
  I'd argue the real problem here is that too many people are taught to rely on shared mutable state in concurrency. Mutable state and concurrency mix very easily as long as you stick with something like message passing for your cross-thread communication. Erlang stands out as a stellar example of how successful that approach can be, but it can just as easily be done in C. Event-driven and client/server programming, as close cousins of the Erlang model, are concurrent even when they aren't parallel, and have given us a couple decades' worth of proof that good programmers don't really have a problem with it, and even mediocre programmers can manage it. The point where everything really gets hairy when the word 'lock' gets introduced into the mix. If we take, for the sake of argument, that the primary motivation for writing parallel code is some version of scalability or performance, then I don't think we should be so hasty to jettison mutability. After all, concurrency is only a means to an end. The real goal is performance, and it's generally much easier, if not more possible, to write performant code if you allow yourself some mutable state, however judiciously it is used. The hash table example from my earlier post is an elephant in the room here: Hash tables can give near constant-time performance. The closest anyone has ever gotten with a purely functional equivalent is O(log n) plus a healthy dose of cache-unfriendliness to boot. If that must be the cost of pervasive parallelism, perhaps we should be reconsidering how pervasive parallelism really needs to be.
  - cageface 15y ago
    The problem with message-passing approaches is that you have to keep multiple copies of your data structures in sync and this can be just as tricky as handling mutable data. The kind of functional data structures you find in languages like Clojure or Haskell can simplify these issues a lot

gnuvince 15y ago

I don't think anyone says that mutable state should be completely eliminated; the argument is that it should (1) not be the default, and (2) be made explicit through the type system.

jinfiesto 15y ago
While you're right, I think that's kind of obscured by the language that a lot of functional evangelists use. I myself prefer FP (Lisp first, now Haskell,) but most people who are coming from an imperative programming languages tend to see Functional languages as uselessly pure. As a matter of fact, in LYAH, the author states that Haskell is totally 100% pure. Which of course, is true in a sense, but false in another, at least in that we still model and use mutable state. (It's just marked by the type system, as you mentioned, and it's done in a functional way and usually heavily sugared.) In Haskell, I'm disregarding the IO monad.

jfoutz 15y ago

Haskell is more about inverting the responsibility. Just code up whatever in Haskell and it might be slow, but there are a whole bunch of errors that code just can't have. When you need the big unsafePerformIO hammer, it's there for you. Anybody can write fantastic threaded code in any language if they think real hard about it. Haskell just makes you say, "Yes indeed i did think really hard about it. I'm not just checking this in on friday afternoon so the boss doesn't bug me." I'm not real familiar with erlang, but IIRC it has very similar appeal to a higher power semantics. This may or may not be useful, depending on the kind of work you do. I ,for one, am often undisciplined but occasionally very clever. Given that, the Haskell model is very enjoyable ; I've never used it to make money though. So there's that.

jberryman 15y ago

The argument is that while a good programmer can manage and perhaps reason about mutable state in a single threaded program, this becomes impossible when concurrency is added to the mix.

bunderbunder 15y ago
I'd argue the real problem here is that too many people are taught to rely on shared mutable state in concurrency. Mutable state and concurrency mix very easily as long as you stick with something like message passing for your cross-thread communication. Erlang stands out as a stellar example of how successful that approach can be, but it can just as easily be done in C. Event-driven and client/server programming, as close cousins of the Erlang model, are concurrent even when they aren't parallel, and have given us a couple decades' worth of proof that good programmers don't really have a problem with it, and even mediocre programmers can manage it. The point where everything really gets hairy when the word 'lock' gets introduced into the mix. If we take, for the sake of argument, that the primary motivation for writing parallel code is some version of scalability or performance, then I don't think we should be so hasty to jettison mutability. After all, concurrency is only a means to an end. The real goal is performance, and it's generally much easier, if not more possible, to write performant code if you allow yourself some mutable state, however judiciously it is used. The hash table example from my earlier post is an elephant in the room here: Hash tables can give near constant-time performance. The closest anyone has ever gotten with a purely functional equivalent is O(log n) plus a healthy dose of cache-unfriendliness to boot. If that must be the cost of pervasive parallelism, perhaps we should be reconsidering how pervasive parallelism really needs to be.
- cageface 15y ago
  The problem with message-passing approaches is that you have to keep multiple copies of your data structures in sync and this can be just as tricky as handling mutable data. The kind of functional data structures you find in languages like Clojure or Haskell can simplify these issues a lot