I have had my eye on functional programming languages for a while, but am hesitating to actually get into them. But I think it's about time I at least starting glancing that direction to make sure I'm ready for anything.

I've seen talk of Haskell, F#, Scala, and so on. But I have no clue the differences between the languages and their communities, nor do I particularly care; except in the context of game development.

So, from a game development standpoint, which functional programming language has the most features suited for game programming? For example, are there any functional game development libraries/engines/frameworks or graphics engines for functional languages? Is there a language that handles certain data structures which are commonly used in game development better?

Bottom line: what functional programming language is best for functional game programming, and why?

I believe/hope this question will declare a clear best language therefore I haven't marked it CW despite its subjective tendency.

  • 2
    \$\begingroup\$ "What do you mean, 2D games, or 3D games?" "Huh? I don't know - aieeee " \$\endgroup\$ – Cyclops Jul 28 '10 at 15:41
  • \$\begingroup\$ @Cyclops uh, what? I don't understand... \$\endgroup\$ – Ricket Jul 28 '10 at 17:15
  • \$\begingroup\$ @Ricket, partly it was a request to clarify what type of game you're talking about, 2D or 3D (and maybe real-time or turn-based). Partly it was a Monty-Python joke which obscured the first part. Wups. :) And I do think specifying the type of game, is useful - unless there is a single functional-language that is perfect for everything, then different languages may be better at different things. \$\endgroup\$ – Cyclops Jul 28 '10 at 19:06
  • \$\begingroup\$ I don't believe 2D or 3D impacts a language choice, except by the variety of engines/libraries available for a language. I am personally interested in both 2D and 3D so I wasn't thinking of one or the other when writing this question. But overall, 2D and 3D games share a lot of common systems and data structures (e.g. audio, input, AI, program structure, game loop) and there are many 3D games which could be ported to 2D or vice versa. And yeah I haven't seen Monty Python so that's why I didn't understand it at all. :) \$\endgroup\$ – Ricket Jul 28 '10 at 23:13
  • 1
    \$\begingroup\$ I don't think there's a definite answer about the best language. \$\endgroup\$ – Wei Hu Aug 12 '10 at 19:30

F# being part of Microsofts .net family has access to XNA, which is a fantastic base for building games. A bit of googling turns up some tutorials, videos and articles. The great XNA docs should help as well.

There has been some movement in games for Haskell as well, see here. You'll probably be using openGL bindings.

Since Scala plays in Java land, it integrates with all the available Java engines/bindings, see this SO post.

I think it comes down to preference, while I've only played with Haskell, I'd imagine each functional language has it's own idiosyncrasies. It may be worth whipping up a small test game in each and seeing which one feels better to you.

Like I said I only have minimal Haskell experience, so I can't comment on the best, but these resources should get you started hopefully.

  • 2
    \$\begingroup\$ Between problems with JVMs and the immaturity of the compiler implementation, I've found Scala's performance unacceptable when using a functional style, even though the language itself supports it well. It ends up being about as fast as, say, Python or Ruby, not F# or OCaml. (Scala's speed is competitive for more OO / procedural styles.) \$\endgroup\$ – user744 Jul 28 '10 at 14:35
  • \$\begingroup\$ I actually got an F# project running XNA (that is an empty XNA window with cornflower blue, only the code was F# and not C#. \$\endgroup\$ – RCIX Jul 28 '10 at 16:06

I would say Lisp.

It has been used in games as a scripting language, at Naughty Dog at least (or it was I think), and is a very mature language.

The advantage of Lisp is in deserialization, which is a major part of what we call asset management. Deserializing lisp is trivial, the code and the data are one. This makes it easier to have a file format for assets and behaviors. It's not like you a one in json/xml/yaml/bin and one F# file for AI. You can save everything as s-expressions which is going to simplify the asset pipeline a lot.

  • \$\begingroup\$ TBH i'd recommend against this. Scripting languages are not just for the developer to use; modders will want to mod the game, and there's nothing that will scare them off faster than (()())))()((()). Plus, even as far as functional languages go, Lisp is esoteric. \$\endgroup\$ – RCIX Jul 29 '10 at 0:45
  • 7
    \$\begingroup\$ If scaring off modders is something that worries you, going for a functional language is probably not the right move. \$\endgroup\$ – Paul Wicks Jul 29 '10 at 20:31
  • 3
    \$\begingroup\$ @RCIX & @Joe - Necro powers ACTIVATE. Anyway, Scheme is used as a teaching language. SICP is something like half a CS degree in one book and is used by a bunch of schools (including MIT until recently), and HTDP is a less hardcore introduction. \$\endgroup\$ – Jesse Millikan Feb 15 '11 at 4:03
  • 1
    \$\begingroup\$ @RCIX & Joe indeed. lisp & scheme are the introductory languages at a lot of universities. \$\endgroup\$ – oberhamsi May 26 '11 at 14:12
  • 1
    \$\begingroup\$ Lisp is not something you want to use. Naughty Dog had ONE, single Lisp programmer and when he quit they transitioned all their engine(s) to C++. No idea why an obsolete engine from one company gets dragged out as a shining example all the time =) \$\endgroup\$ – Patrick Hughes Nov 24 '11 at 17:38

After gaining some practical experience with it, I would vote for Clojure - already written one little game in it, and planning to do more.


  • Productivity - Clojure is a dynamic language. It has great features for interactive REPL-style development, for example you can use the REPL to query or alter state inside a running game application instance. Code in Clojure is also often ridiculously concise. I'd guess I am 3-5 times more productive in Clojure than in Java or C#.
  • Impure - while I appreciate the beauty and elegance of pure functional languages like Haskell, game programming is a messy pursuit where pragmatism wins. I want to be able to put side effects in my functions when I need them, and Clojure allows this. Having said that, idiomatic Clojure style is to be purely functional most of the time.
  • Metaprogramming - Clojure's Lisp heritage as a homoiconic language makes it great for metaprogramming / code generation. It's easy to "extend the language" to make your own DSLs or eliminate biolerplate. You could easily use Clojure as it's own game scripting language, and the dynamic code compilation means that your scripts will run just as fast as your core game engine.
  • Access to Java libraries. You can use all the sound / graphics / AI / networking libraries from Java, which is a huge advantage vs. most other functional languages (where you'll have to either write these from scratch or develop a lot of tricky interfacing code). This can be a life-saver.
  • Cross-platform - this comes for free from running on the JVM, but it's a nice bonus.
  • Performance - for a dynamic functional language, Clojure is about as fast as you can get. It is always JIT compiled, never interpreted. with intelligent optimization you can match the speed of pure, low-level Java code in Clojure. For example, you can use Java primitive arrays, or provide type hints to ensure that the compiler produces statically typed function calls in performance-critical code.
  • Concurrency - Clojure has a great model for managing concurrent state, supported by an impressive software transactional memory system. Worth seeing this video for more insights on how this works.

The only time I wouldn't consider Clojure would be if I was writing a state-of-the-art graphically intensive game where you need cutting edge performance (where I still think you need C/C++).


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