6 ms·

The author seems to think that because a language supports functional programming, it cannot support mutable state in any form. It would be worthwhile to actual

The author seems to think that because a language supports functional programming, it cannot support mutable state in any form. It would be worthwhile to actually look into what sort of support for various types of state that a language like Clojure has (http://clojure.org/state http://clojure.org/state). There are at least 3 ways off the top of my head that I can change the value of a variable in a Clojure process during runtime. It's obviously not the sort of control over state that you have in C++, but it's a far cry from define a variable once and that's all you can do.

nicktelford 14y ago
The re-enforcement of the fallacy that FP shuns mutable state really put me off this article.
- Locke1689 14y ago
  Functional programming does shun mutable state. It just doesn't make it impossible. Functional programming is a style of programming which uses the lambda calculus as its base model of computation. Just because you can subvert that at times doesn't mean that idiomatic code doesn't disapprove of breaking referential transparency.
  - narrator 14y ago
    Well you can mutate anything you want in FP as long as it's the end of the stack (via function calls or return values).
    - Locke1689 14y ago
      That's not mutation. Mutation is altering the value of a bound identifier.
  - jmillikin 14y ago
    Functional programming doesn't shun mutable state. It shuns global state, which is not the same thing. Mutability is well-supported even in very stringently functional languages such as Haskell.
    - Locke1689 14y ago
      No. It shuns mutable variables. It provides outs for performance or architectural reasons, but it's never a "good thing." The ST monad is there for many reasons but if you can avoid it you probably should. If profiling says it's necessary, then add it. Look at Coq.
      - jmillikin 14y ago
        That's a frankly silly position to hold. There's no reason to avoid ST, and in many cases it makes the code clearer and shorter than trying to figure out some pointfree contortionism to reach the same goal. I'll look at Coq when it has support for binding to C libraries, opening sockets, or doing anything else than a programming language needs to support.
        eurleif 14y ago
        You seem to be setting up a false dichotomy between using the ST monad and writing pointfree code ("functions as a composition of other functions, never mentioning the actual arguments they will be applied to"). But you can write non-pointfree code that doesn't use the ST monad, and you can write pointfree that does use it. They're unrelated.
        Locke1689 14y ago
        ST is just a prettified C that's safe and well-typed. If you want to write C in Haskell that's fine, but you're not doing functional programming. This is always the user/theorist divide. I'm not saying that sometimes ST isn't necessary, but it should always be the smallest necessary imperative subset. By the way, the authors of the ST monad make this same point (read the paper). ST is (by necessity) always single threaded. It ruins modularity by not being able to interact with any non-ST code. In short, it's not functional. Anyway, theorists will continue to do interesting things with Coq and whether or you think it's sufficient as a "programming language," it's useful to us.
  - sparkie 14y ago
    The research paper linked to by the author of this article also shuns mutable state, but takes a different approach to how you might do it in Pure FP languages (e.g, with monads). They basically describe a modified C# language, with global state (static variables) eliminated - any global state is immutable only. Naturally, anything marked immutable cannot access anything marked writable, so unless you want to put writable permissions on everything (turning it back into standard OOP), you're going to need to design programs around immutable data by default. Also, anything marked writable in the new language can only be written to by one thread at a time anyway, since the writable references are unique. The result is a significantly different style to the traditional imperative OOP people are used to, so it's not like you can lift an existing program into this paradigm without problems. If the author thinks that FP won't become mainstream, what makes him think that this will?
- tkellogg 14y ago
  I'm still not sure where you read that mutable state is impossible in FP. If you don't mind me quoting, I believe it says: "In most FP languages, variables are declared immutable by default." That doesn't sound like a claim that mutable state is impossible. Perhaps we should spend more time reading and less time criticizing...

nicktelford 14y ago

The re-enforcement of the fallacy that FP shuns mutable state really put me off this article.

Locke1689 14y ago
Functional programming does shun mutable state. It just doesn't make it impossible. Functional programming is a style of programming which uses the lambda calculus as its base model of computation. Just because you can subvert that at times doesn't mean that idiomatic code doesn't disapprove of breaking referential transparency.
- narrator 14y ago
  Well you can mutate anything you want in FP as long as it's the end of the stack (via function calls or return values).
  - Locke1689 14y ago
    That's not mutation. Mutation is altering the value of a bound identifier.
- jmillikin 14y ago
  Functional programming doesn't shun mutable state. It shuns global state, which is not the same thing. Mutability is well-supported even in very stringently functional languages such as Haskell.
  - Locke1689 14y ago
    No. It shuns mutable variables. It provides outs for performance or architectural reasons, but it's never a "good thing." The ST monad is there for many reasons but if you can avoid it you probably should. If profiling says it's necessary, then add it. Look at Coq.
    - jmillikin 14y ago
      That's a frankly silly position to hold. There's no reason to avoid ST, and in many cases it makes the code clearer and shorter than trying to figure out some pointfree contortionism to reach the same goal. I'll look at Coq when it has support for binding to C libraries, opening sockets, or doing anything else than a programming language needs to support.
      - eurleif 14y ago
        You seem to be setting up a false dichotomy between using the ST monad and writing pointfree code ("functions as a composition of other functions, never mentioning the actual arguments they will be applied to"). But you can write non-pointfree code that doesn't use the ST monad, and you can write pointfree that does use it. They're unrelated.
      - Locke1689 14y ago
        ST is just a prettified C that's safe and well-typed. If you want to write C in Haskell that's fine, but you're not doing functional programming. This is always the user/theorist divide. I'm not saying that sometimes ST isn't necessary, but it should always be the smallest necessary imperative subset. By the way, the authors of the ST monad make this same point (read the paper). ST is (by necessity) always single threaded. It ruins modularity by not being able to interact with any non-ST code. In short, it's not functional. Anyway, theorists will continue to do interesting things with Coq and whether or you think it's sufficient as a "programming language," it's useful to us.
- sparkie 14y ago
  The research paper linked to by the author of this article also shuns mutable state, but takes a different approach to how you might do it in Pure FP languages (e.g, with monads). They basically describe a modified C# language, with global state (static variables) eliminated - any global state is immutable only. Naturally, anything marked immutable cannot access anything marked writable, so unless you want to put writable permissions on everything (turning it back into standard OOP), you're going to need to design programs around immutable data by default. Also, anything marked writable in the new language can only be written to by one thread at a time anyway, since the writable references are unique. The result is a significantly different style to the traditional imperative OOP people are used to, so it's not like you can lift an existing program into this paradigm without problems. If the author thinks that FP won't become mainstream, what makes him think that this will?
tkellogg 14y ago
I'm still not sure where you read that mutable state is impossible in FP. If you don't mind me quoting, I believe it says: "In most FP languages, variables are declared immutable by default." That doesn't sound like a claim that mutable state is impossible. Perhaps we should spend more time reading and less time criticizing...