5 ms·

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 l

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.

seanmcdirmid 12y ago
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 http://research.microsoft.com/pubs/211297/managedtime.pdf
brudgers 12y ago
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 12y ago
  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 12y ago
    Only after the learning curve, though. It isn't immediately approachable as an imperative language.
    - the_af 12y ago
      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 12y ago
        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 12y ago
        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.

seanmcdirmid 12y ago

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 http://research.microsoft.com/pubs/211297/managedtime.pdf

brudgers 12y ago

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 12y ago
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 12y ago
  Only after the learning curve, though. It isn't immediately approachable as an imperative language.
  - the_af 12y ago
    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 12y ago
      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 12y ago
        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.