Legendary programmer John Carmack discusses his work on games like Doom and Quake, VR headsets, and rockets. He's cautious on the market: Meta's $10B+ annual VR/AR bet on the 'metaverse' could be a bubble if lightweight glasses don't arrive in 5-10 years. Key mentions: Meta (huge investment, high risk), OpenAI's GPT-3 (impressive but not AGI), and DeepMind's AlphaFold 2 (breakthrough but not AGI either).
John Carmack discussed the core themes of his career on the Lex Fridman podcast: from co-founding id Software (leading the development of revolutionary games such as Commander Keen, Wolfenstein 3D, Doom, and Quake) to serving as CTO of Oculus VR (advancing the technological path of virtual reality a
John Carmack is a legendary programmer, co-founder of id Software (leading the development of revolutionary games such as Wolfenstein 3D, Doom, and Quake), founder of Armadillo Aerospace, and former CTO of Oculus VR. The main thread of this episode is Carmack’s deep retrospective and forward-looking judgments on key areas of his career: programming, game engines, VR/AR, the metaverse, AGI, and rocket technology. The most weighty judgment of the entire episode: Carmack believes that the current deep learning paradigm itself is insufficient to achieve AGI, requiring a fundamentally new, system-level innovation capable of handling "open-ended" problems, not merely larger models and more data.
Carmack believes the core appeal of programming lies in the "magical feeling" of creating complex systems from scratch, and that every breakthrough in game engines stems from the pursuit of performance limits.
Carmack believes VR/AR is the physical foundation for realizing the "metaverse" vision, but current devices still have vast room for improvement in weight, field of view, resolution, input latency, and social interaction.
Carmack believes current AI methods based on large-scale neural networks and reinforcement learning, while performing well on specific tasks, cannot solve the "open-ended" problems required for AGI.
1. Handling "unknown unknowns": Reasoning autonomously in entirely novel situations outside the training data.
2. Possessing a "world model": Learning not just input-output mappings but the causal structure of the world.
3. Achieving "continual learning": Absorbing new knowledge without forgetting old knowledge.
Carmack believes his experience at Armadillo Aerospace gave him a deep understanding of the importance of "systems engineering"—that "making all subsystems work together" is more important than "extreme performance of individual components."
| Position | Guest Attitude | Key Data |
|---|---|---|
| Meta (formerly Facebook) | Risk Warning | Annual VR/AR investment > $10 billion; if hardware does not reach "glasses form factor" in 5-10 years, metaverse may fail |
| OpenAI (GPT-3) | Neutral (technically impressive, but insufficient for AGI) | 175 billion parameters |
| DeepMind (AlphaFold 2) | Neutral (technically impressive, but insufficient for AGI) | Breakthrough in protein structure prediction |
| Armadillo Aerospace | Historical Review (defunct) | Total investment < $20 million; Stig rocket achieved 1 km VTVL |
1. Carmack believes the "magic" of programming lies in using algorithms to break hardware limits: Doom's BSP tree and precomputed lighting enabled 35 fps 3D rendering on a 1993 PC, while competitors achieved only 10-15 fps.
2. The ultimate goal of VR/AR is the "visual Turing test": Requires 8K resolution per eye, 140-degree field of view, < 5 ms latency, and device weight < 100 grams for all-day wear.
3. Carmack is cautious about the "metaverse": If no AR glasses weighing < 150 grams appear by 2027, the metaverse will be a marketing bubble.
4. AGI requires transcending the "super parrot" paradigm: Current AI lacks causal reasoning and world models, unable to handle "unknown unknowns."
5. Carmack proposes a counterintuitive path to AGI: AGI might not come from making AI smarter, but from making AI "dumber"—focused on one core problem, from which general capabilities emerge.
6. Rocket development is 90% systems engineering, 10% performance: Armadillo's failure was not due to poor engines, but insufficient system reliability.
7. Carmack's "one data structure solves multiple problems" philosophy: Doom's BSP tree was used simultaneously for rendering, collision detection, and AI pathfinding—a model of efficiency.
8. A reusable orbital rocket requires at least $1 billion and 5 years: Armadillo's < $20 million investment demonstrated the limits of the "amateur" model.
Carmack's discussion of programming languages reveals an underestimated phenomenon in the technology ecosystem: the deep impact of path dependence. He notes that Turbo Pascal's compilation speed was 10-20 times faster than mainstream compilers of the time. This efficiency advantage could have altered the trajectory of programming language development. However, C ultimately prevailed due to the inertia of the Unix ecosystem—a case not purely of technical merit, but of ecosystem lock-in effects.
Key Data Comparison:
| Feature | Turbo Pascal | C Language |
|---|---|---|
| Compilation Speed | Very fast (single-pass compilation) | Slower (multi-pass optimization) |
| Type Safety | Supports range-checked arrays | No built-in bounds checking |
| Memory Management | Manual (same as C) | Manual |
| Ecosystem | Limited (Borland-dominated) | Vast (Unix/Linux) |
| Security Vulnerability Tendency | Lower (optional checks) | Higher (buffer overflows common) |
Carmack points out that if the programming world had taken the Pascal route, many of C's security problems might have been avoided—a thought-provoking "technological branching point."
Carmack mentions seeing a debate on Twitter this morning among veteran game developers about the pros and cons of garbage collection, revealing the tension between engineering practice and theoretical ideals:
Carmack's stance is pragmatic: over 99% of software should use garbage collection, with manual management reserved only for the most stringent real-time systems. This "choose the tool for the scenario" mindset aligns with his methodology in game development of "choosing algorithms based on hardware constraints."
Carmack's analogy for JavaScript is highly insightful—comparing JavaScript to biological evolution:
> "It's like this huge mess. If things don't work, they naturally die off; if they are useful to people, they naturally survive."
This analogy reveals several key points:
1. Efficiency is not the only optimization goal: JavaScript's "deep stack" (from one line of code to browser rendering) is extremely complex, yet it still works.
2. Scale creates possibilities: The ecosystem of billions of devices allows a "trial-and-error, survival" evolutionary mechanism.
3. Local optimum vs. global optimum: JavaScript may not be optimal on any single metric, but it wins on the ultimate metric of "survival."
Carmack also offers a thought-provoking view: If you can accept performance 1000 times slower than the "speed of light," many problems become solvable. This is consistent with his early approach in game development of "using clever tricks to bypass hardware limitations."
Carmack’s attitude toward debuggers stands in stark contrast to mainstream “Unix culture”:
> “Anyone who thinks ‘just read the code and think about it’ is crazy. You can’t even read all the code in a large system.”
He puts forward a key point: the debugger is not just a tool for finding bugs, but an experimental platform for understanding systems. In game development culture, programmers “even start the debugger before they know there’s a problem.” This preventive usage differs sharply from the practice of “only using GDB when all else fails.”
Comparison of Two Debugging Cultures:
| Dimension | Game Development Culture | Unix/Silicon Valley Culture |
|---|---|---|
| Debugger usage | Daily tool, actively used | Last resort, passively used |
| IDE preference | Visual Studio, etc. | Emacs/Vim |
| Debugging timing | Step through immediately after writing code | Only used when encountering incomprehensible bugs |
| Efficiency impact | High (instant feedback) | Low (compile-log cycle) |
Carmack describes a highly illuminating experience: when he thoroughly examined id Software’s codebase with code analysis tools, even the code widely regarded as the most robust was riddled with errors.
> “Anything that is syntactically allowed by the language will eventually appear if the codebase is large enough.”
This discovery led to a methodological shift: from relying on programmer goodwill to relying on automated tools. He specifically emphasizes:
Carmack notes that 10–20% of his private code consists of assertions, which serve not only as debugging tools but also as encoding of design intent:
> “This code was originally written under this worldview, under this set of constraints. If something breaks, it means you need to rethink the initial assumptions.”
This philosophy of “assertions as documentation” aligns with his practice in game development of “fixed array size + assertions”—capturing environmental changes through hard-coded limits, rather than allowing the system to adapt indefinitely.
Carmack introduced a highly original concept: the "Turing completeness" of game design. The blocky world of Wolfenstein 3D could not accommodate true creative diversity, while Doom’s arbitrary-angle walls and variable floor/ceiling heights crossed this threshold.
Design Space Comparison:
| Game | Design Freedom | Community Creations | Creative Longevity |
|---|---|---|---|
| Wolfenstein 3D | Low (90-degree blocks) | Limited | Low (quickly exhausted) |
| Doom | Medium (arbitrary angles + heights) | Thousands of levels | High (new creations still emerging) |
| Minecraft | High (1/8-scale voxels) | Infinite | Extremely high |
Carmack noted that technology licenses after Wolfenstein produced no impactful works, while the Doom community continues to create new content to this day—demonstrating the existence of a "design space tipping point."
Carmack’s reflection on Quake’s development is one of the most valuable lessons in the entire book:
> "If I could go back and tell my younger self, I would say: split these innovations into two phases, make them two separate games."
His proposed split:
The core of this lesson is: do not try to solve all problems in a single iteration. Quake simultaneously advanced:
1. A brand-new 3D rendering engine
2. A client-server network architecture
3. Programmable game logic (QuakeC)
4. Lightmap surface caching
If split into two steps, a game that "looks like Doom but feels like Quake" could have been released eight months earlier, followed by a full 3D engine six months later.
Carmack repeatedly emphasizes a seemingly contradictory point: true innovation often comes from "pretending."
> "Doom had a lot of smoke and mirrors—people thought it was more powerful than it actually was, but we chose the right smoke and mirrors to deploy."
The essence of this approach is: sacrificing certain capabilities to greatly enhance others. In Doom, the ability to tilt walls and create bridges was sacrificed in exchange for extremely high rendering speed and a smooth experience.
This aligns with his views on AGI: "smoke and mirrors" may be the path to true intelligence—first pretend to understand, then truly understand.
Carmack’s core view on VR development is: Do not invent fictional users; focus on real users.
> "Don’t create Alice, Bob, and Charlie to fit your desired market segmentation matrix. When you already have real users, imagining users is a mistake."
The concept of the "value gradient" he proposed is worth pondering:
Carmack’s analysis of Beat Saber demonstrates a systematic approach to reverse-engineering success:
1. Maximizing controller advantages: Always held, never colliding
2. Minimizing comfort issues: Standing still, objects flying toward the user
3. Audio advantages: VR isolates the outside world, enhancing the audio experience
4. Time fragmentation: 3–4 minute gameplay windows
5. Fitness value: An unexpected but powerful added feature
This analysis reveals a key insight: Successful VR applications are not the "best" experiences, but those that "best match VR’s characteristics".
Carmack’s criticism of Meta’s internal efficiency is blunt:
> "The $1 billion figure makes me feel sick to my stomach, but that’s how they demonstrate commitment."
Issues he observed:
Yet he acknowledges the advantages of large companies: Meta’s sustained investment in VR/AR is unmatched by companies like Google, which would readily cancel projects.
Carmack proposes a specific milestone definition for AGI:
> "If we reach a point where you have a learning-disabled toddler—a child with special needs—who can still interact with their favorite TV shows and video games, and can be trained and learn in a human-like way. At that point, you can deploy an army of engineers, cognitive scientists, and education experts."
Key elements of this definition:
1. Continuous learning: Not one-time training, but lifelong learning
2. Task-agnostic: Not optimized for a specific task
3. Educability: Capable of learning through curricula
4. Social interaction: Able to engage in meaningful interaction with humans
Carmack’s rejection of a "fast takeoff" (FOOM) is grounded in engineering realities:
1. Hardware constraints: AGI requires thousands of GPUs, which are not freely available resources
2. Data center construction cycles: These take years
3. Network bandwidth limitations: Even with perfect hacking skills, one cannot exceed TCP connection speeds
4. Specialized architecture: AGI systems are optimized for specific chips and interconnects and cannot be arbitrarily migrated
> "Even if you had perfect hacking abilities, the idea of instantly taking over the world is simply unrealistic."
Carmack’s core assumption is that AGI will require tens of thousands of lines of code, not millions.
This assumption is based on:
1. The simplicity of the brain: The human genome is only about 50MB, and brain structure is relatively simple
2. The number of key insights: He believes there are fewer than six key insights, each of which could be written on the back of an envelope
3. The treasure trove of existing literature: The "precursors" to key steps may already exist in the current literature
Carmack takes a very pragmatic view of consciousness and death:
> "Most debates about consciousness are not very valuable. Consciousness is a feeling that arises when the brain is functioning."
On death as a constraint:
Carmack’s defense of work intensity is noteworthy:
> "A 40-hour work week is basically a part-time job. If you are truly committed and doing what you believe is important, more work gets more done."
His "asteroid impact" thought experiment:
Key Distinction:
Carmack admits he has never experienced "burnout":
> "I have never reached the point where I thought, 'I just don’t care about this anymore; I don’t want to do this anymore.'"
He attributes this to:
1. Multi-project flexibility: The ability to switch between different tasks
2. Sense of progress: As long as momentum is maintained, obstacles can be overcome
3. Optimism: A belief that problems are solvable
Carmack’s core advice to young people is "weaponized curiosity":
> "You can deploy your curiosity to discover things that are useful and valuable but not immediately obvious."
Specific methods:
1. Deep understanding: Not just surface-level competence, but true comprehension
2. Cross-layer cognition: From hardware to software to system architecture
3. Opportunity awareness: Prepare tools, observe changes, and seek deployment opportunities
| Feature | Wolfenstein 3D | Doom | Quake |
|---|---|---|---|
| Rendering Method | Ray Casting | BSP Tree + Surface Caching | Full 3D Polygons |
| Degrees of Freedom | 4 (Movement + Turning) | 4 (No Pitch/Roll) | 6 (Full) |
| Map Structure | 90-Degree Blocky | Arbitrary Angles + Heights | Fully 3D |
| Networking | None | Peer-to-Peer | Client-Server |
| Programmability | None | WAD File Replacement | QuakeC Language |
| Design Space | Limited | Turing Complete | Fully Open |
| Language | Development Efficiency | Runtime Efficiency | Learning Curve | Suitable Scenarios |
|---|---|---|---|---|
| Python | Very High | Very Low (Loops 1000x Slower) | Low | AI/ML Prototyping |
| C++ | Medium | High | High | Systems Programming |
| C | Low | Very High | Medium | Low-Level/Embedded |
| JavaScript | High | Medium | Low | Web/UI |
| Go | High | High | Low | Server-Side |
| Lisp | Medium | Medium | High | Metaprogramming |
| Dimension | Startup | Large Company (Meta/Google) |
|---|---|---|
| Decision Speed | Fast | Slow (Cross-Functional Meetings) |
| Resource Availability | Limited | Nearly Unlimited |
| Risk Tolerance | High | Low (Political Risk) |
| Talent Density | High (Self-Selected) | High (But Diluted) |
| Efficiency | High | Low (1/10) |
| Persistence | Low (Prone to Failure) | High (Sustained Investment) |
Due to space constraints, the following topics were not explored in depth in this analysis:
1. Carmack's "Inverse Square Root" Misconception: He clarified that it was not his invention, but the internet remains unconvinced
2. .plan Files as Early Blogs: The evolution from work logs to philosophical essays
3. Relationship with John Romero: The complete narrative from collaboration to divergence and reconciliation
4. Lessons from Armadillo Aerospace: Why "limited commitment" led to failure
5. The Economics of Nuclear Fission: Why fuel costs account for only 2% of electricity
6. Self-Supervised Learning and AGI: Carmack's critique of the current paradigm
These topics warrant separate exploration in future analyses.