[takeoutweight]

I suppose I can only speak for myself, but as a functional programmer I would never ask you to give up mutation completely.

I do think it's nice that most FP languages give us pure functions and persistent data structures that are easy to use and relatively performant, so we don't have to go out of our way to provide a pure (by construction) abstraction when we want to.

The key idea is to be honest when you are asking for mutation. Haskell would likely be far on the "left wing" (or right wing?) on your political spectrum but you can do mutation whenever you please as long as you're honest and mark it in the types with something like IO, State, or ST (Clojure does something similar in spirit with 'transient'). There is even unsafePerformIO if you are absolutely sure that you are wrapping an impure computation in a way that you know looks pure from the outside.

Purity isn't promoted because it's a virtue. It's that pure expressions generally come with nice commutativity and idempotency laws which give you the ability to refactor code while remaining confident you won't change its meaning or alter the behaviour of distance subsystems. It's worth preserving those properties when you can.

[brudgers]

Maybe, what I am thinking is that a language which makes it easy to program in a functional style, should make it equally easy to program in an imperative one. By extension, this may mean that a good language for functional programming ought to make it easier to program imperatively than languages designed to facilitate imperative programming.

Of course, this begs the question of what is easier and harder and better and worse. There's a case to be made that Haskell's monads make imperative programming easier. It's essentially a mathematical argument - rather abstracto-theoretical versus the sort of concrete arguments that get advanced to avoid discussions of why it might be better to reason with lambda-calculus versus using von-Neumann as a model.

To put it another way, being able to abstract away von-Neumann into mathematics is useful. But the von-Neumann model is useful because it is a model that we can easily get our heads around.

[jackpirate]

If you asked a Haskell expert what their favorite imperative language is, they'll probably say "Haskell."

That is because it "makes it easier to program imperatively" more than any other language I've met.

[trobertson]

Only after the learning curve, though. It isn't immediately approachable as an imperative language.

[the_af]

Yes, but suppose you could write the same program in two languages, a classic imperative one, and a purist and difficult FP language.

For the sake of argument, let's assume the classic imperative language is easier to approach for rookies. If it's also the easiest language to write bugs and make mistakes with, wouldn't the "harder" FP language still be a net win? As long as its learning curve isn't unapproachably steep -- i.e. so steep that your time to market becomes awful -- what is the advantage of the imperative language's ease to hit the ground running and writing lots of bugs?

[brudgers]

If language 'a' lets a person write a program with 'b' bugs in time 't', and language 'aa' lets the same person write the same program with 'b' bugs in time 't-n' then there is a clear net win for all 'n' > zero.

If 'aa' also has the advantage of providing semantics for producing significantly less buggy code in time 't-n-m' at some future time then that is also an advantage but a distinctly different one and one which can be deferred [and probably will be given a significant learning curve].

The first step toward the modern automobile was the 'horseless carriage' not the Countach.

[nightski]

It's greatly overstating the learning curve. It's possible to pick up Haskell by simply writing a few small applications tackling different parts of the language in each one. This can be done in a few months. Not to mention there are now numerous resources available for free such as learn you a haskell, real world haskell, and countless blog posts.

[NAFV_P]

> The first step toward the modern automobile was the 'horseless carriage' not the Countach.

Lamborghini makes shit cars. The only reason people rave about them is because they have giant engines. A car without a reverse gear is one of the stupidest ideas in automobile history.

[jimbokun]

"But the von-Neumann model is useful because it is a model that we can easily get our heads around."

I am skeptical of this statement.

Programmers make a lot of errors when reasoning about mutable state, so I don't think it's fair to say "we can easily get our heads around the von-Neumann model". My intuition is programs written without mutable state will, on average, have fewer errors, which suggests to me the more "mathematical" nature of functional programming is actually easier to wrap one's head around.

Not sure what empirical data is out there to test this hypothesis.

[brudgers]

I probably wasn't clear enough. My point is that the von-Neumann model allows us to walk up to a computer and point and say, "Here is the memory and here is the processing unit and here on this test probe of register 47 we see the instruction to move the contents of memory address 42 from memory into register 19." Even my mom can understand a sketch of the von-Neumann model to some degree.

Because functions are not a model of a computer, but a means of computation, there's no obvious picture. Indeed, if I look at the test probe, I don't see a function but an instruction to move the contents of memory address 42 from memory into register 19. I can draw a diagram of a Turing machine in a few minutes, not so with the lambda calculus. The equivalence is only mathematical, and that cuts both ways. There's no way to write a functional version of The Art of Computer Programming because mathematical equations don't have running times.

[discreteevent]

I think you hot the mail on the head there. That the delta between mathematics and programming is time. Lee Smolin makes a similar case for physics.

[seanmcdirmid]

One can achieve commutativity and idempotency in a side effect based language as well...but one has to redo the programming model to achieve it:

http://research.microsoft.com/pubs/211297/managedtime.pdf