4 ms·

> An open question is "Is being purely functional, even excepting I/O, worthwhile?" Or is it, as was suggested to me via email earlier this year, the equivalent

> An open question is "Is being purely functional, even excepting I/O, worthwhile?" Or is it, as was suggested to me via email earlier this year, the equivalent of writing a novel without using the letter 'e'? This is a great question. I've been playing with pure functional programming, and I also noticed that applying it to video games is very hard. In other areas, FP provides many advantages such as testability and safe parallel execution. But for simple games these are not that useful. Simple games seem very well suited for the imperative, global state model. There is one aspect that might make FP worth it for games and it's interactive programming. The immediate feedback loop described by Bret Victor [1], with the possibility of going back and forth in time is easier to achieve with a pure functional approach. The Elm debugger [2] is an implementation of this concept, using hot swapping and functional reactive programming it's possible to design games interactively in a very unique way that it's hardly achieved with the traditional imperative approach. [1] https://www.youtube.com/watch?v=PUv66718DII https://www.youtube.com/watch?v=PUv66718DII [2] http://debug.elm-lang.org/ http://debug.elm-lang.org/

Peaker 10y ago
> But for simple games these are not that useful. Simple games seem very well suited for the imperative, global state model. I think this indicates a bias -- resulting from years of programming games in these models. I think pure FP in the form of FRP is a far better match for simple games than the imperative, global state model.
the_af 10y ago
> But for simple games these are not that useful. Simple games seem very well suited for the imperative, global state model. Could you elaborate? I think this is one of those things we "know" which isn't necessarily so. Simple sprite-based games can be written using purely functional techniques (see: https://github.com/nikki-and-the-robots/nikki https://github.com/nikki-and-the-robots/nikki). It's just that it's not common to use FP languages for this.
- ceronman 10y ago
  Yeah, I know you can develop games in a purely functional fashion. My point what is the advantage of doing so, given that most resources are developed for an imperative way. I think the interactive approach taken by Elm is a very good advantage of FP for games.
baggers 10y ago
A few notes: - Elm dropped frp [0] - Even in it's older frp incarnation, elm didnt allow changing of the flow graph (sorry I cant remember the correct elm term for this) while the program ran [1], making it hard to say this would be an ideal way to go for true 'interactive coding' for games. To clarify my opinion I would like to add that I am assuming an ideal of 'interactive game coding' where one would start a GL context & repl session at the start of the day and make the game whilst never closing the session or killing the context. The OP limited himself to retrogames which is a wise move for exploring this topic, _one_ of the things that makes writing modern games hard is the extent to which you are pushing what the hardware can do. It is normal to be required to really be strict about what happens when in each frame and it's not possible to do this if, part-way through rendering you have to process events coming from some input thread that has no idea about the context your program is in. Lastly I would add that your program itself is state. Interactive programming requires you to create and remove functions from your running program and bugs particular to doing this can occur (some object has a reference to a version of a function you have removed etc etc). Unless we move to a point where our code (compiled & text) live in a some persistant data-structure that allows rollback in some meaningful way I find it hard to imagine _real_ functional interactive programming. This is a cool topic and ripe for discussion and progress, but just dropping in interactive programming does not in itself make game coding easier. However it is a pile of fun. [0] http://elm-lang.org/blog/farewell-to-frp http://elm-lang.org/blog/farewell-to-frp [1] https://www.youtube.com/watch?v=Agu6jipKfYw https://www.youtube.com/watch?v=Agu6jipKfYw

Peaker 10y ago

> But for simple games these are not that useful. Simple games seem very well suited for the imperative, global state model. I think this indicates a bias -- resulting from years of programming games in these models. I think pure FP in the form of FRP is a far better match for simple games than the imperative, global state model.

the_af 10y ago

> But for simple games these are not that useful. Simple games seem very well suited for the imperative, global state model. Could you elaborate? I think this is one of those things we "know" which isn't necessarily so. Simple sprite-based games can be written using purely functional techniques (see: https://github.com/nikki-and-the-robots/nikki https://github.com/nikki-and-the-robots/nikki). It's just that it's not common to use FP languages for this.

ceronman 10y ago
Yeah, I know you can develop games in a purely functional fashion. My point what is the advantage of doing so, given that most resources are developed for an imperative way. I think the interactive approach taken by Elm is a very good advantage of FP for games.

baggers 10y ago

A few notes: - Elm dropped frp [0] - Even in it's older frp incarnation, elm didnt allow changing of the flow graph (sorry I cant remember the correct elm term for this) while the program ran [1], making it hard to say this would be an ideal way to go for true 'interactive coding' for games. To clarify my opinion I would like to add that I am assuming an ideal of 'interactive game coding' where one would start a GL context & repl session at the start of the day and make the game whilst never closing the session or killing the context. The OP limited himself to retrogames which is a wise move for exploring this topic, _one_ of the things that makes writing modern games hard is the extent to which you are pushing what the hardware can do. It is normal to be required to really be strict about what happens when in each frame and it's not possible to do this if, part-way through rendering you have to process events coming from some input thread that has no idea about the context your program is in. Lastly I would add that your program itself is state. Interactive programming requires you to create and remove functions from your running program and bugs particular to doing this can occur (some object has a reference to a version of a function you have removed etc etc). Unless we move to a point where our code (compiled & text) live in a some persistant data-structure that allows rollback in some meaningful way I find it hard to imagine _real_ functional interactive programming. This is a cool topic and ripe for discussion and progress, but just dropping in interactive programming does not in itself make game coding easier. However it is a pile of fun. [0] http://elm-lang.org/blog/farewell-to-frp http://elm-lang.org/blog/farewell-to-frp [1] https://www.youtube.com/watch?v=Agu6jipKfYw https://www.youtube.com/watch?v=Agu6jipKfYw