[zackzackzack]

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). 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]

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

[Locke1689]

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.

[jmillikin]

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]

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]

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]

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]

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]

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?

[narrator]

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]

That's not mutation. Mutation is altering the value of a bound identifier.

[tkellogg]

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...