I've been told in previous questions that functional programming languages are unsuited for dynamic systems such as a physics engine, mainly because it's costly to mutate objects. How realistic is this statement, and why?

  • 4
    You may find github.com/linneman/particles-clj interesting. Due to the functional programming style the computational load will be distributed over the available CPU cores which can dramatically increase processing speed in some cases
    – user40980
    Apr 16, 2013 at 15:15
  • 2
    Who told you they were unsuitable? Link to answer/comment?
    – Andres F.
    Apr 16, 2013 at 15:39
  • 7
    @Dokkat: I'm skeptical that the commenter there knows much of anything about functional programming, to be very honest. I'd take it with a large grain of salt. Apr 16, 2013 at 17:04
  • 6
    In addition, I'd also disregard the answer that starts with "A pure functional approach is not a good fit for games ..." unless the author proves he has actually tried writing a functional program. Otherwise, he is just guessing what he thinks the problems may be.
    – Andres F.
    Apr 16, 2013 at 17:09
  • 1
    @Dokkat game development has additional constraints rather than just a particle simulator and physics engine (which can fit rather nicely into functional programming) -- run time performance being key for game development (and more important than the physics itself at times). The physics engine for a mining company predicting blasts asks accuracy more than performance. With functional programming, more performance can be obtained more easily by throwing more hardware at it (something that game engines can't do).
    – user40980
    Apr 16, 2013 at 17:13

2 Answers 2


Both Haskell and Clojure allow actual mutability, so that's a non-issue to start with.

Beyond that, if your "mutable" data consists of intermediate values being updated incrementally as part of some larger computation, you may not even need mutability to be efficient! For example, there's ongoing research in Haskell regarding a technique called stream fusion, where the compiler fuses processing loops, data producers, and data consumers to eliminate intermediate data structures entirely.

The main issue with Haskell here is laziness--in a number-crunching program where you have a lot of input data and a lot of output data and all of it is important, laziness does you very few favors but still imposes some overhead. That's not to say you can't write programs like that in Haskell (people do, in fact) but it's not playing to the language's strengths and you need to have a better understanding of the evaluation model to get the performance you want.

That said, heavy number-crunching doesn't play to the strengths of the JVM, either. That sort of program is why FORTRAN is still around.

  • 1
    worth a note: the upcoming 8.0 version of GHC will support strict evaluation mode per module. Nov 3, 2015 at 0:26

I can't speak for Clojure, but I can say Haskell has a lot of very highly tuned IO packages available that will allow all the mutation you could want.

Here's an answer to a question I wrote where someone details the 3 most common ones and regards their performance: https://stackoverflow.com/questions/15439966/when-why-use-an-mvar-over-a-tvar/15440286#15440286

You can also see here a simple graph showing performance metrics of a haskell web server called Warp, which is a highly IO intensive application.

There is a lot of confusion about this regarding Haskell, the truth is it has fantastic IO facilities with many packages on hackage for using IO in a great many different ways, many of which have been highly tuned. The reason people presume this isn't the case is because Haskell goes to great lengths to separate IO from everything else, but that has no effect on the performance characteristics.

Now to speak about performance characteristics however, the reason people recognize it as having poor performance is due to the lazy evaluation causing it to behave in ways that aren't always intuitive. This is however something you have to worry about considerably less when you start working in an IO context doing destructive updates such as in a system you are referring to. Further people tend to find that when they are having performance troubles, the built in facilities to instrument and identify where resources are going help a great deal.

Another monad worth looking at for a system like you describe would be the ST monad which is specifically for destructive updates done by very small IO calls giving it great performance.

Sorry I really can't speak to Clojure, hopefully someone else can give details there.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.