Jump to content

Image of the Day

#QuestOfDungeons is an old-fashioned dungeon crawler. #ScreenshotSaturday  #PS4share

https://t.co/1mztLegxeN https://t.co/DpYimg3MZb
IOTD | Top Screenshots

The latest, straight to your Inbox.

Subscribe to GameDev.net's newsletters to receive the latest updates and exclusive content.

Sign up now

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

4: Adsense

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
8 replies to this topic

#1 nimrodson   Members   


Posted 28 March 2013 - 09:29 PM



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?



#2 Steve_Segreto   Members   


Posted 28 March 2013 - 10:29 PM

In computer sciencefunctional programming is a programming paradigm that treats computation as the evaluation of mathematical functions and avoids state and mutable data.




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 by Steve_Segreto, 28 March 2013 - 10:30 PM.

#3 nimrodson   Members   


Posted 29 March 2013 - 10:19 AM

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. 

#4 metsfan   Members   


Posted 29 March 2013 - 10:26 AM

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.

#5 SamLowry   Members   


Posted 29 March 2013 - 10:29 AM


"Functional style" normally refers to "stateless programming", but I've also heard it used to refer to "using higher order functions" (see http://www.cs.kent.ac.uk/people/staff/dat/miranda/whyfp90.pdf).


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).

#6 BCullis   Members   


Posted 29 March 2013 - 12:23 PM

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".

Hazard Pay :: FPS/RTS in SharpDX (gathering dust, retained for... historical purposes)
DeviantArt :: Because right-brain needs love too (also pretty neglected these days)

#7 Nypyren   Members   


Posted 29 March 2013 - 01:37 PM

If you come from an imperative background, it's kind of hard to envision what functional techniques are good for unless you try using them.

I use C#, so the only functional stuff I really use are first class functions and lambdas. For me, the benefit of using these is reduction in the amount of state that I need to manually implement.

For example, let's say I want to filter a collection:

Imperative style:
public List<int> FindPositiveIntegers(List<int> inputs)
  List<int> values = new List<int>();

  foreach (int input in inputs)
    if (input > 0)

  return values;
Functional style:
List<int> values = inputs.Where(x => x > 0).ToList();
In my opinion, the functional case's advantages include:

- The code is shorter, which usually means it's easier to maintain.

- 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.


OOP encapsulates data, Functional style encapsulates code.

Edited by Nypyren, 29 March 2013 - 04:24 PM.

#8 Yrjö P.   Members   


Posted 31 March 2013 - 04:30 AM

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.


I'm "thinking functionally" a lot of the time even when coding C++.

#9 SillyCow   Members   


Posted 01 April 2013 - 04:21 PM

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.

Edited by SillyCow, 01 April 2013 - 04:30 PM.

My browser game: Vitrage - A game of stained glass

My android games : Enemies of the Crown &  Killer Bees

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.