John Carmack's keynote at Quakecon 2013 part 4

The use of monads is a side-effect (ha!) of committing to purity throughout a language, and that's what FP is being equated to: pure statically-typed FP. (You can argue about how justified that is, of course. I'm not going into that, but you might want to see what John Carmack has to say[0]. No, he doesn't end by saying "we should all convert to the church of Haskell now", but he does talk about how large-scale game programming refactors are made easier when you're working with no (or very disciplined) side effects.) Monads are not the only way to deal with effects while keeping purity, although they were the first discovered and so on: algebraic effect systems as in Koka[1] (and as simulated in Idris or PureScript) are another alternative. Koka infers effects, so it's probably easier for a C-family programmer to pick up (I know little about it, though). [0]: [this video] [1]: [link]

It depends on which type of games you're talking about. AAA game engines are still all about performance and tight memory budgets due to the nature of the platforms they're developing on - consoles and PCs. Hence the aversion to garbage collected languages, although higher level languages usually make it in the engines as scripting languages for game logic: UnrealScript for UDK, C# and UnityScript for Unity, Lua for CryEngine... The industry is traditionally oriented towards C++ and imperative / OO languages, but there's a lot of potential for functional languages in the "embedded scripting" area. In his 2013 QuakeCon keynote [1], John Carmack talks a bit about his experience with functional languages, and how, for example, Scheme could be an ideal candidate as an embedded scripting language. As far as smaller teams are concerned, and especially indie development, there is a lot of potential for OCaml, Clojure and other functional languages. Many mobile and indie dev teams already use a heck lot of C#, Python, Java and other specialized tools like Haxe, ActionScript. But all these languages have well liked and mature frameworks geared towards game development (XNA / MonoGame, PyGame, OpenFL, libgdx, ...), which is maybe what Clojure and OCaml are missing right now. [1] [this video]

Backend devs can probably use more computer resources, particularly cores and RAM. We want to simulate whole clusters on our dev machines and instrument them with tools like Ansible and Docker, and then deploy multiple (fairly heavyweight) processes like JVMs to them. But yeah, 4 (fast) cores and 16GB of RAM is available in a laptop these days, along with an SSD and the best display you can buy, for $3k. (Of course I'm speaking of the MBPr). Games can always use more resources. AFAIK there is still a lot of progress being made with GPUs. 60fps on a 4K display will be a good benchmark. The funny thing is that GPU makers have taken to literally just renaming and repackaging their old GPUs, e.g. the R9.[1] As for the game itself, there is a looming revolution in gaming when Carmack (or someone equally genius-y) really figures out how to coordinate multiple cores for gaming.[2] But yeah, most everything else runs fine on machines from 2006 and on, including most development tasks. That's why Intel in particular has been focused more on efficiency than power. [1] Tom's Hardware R9 review: [link] [2] Carmack at QuakeCon talking about functional programming (Haskell!) for games and multi-core issues: [this video]

John Carmack has mentioned that he uses a visual Lisp environment on iPad. Scheme-based, iirc. It's somewhere in here, I think (but alas I'm not up to listening again through half an hour of the old lady voice): [this video] I feel like marrying Lisp's meta-programmable DSLs to an easy visual environment is the ultimate cosmic dream of 'domain-centered' programming and customization for non-coders―but it also seems to me that Lisp is rather text-based, trading a readymade set of operations picked in the interface for infinite extendability through text. So I'm not sure if a visual Lisp is any convenient to use. Also, for me the immediate downside of the Lisp environment in question is that it's only available for iPad.

Reasoning about code requires reasoning about relevant state. On the one extreme, you have pure functional programming, where all state is passed in and returned out - all relevant state is explicit and "obvious". On the other extreme, you might use global state for everything - relevant state requires diving into all your code. This sounds unthinkable in the modern era, but similar styles aren't entirely uncommon in sufficiently old codebases with codebases that didn't really bother to use the stack. This is part of the reason why memory corruption bugs can be so insidious in large codebases - if anything in your codebase could've corrupted that bit of memory, and your codebase is millions of lines of code, you have a large haystack to find your bugs in, and your struggle will be to narrow down the relevant code to figure out where the bug actually is. This isn't hypothetical - I've had system UI switch to Chinese because of a use-after-free bug relating to gamepad use in other people's code, for example. (EDIT: Just to be clear - globals don't particularly exacerbate memory corruption issues, I'm just drawing some parallels between the difficulty in reasoning about global state and the difficulty in debugging memory corruption bugs.) > Game development John Carmack on the subject, praising nice and self contained functional code and at some point mentioning some of the horrible global flag driven messes that have caused problems in their codebase, mirroring my own experienc

> Lack of safety is a feature in game development, Bullshit. How many games have had releases delayed and major wrenches thrown into marketing plans because of progress ruining heisenbugs? How many failed certification passes from banal data races and other undefined behavior? We trap UI in actionscript or javascript, and gameplay programmers in other scripting languages - perhaps python or lua - for faster iteration times, hot reloading, and safety . Because it's difficult enough to keep the build stable when it's merely all the engine programmers who should know better screwing things up with C++. This results in large messes of poorly performing, poorly optimized, garbage-collector laden code that Rust would handle much faster. We're leaving lots of performance on the table, often for little other purpouse than "safety". Console first day patches may have taken off some of the pressure for getting the first release right, but handhelds aren't always online and still have a pretty high bar. > the optimizations required are typically unorthodox Rust's `unsafe` keyword and intrinsics let you do all the unaligned intrinsic-laden data-racey technically-undefined-behavior micro-optimizations you might want to do in C++ in Rust just fine. It'll hopefully trigger a more stringent code review and force you to justify your pile of bugs, but that's a good thing. Or you can skip the code review if your entire company really disagrees. > a super strict language slows development down C