John Carmack's keynote at Quakecon 2013 part 4 on HackerTube: recommended by 5 Hacker News commenters across 5 separate months, 2013–2025.
talk · intermediate · evergreen
Part 4 of John Carmack's QuakeCon 2013 keynote, covering OpenGL, functional programming, Haskell, Lisp and Scheme, typing, multithreading, events and garbage collection.
Cited again and again as Carmack's key public statement on functional programming and purity in game development, plus his remarks on garbage collection.
“There's an old video [0] where he talks in-depth about his explorations of functional programming.”
19 Hacker News comments link this video. Each one links back to its thread.
I think it is, and if you don't want to take my word for it, John Carmack thinks the same :) There's an old video [0] where he talks in-depth about his explorations of functional programming. It's perhaps a bit more about Haskell than about SICP, but in it he's also quite enthusiastic about what a veteran programmer can still learn from this book. [0] ▶ this video
in “Why "Structure and Interpretation of Computer Programs" matters (2011)” · View on HN
Excellent read, I still remember a lot of it. There is also the accompanying Quakecon presentation where John Carmack talks at length about all this: ▶ this video
in “Functional programming in C++ (2012)” · View on HN
What you describe above is similar to what Carmack discussed at his QuakeCon keynote several years back when toying with a game engine on Haskell. Very interesting talk, ▶ this video
in “Global Mutable State” · View on HN
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]
in “Elm in Production: 25K Lines Later” · View on HN
Raymond Hettinger's talk about good code reviews -- [link] Carmack's talk about functional programming and Haskell -- ▶ this video Jack Diederich's "Stop Writing Classes" -- [link] All with a good sense of humor.
in “Ask HN: What's your favorite tech talk?” · View on HN
> In practice programmers tend to avoid writing the kind of program where anything can happen. My faith in this presumption dwindles every year. I expect AI to only exacerbate the problem. Since we are on the topic of Carmack, "everything that is syntactically legal that the compiler will accept will eventually wind up in your codebase." [0] [0] ▶ this video
in “John Carmack on mutable variables” · View on HN
> 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
in “Why Rust Is the Future of Game Development” · View on HN
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
in “It's not what programming languages do, it's what they shepherd you to” · View on HN
I have no idea about how Doom Eternal does it, but John Carmack has some ideas on how to parallelize game engines here: ▶ this video
in “It's not what programming languages do, it's what they shepherd you to” · View on HN
▶ this video was Carmack's presentation on an immutable Haskell game engine. Unfortunately, he doesn't go into too much detail. [link] was the previous HN thread about it.
in “Show HN: Angeldust – a fast and efficient video game” · View on HN
According to John Carmack, the acclaimed expert in the field of game programming, "Functional Programming is the Future" - ▶ this video
in “Ask HN: Why do new(ish) programming languages eschew OOP features?” · View on HN
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.
in “Scratch 3.0” · View on HN
My games development experience is quite irrelevant, however Tim Sweeney and John Carmack might know a thing or two about game engines. "The Next Mainstream Programming Languages: A Game Developer's Perspective" by Tim Sweeney [link] [link] "Considering that 8 bit BASICs of the 70s had range checked and garbage collected strings, it is amazing how much damage C has done." John Carmack - [link] Quakecon 2013 keynote section about GC ▶ this video
in “Java's Magic Sauce” · View on HN
Has there been any progress on garbage collection since then? He discusses GC in games starting here: ▶ this video
in “John Carmack on Functional Programming (2013) [video]” · View on HN
John Carmack thinks there is potential in Haskell or other functional languages for game dev, so much so that he ported Wolfenstein 3D to Haskell as a summer project. I think he talks about in in this QuakeCon 2013 segment: ▶ this video
in “Why I Write Games in C” · View on HN
From my perspective the Haskell community is fairly active and growing. At the moment #haskell has 1100 users tying #python and easily beating out ##c, #c++, #clojure, #lisp, #java, #javascript, and #ruby on Freenode. John Carmack is exploring functional programming[0], and this is Randall Munroe's second functional programming comic in recent weeks. [0]: ▶ this video [1]: [link]
in “Xkcd: Haskell” · View on HN
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
in “The PC is not dead, we just don't need new ones” · View on HN
Google cache: [link] The article is essentially just a link to the fourth part of his keynote at Quakecon ( ▶ this video )
in “John Carmack: Thoughts on Haskell [video]” · View on HN
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
in “What Programming a Game in 48 Hours Taught Me About Programming Games” · View on HN