Hacker News Reader

Comment by stephth | Hacker News Reader

I do like the idea of functional programming as a paradigm - that can be used in any language - and dodged when needed - much better than pure functional programming/languages. As a game designer, with so many state-dependent parts, and with so many refactoring iterations that come along with designing a game from the ground up, too much functional code would become a burden. The approach suggested here on the other hand - trying using to use FP as much as reasonable - allows me to benefit with FP when possible while maintaing agility.

In a language like c++, what would be an elegant naming convention to differentiate between pure functions and others?

View on HN

This is definitely coming from someone who has never written a stateful functional program. You have to write things pretty differently but it’s usually better than it’s imperative counterpart. It works just fine, trust me.

You may be interested in James Hague's "Purely Functional Retrogames" (http://prog21.dadgum.com/23.html) series of posts. He's written several about the hurdles and benefits of using FP for game programming. (He's using Erlang.)

He basically seems to have come to the conclusion (even moreso in more recent posts) that functional languages are not the way to go, so I'm not sure it's the best starting point unless that's where you want to end up.

Not really - he's very positive about Erlang, for example. He thinks that going for absolute functional purity is not worth the effort, but that mostly functional (or functional-by-default) is very practical. I tend to agree.

His criticism is pretty fair, too - far more substance than a dozen "oh wow, look at how small quicksort / fibonacci is" blog posts.

I've read some of James Hague's more recent posts on FP, and I got the same idea from them than @radarsat1. But more importantly, until I see someone adopting FP for the game logic in a innovative game - re-writing Pacman doesn't have the challenges of programming something while inventing it - and concluding that it is beneficial, more productive game design with FP is an unproven idea. See @eru's answer with the Tim Sweeney talk.

You might be interested in the talk "The Next Mainstream Programming Language: A Game Developer’s Perspective" [0]. The authors argue that functional programming is the future of game programming.

[0] http://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced-...

Good read, thanks. But in practice, with all its problems, C++ has been proven to work over and over, and the author's - Tim Sweeney - work is proof of that. Today, 6 years after this talk, has anyone successfully made a commercial game with the game logic built with FP, and if so, was it more productive than the former approach? I'm not saying the lack of examples prove it's not beneficial, but believing it is, is still only a guess.

FP languages in games:

- Jax and Daxter (and Crash Bandicoot): http://ynniv.com/blog/2005/12/lisp-in-games-naughty-dogs-jax... - Abuse: http://en.wikipedia.org/wiki/Abuse_(computer_game) - Lua (even though it is not strictly functional) is used quite a bit throughout the game industry.

Of those examples only Jak and Dexter is actually about functional programming in game dev. It's a good example though. But the outcome of using FP didn't turn out that great for them, it did not make them more productive:

A single programmer (who could easily be one of the top ten Lisp programmers in the world) wrote GOAL. While he called his Lisp techniques and programming practices "revolutionary," others referred to them as "code encryption," since only he could understand them.

So we found one example, and it didn't prove FP is beneficial to productivity.

You are right, we need to see more examples of functional programming being used in games. Then we can better tell what effects it has.

Interestingly, you can also say that Cobol has been proven to work for business applications over and over. And people build successful websites with PHP.

> In a language like c++, what would be an elegant naming convention to differentiate between pure functions and others?

D is a bit like C++. And its type system supports pure functions. I don't know if there's a standard naming convention, but D is worth a look.

Reply on news.ycombinator.com