What is functional programming and how can it help us in game developing?

Recommended Posts

I would like to know some opinions about this programming paradigm: It is useful? How much? Could have an important role or participation in game design and/or coding? It is complementary, opposite, or totally uncomparable to OOP?

Using compute shaders is functional programming. Functional programming and associated languages usually map better to hardware (think FPGAs) than software. Come to think of it, any shader is a functional program evaluated simultaneously on blocks of data.

Edited March 29, 2013 by Steve_Segreto

4

Share this post

Link to post

Share on other sites

Using compute shaders is functional programming. Functional programming and associated languages usually map better to hardware (think FPGAs) than software. Come to think of it, any shader is a functional program evaluated simultaneously on blocks of data.

OK, thanks for the tip. But, what happens in a higher abstraction level? Which elements of functional programming could be beneficious in game design?

Newly, thanks.

1

Share this post

Link to post

Share on other sites

For one thing, functional programming typically handles multithreaded situations much better because of the lack of mutable state. As a result, things that you typically would do sequentially, you can spread out among multiple threads, and you can thread by task. Also, the idea of functions being first class citizens can be a useful paradigm when trying to move away from an global event manager model (which I have grown to hate). Just a couple of ideas, there are more.

Stateless programming means that you cannot modify existing data, e.g. once a list is created, you cannot add new elements to it. This is not as useless as it sounds, as you can just create a new list which is equal to the old list with the extra elements added to it. This in turn might seem like a waste of memory, but again, it isn't, as you can reuse parts of old data structures in your new ones, since they are guaranteed never to change anyway.

This approach can have many advantages: it makes reasoning about programs easier, it can be more efficient, etc. Functional style can make using multithreading much easier. Formally, a variable in functional setting can be seen as just something with a value, which does never change. A variable in a stateful setting, however, has a value that changes in time, i.e. there's an extra dimension to take into account. Multithreading can be seen as "your code will run, but you can't know when". In that sense, it is easy to see why functional style simplifies multithreading.

Functional and imperative (= non-functional) style can easily coexist. For example, Haskell is a purely functional language (whereas for example O'Caml has ref cells which introduce state). However, Haskell gets translated to imperative code (due to laziness), so underlying a functional layer lies an imperative one. But, using certain syntactic tricks (monads, do-notation, ...) it is possible to introduce state in Haskell programs, so from functional elements one can build an imperative program.

Same thing in other languages: in java/C#, strings appear immutable to the user, while internally, they probably use state, but it is abstracted away. These purely functional strings are then used in an imperative setting, etc. etc. You can switch between functional and imperative style at will inside one program.

Also related is the expression problem. This has less to do with stateless vs stateful however, but rather as having functions or classes as building blocks. One can distinguish two "dimensions": functionality and cases. Let's take shapes as an example: one can have circles, squares, etc. as cases, and area, circumference, intersection, ... as functionality. An OO language allows you to easily add new cases (i.e. new shapes) by writing a new subclass, and implementing all necessary methods. This does not require you to make changes to existing code. If however you need new functionality, you would have to modify the superclass (Shape), i.e. add extra methods, and implement these in all subclasses.

Functional style can be seen as orthogonal to this. Adding new functionality is trivial: just define a new function, no existing code needs modifications. However, adding a new case requires you to extend the data type definition and adjust all existing functions to deal with this new case.

Technically, it is possible to add extra functionality in OO programs and add new cases in functional programs without modifying existing code, but it can lead to some ugly results, which sometimes bypass the type system (I'm thinking of using instanceof in java, which bypasses some correctness checks (exhaustivity, i.e. making sure that all abstract methods are implemented) done by its type system).

5

Share this post

Link to post

Share on other sites

It has potentially huge applications to self-correcting AI routines (and really the field of AI in general). Depending on your functional language, output from a function can be fed as input right back into the same function. For example: Lisp can rewrite and evaluate its own code, because there's no differentiation between "code" and "data".

- The variable mutation is entirely hidden from the programmer by the LINQ methods. Reducing the number of variables that a programmer has to deal with also means that there are fewer *effective* states that the program can be in (this is a good thing - fewer states means it's easier to prove that it works correctly in those states).

- There is less manual flow control being performed by the programmer. Flow control is another kind of state that a programmer has to consider.

- I can more easily write a function which gets negative numbers instead; In both cases I can copy/paste the whole thing and just change the condition, but in the functional case it's easier because there is less code to maintain.

- The "Where" and "ToList" methods seen here are reusable. They've been proven to work correctly, so the only burden on the programmer is understanding what they do and writing the lambda expression "x => x > 0" inside the Where call. Allowing for reuse of code where *parts of the algorithm itself* are interchangeable is a consistent theme when using functional style.

Share this post

Link to post

Share on other sites

For folks interested in checking out FP, it may be useful to know that a new round of a functional programming basics course has just started at Coursera. The language used is Scala, but you aren't expected to have previous knowledge, and the focus is on general FP concepts as opposed to diving deep into the languge. (Though it's a good opportunity to get started with Scala as well; the lecturer is Martin Odersky, the author of the language.)

FP-oriented thinking is useful even for the hobbyist because it leads to more expressive code, cutting down development time, errors and maintenance. And it has become critical for high performance. Single cores stopped getting significantly faster a long time ago, and concurrency and parallelism are now the major bottleneck for most interesting things. FP helps you survive in an environment with those two phenomena.

Share this post

Link to post

Share on other sites

The most useful functional programming in games I've seen recently is Javascript + HTML5.

JavaScript is both OOP and Functional.

Using it functionally is the best way to get things done, (especially IO).

There are many other cool things about functional programming, but this is the only way I can justify it to a hobbyist programmer.

Aside from this, you should learn & use functional programming at least once just because it's very interesting. It will lead you to new design patterns. Especially where asynchronous tasks are involved.