John Carmack is a legendary programmer, co-founder of id Software, and lead programmer of many revolutionary video games including Wolfenstein 3D, Doom, Quake, and the Commander Keen series. He is also the founder of Armadillo Aerospace, and for many years the CTO of Oculus VR. Please support this podcast by checking out our sponsors:
- InsideTracker: https://insidetracker.com/lex to get 20% off
- Indeed: https://indeed.com/lex to get $75 credit
- Blinkist: https://blinkist.com/lex and use code LEX to get 25% off premium
- Eight Sleep: https://www.eightsleep.com/lex and use code LEX to get special savings
- Athletic Greens: https://athleticgreens.com/lex and use code LEX to get 1 month of fish oil

EPISODE LINKS:
John's Twitter: https://twitter.com/ID_AA_Carmack
Books mentioned:
Hackers: Heroes of the Computer Revolution: https://amzn.to/3SkNZER
Game Engine Black Book Wolfenstein 3D: https://amzn.to/3QlOqg8

PODCAST INFO:
Podcast website: https://lexfridman.com/podcast
Apple Podcasts: https://apple.co/2lwqZIr
Spotify: https://spoti.fi/2nEwCF8
RSS: https://lexfridman.com/feed/podcast/
Full episodes playlist: https://www.youtube.com/playlist?list=PLrAXtmErZgOdP_8GztsuKi9nrraNbKKp4
Clips playlist: https://www.youtube.com/playlist?list=PLrAXtmErZgOeciFP3CBCIEElOJeitOr41

OUTLINE:
0:00 - Introduction
1:57 - Programming languages
33:01 - Modern programming
43:03 - Day in the life
50:53 - Hard work
54:06 - Pizza and Diet Coke
56:50 - Setup
1:22:08 - id Software
1:54:58 - Commander Keen
2:01:44 - Hacker ethic
2:09:24 - Wolfenstein 3D
2:29:21 - Doom
2:43:42 - Quake
3:08:02 - John Romero
3:15:49 - Metaverse
3:44:11 - Elon Musk
3:50:06 - Mars
3:59:09 - Nuclear energy
4:02:47 - AGI
4:49:59 - Andrej Karpathy
4:52:57 - Martial arts
5:01:57 - Advice for young people
5:10:57 - Meaning of life

SOCIAL:
- Twitter: https://twitter.com/lexfridman
- LinkedIn: https://www.linkedin.com/in/lexfridman
- Facebook: https://www.facebook.com/lexfridman
- Instagram: https://www.instagram.com/lexfridman
- Medium: https://medium.com/@lexfridman
- Reddit: https://reddit.com/r/lexfridman
- Support on Patreon: https://www.patreon.com/lexfridman

I remember the reaction where he had drawn these characters and he was slowly moving around and like people had no experience with 3D navigation.

We didn't even have mice set up at that time, but slowly moving, going up, picked up a key, go to a wall, the wall disappears in a little animation and there's a monster like right there and he practically fell out of his chair.

You know, the games were the God's eye view.

You were a little invested in your little guy.

You can be like, you know, happy or sad when things happen, but you just did not get that kind of startle reaction.

Something in the back of your brain, some reptile brain thing is just going, oh shit, something just happened.

And that was 1 of those early points where it's like, yeah, this is going to make a difference.

This is going to be powerful and it's going to matter.

The following is a conversation with John Carmack, widely considered to be 1 of the greatest programmers ever.

He was the co-founder of id Software and the lead programmer on several games that revolutionized the technology, the experience, and the role of gaming in our society, including Commander Keen, Wolfenstein 3D, Doom, and Quake.

He spent many years as the CTO of Oculus VR, helping to create portals into virtual worlds and to define the technological path to the metaverse and meta.

And now he has been shifting some of his attention to the problem of artificial general intelligence.

This was the longest conversation on this podcast at over 5 hours and still I could talk to John many many more times and we hope to do just that.

To support it, please check out our sponsors in the description.

And now, dear friends, here's John Carmack.

What was the first program you've ever written?

So, I remember being in a radio shack going up to the TRS-80 computers and learning just enough to be able to do 10 print John Carmack.

And it's kind of interesting how, of course, Carnegan and Ritchie kind of standardized hello world as the first thing that you do in every computer programming language and every computer, but not having any interaction with the cultures of Unix or any other standardized things, it was just like, well, what am I gonna say?

And then you learn how to do go to 10 and have it scroll all off the screen.

And that was definitely the first thing that I wound up doing on a computer.

I was always told in the beginning that you're not allowed to use go to statements.

Can we look at the philosophy and the technical aspects of the go-to statement that seems so convenient, but it's supposed to be programming?

back in the day in basic programming languages, you didn't have proper loops.

You didn't have for, whiles, and repeats.

You know, That was the land of Pascal for people that kind of generally had access to it back then.

And as you made what were big programs back then, which were a thousand-line basic program is a really big program, They did tend to sort of degenerate into madness.

You didn't have good editors or code exploration tools, so you would wind up fixing things in 1 place, add a little patch, and there's reasons why structured programming generally helps understanding.

Usually it's because there's a language feature missing, like nested breaks or something, where it can sometimes be better to do a goto cleanup or goto error rather than having multiple flags, multiple if statements littered throughout things.

If you grep through all of my code right now, I don't think any of my current codebases would actually have a go-to.

But deep within sort of the technical underpinnings of a major game engine, you're gonna have some go-to's in a couple places probably.

Yeah, the infrastructure on top of, like the closer you get to the machine code, the more go-to's you're gonna see, the more of these like hacks you're going to see, because the set of features available to you in low level programming languages is limited.

So, print John Carmack, when is the first time, if we could talk about love, that you fell in love with programming.

You said like, this is really something special.

It really was something that was 1 of those love at first sight things where just really from the time that I understood what a computer was, even, I mean, I remember looking through old encyclopedias at the black and white photos of the IBM mainframes at the reel-to-reel tape decks.

And for people nowadays, it can be a little hard to understand what the world was like then from information gathering, where I would go to the libraries and there would be a couple books on the shelf about computers, and they would be very out of date even at that point, just not a lot of information.

But I would grab everything that I could find and devour everything.

Whenever Time or Newsweek had some article about computers, I would cut it out with scissors and put it somewhere.

It felt like this magical thing to me, this idea that the computer would just do exactly what you told it to.

I mean, and there's a little bit of the genie monkey's paw sort of issues there where you'd better be really, really careful with what you're telling it to do.

It wasn't going to have a different point of view.

It was going to carry out what you told it to do.

And if you had the right commands, you could make it do these pretty magical things.

And so what kind of programs did you write at first?

So I can remember as going through the learning process where you find at the start you're just learning how to do the most basic possible things.

And I can remember stuff like a Superman comic that Radio Shack commissioned to have, it's like Superman had lost some of his super brain and kids had to use Radio Shack TRS-80 computers to do calculations to help him kind of complete his heroics.

And I'd find little things like that and then get a few basic books to be able to kind of work my way up.

I had a couple books that would teach me important things about it.

I had 1 book that I could start to learn a little bit of assembly language from, and I'd have a few books on BASIC and some things that I could get from the libraries.

But my goals in the early days was almost always making games of various kinds.

I loved the arcade games and the early Atari 2600 games, And being able to do some of those things myself on the computers was very much what I aspired to.

And it was a whole journey where if you learn normal basic, you can't do any kind of an action game.

You can write things where you say, what do you do here?

I get sword, attack troll, that type of thing.

And that can be done in the context of basic I But to do things that had moving graphics there were only the most limited things you could possibly do you could maybe do breakout or Pong or that sort of thing in low resolution graphics And in fact 1 of my first sort of major technical hacks that I was kind of fond of was on the Apple II computers, they had a mode called low resolution graphics, where of course all graphics were low resolution back then.

But regular low resolution graphics, it was a grid of 40 by 40 pixels normally, but they could have 16 different colors.

And I wanted to make a game kind of like the arcade game Vanguard, just a scrolling game.

And I wanted to just kind of have it scroll vertically up.

You could manage to do that in basic, but there's no way you could redraw the whole screen.

And I remember at the time just coming up with what felt like a brainstorm to me where I knew enough about the way the hardware was controlled, where the text screen and the low-resolution graphics screen were basically the same thing.

And all those computers could scroll their text screen reasonably.

You could do a listing and it would scroll things up.

And I figured out that I could kind of tweak just a couple things that I barely understood to put it into a graphics mode, and I could draw graphics, and then I could just do a line feed at the very bottom of the screen, and then the system would scroll it all up using an assembly language routine that I didn't know how to write back then.

So that was like this first great hack that sort of had analogs later on in my career for a lot of different things.

So I found out that I could draw a screen, I could do a line feed at the bottom, we would scroll it up once, I could draw a couple more lines of stuff at the bottom, and That was my first way to kind of scroll the screen, which was interesting in that that played a big part later on in the id software days as well.

So do efficient drawing where you don't have to draw the whole screen, but you draw from the bottom using the thing that was designed in the hardware for text output.

Where so much of, until recently, game design was limited by what you could actually get the computer to do.

Where it's easy to say, like, okay, I want to scroll the screen.

You just redraw the entire screen at a slight offset.

But up until a decade ago or so, there were all these things everybody wanted to do, But if they knew enough programming to be able to make it happen, it would happen too slow to be a good experience, either just ridiculously slow or just slow enough that it wasn't fun to experience it like that.

So so much of kind of the first couple decades of the programming work that I did was largely figuring out how to do something that everybody knows how they want it to happen.

It just has to happen 2 to 10 times faster than sort of the straightforward way of doing things would make it happen.

And it's different now Because at this point, lots of things you can just do in the most naive possible way and it still works out.

You don't have nearly the creative limitations or the incentives for optimizing on that level.

And there's a lot of pros and cons to that.

But I do Generally, I'm not going to do the angry old man shaking my fist at the clouds bit where back in my day programmers had to do real programming.

It's amazing that you can just kind of pick an idea and go do it right now.

And you don't have to be some assembly language wizard or deep GPU arcanist to be able to figure out how to make your wishes happen.

Well there's still, see that's true, but let me put on my old man with a fist hat and say that probably the thing that will define the future still requires you to operate at the limits of the current system.

So we'll probably talk about this, but if you talk about building the metaverse and building a VR experience that's compelling, it probably requires you to not to go to assembly or maybe not literally, but sort of spiritually to go to the limits of what the system is capable

Yeah, and that really was why virtual reality was specifically interesting to me, where it had all the ties to, you could say that even back in the early days, I have some old magazine articles that's talking about Doom as a virtual reality experience back when just seeing anything in 3D.

So you could say that we've been trying to build those virtual experiences from the very beginning.

And in the modern era of virtual reality, especially on the mobile side of things.

When it's standalone, you're basically using a cell phone chip to be able to produce these very immersive experiences.

It's not at the level of what an old school console game programmer would have operated at, where you're looking at hardware registers and you're scheduling all the DMA accesses.

But it is still definitely a different level than what a web developer or even a PC Steam game developer usually has to work at.

There's opportunities for people that wanna operate at either end of that spectrum there and still provide a lot of value to the world.

Let me ask you sort of a big question about preference.

What would you say is the best programming language?

You've seen throughout your career, you're considered by many to be the greatest programmer ever.

I mean, it's so difficult to place that label on anyone, but if you put it on anyone it's you.

So let me ask you these kind of ridiculous questions of what's the best band of all time?

But in your case, what's the best programming language?

Everything has all the caveats about it, but so what I use, so nowadays I do program a reasonable amount of Python for AI ML sorts of work.

That's I'm not a native Python programmer.

It's something I came to very late in my career.

And it has some of those things where there's some amazing stats when you say if you just start, if you make a loop, you know, a triply nested loop and start doing operations in Python, you can be thousands to potentially a million times slower than a proper GPU tensor operation.

You can be as much slower as we've almost gotten faster in our pace of progress and all this other miraculous stuff.

So your intuition's about inefficiencies within the Python sort of-

It keeps hitting me upside the face where it's gotten to the point now I understand it's like, okay, you just can't do a loop if you care about performance in Python.

You have to figure out how you can reformat this into some big vector operation or something that's going to be done completely within a C++ library.

But the other hand is, it's amazingly convenient, and you just see stuff that people are able to cobble together by, you just import a few different things, and you can do stuff that nobody on earth could do 10 years ago, and you can do it in a little cookbook thing that you copy-pasted out of a website.

When I'm sitting down to do what I consider kind of serious programming, it's still in C++, and it's really kind of a C flavored C++ at that, where I'm not big into the modern template metaprogramming sorts of things.

I see a lot of train wrecks coming from some of that over abstraction.

I spent a few years really going kind of deep into the kind of historical Lisp work and Haskell and some of the functional programming sides of things.

And there is a lot of value there in the way you think about things.

And I changed a lot of the way I write my C and C++ code based on what I learned about the value that comes out of not having this random mutable state that you kind of lose track of.

Because something that many people don't really appreciate till they've been at it for a long time is that it's not the writing of the program initially, it's the whole lifespan of the program.

And that's when it's not necessarily just how fast you wrote it or how fast it operates But it's how can it bend and adapt as situations change?

And then the thing that I've really been learning in my time at Meta with the oculus and VR work is It's also how well it hands off between a continuous kind of revolving door of programmers taking over maintenance and different things and how you get people up to speed in different areas and there's all these other different aspects of it.

So C++ is a good language for handover between engineers?

And there's some really interesting aspects to this where in some cases, languages that are not, that are not generally thought well of for many reasons, like C is derided pretty broadly that yes, obviously all of these security flaws that happen with the memory and unsafeness and buffer overruns and the things that you've got there.

But there is this underappreciated aspect to the language is so simple, anyone can go and, you know, If you know C, you can generally jump in someplace and not have to learn what paradigms they're using because there just aren't that many available.

I think there's some really, really well-written C code.

I find it great that if I'm messing around with something in OpenBSD, say.

I mean, I can be walking around in the kernel and I'm like, I understand everything that's going on here.

It's not hard for me to figure out what I need to do to make whatever change that I need to.

While you can have more significant languages, it's a downside of Lisp where I don't regret the time that I spent with Lisp.

I think that it did help my thinking about programming in some ways.

But the people that are the biggest defenders of Lisp are saying how malleable of a language it is, that if you write a huge Lisp program, you've basically invented your own kind of language and structure because it's not the primitives of the language you're using very much.

It's all of the things you've built on top of that.

And then a language like Racket, kind of 1 of the more modern Lisp versions, it's essentially touted as a language for building other languages.

And I understand the value of that for a tiny little project, but the idea of that for 1 of these long-term supported by lots of people kind of horrifies me, where all of those abstractions that you're like, okay, you can't touch this code until you educate yourself on all of these things that we've built on top of that.

And it was interesting to see how when Google made Go, a lot of the criticisms of that are it's like, wow, this is not a state of the art language.

This language is just so simple and almost crude.

And you could see the programming language people just looking down at it.

But it does seem to be quite popular as basically saying this is the good things about C.

Everybody can just jump right in and use it.

You don't need to restructure your brain to write good code in it.

So, I wish that I had more opportunity for doing some work in Go.

Rust is the other modern language that everybody talks about that I'm not fit to pass judgment on.

I've done a little bit beyond Hello World.

I wrote some video decompression work in Rust just as an exercise, but that was a few years ago and I haven't really used it since.

The best programming language is the 1 that works generally that you're currently using.

Because that's another trap is in almost every case I've seen when people mixed languages on a project, that's a mistake.

I would rather stay just in 1 language so that everybody can work across the entire thing.

And we have, like at Meta, we have a lot of projects that use kind of React frameworks.

So you've got JavaScript here, and then you have C++ for real work, and then you may have Java interfacing with some other part of the Android system.

And those are all kind of horrible things.

And that was 1 thing that I remember talking with Boz at Facebook about it, where like, man, I wish we could have just said, we're only hiring C++ programmers.

And he just thought from the Facebook meta perspective, well, we just wouldn't be able to find enough.

With the thousands of programmers they've got there, it is not necessarily a dying breed, but you can sure find a lot more Java or JavaScript programmers.

And I kind of mentioned that to Elon 1 time, and he was kind of flabbergasted about that.

It's like, well, you just, you go out and you find those programmers and you don't hire the other programmers that don't do the languages that you want to use.

But right now, I guess, yeah, they're using JavaScript on a bunch of the SpaceX work for the UI side of things.

When you go find UI programmers, they're JavaScript programmers.

I wonder if that's because there's a lot of JavaScript programmers, because I do think that great programmers are rare.

That it's not, you know, if you just look at statistics of how many people are using different programming languages that doesn't tell you the story of what the great programmers are using.

And so you have to really look at what you were speaking to, which is the fundamentals of a language.

What does it encourage, how does it encourage you to think, what kind of systems does it encourage you to build?

There is something about C++ that has elements of creativity but forces you to be an adult about your programming.

And so it brings out people that are willing to be creative in terms of building large systems and coming up with interesting solutions, but at the same time have the, sort of the good software engineering practices that amend themselves to real world systems.

Let me ask you about this other language, JavaScript.

So if we, you know, aliens visit in thousands of years and humans are long gone, something tells me that most of the systems they find will be running JavaScript.

I kind of think that if we're living in a simulation, it's written in JavaScript.

For the longest time, even still, JavaScript didn't get any respect, and yet it runs so much of the world and an increasing number of the world.

Is it possible that all, everything will be written in JavaScript 1 day?

So the engineering under JavaScript is really pretty phenomenal.

The systems that make JavaScript run as fast as it does right now are kind of miracles of modern engineering in many ways.

It does feel like it is not an optimal language for all the things that it's being used for, or an optimal distribution system to build huge apps in something like this without type systems and so on.

But I think for a lot of people, it does reasonably the necessary things.

It's still a braces and semicolons language.

It's not hard for people to be trained in JavaScript and then understand the roots of where it came from, I think.

Garbage collection is unequivocally a good thing for most programs to be written in.

It's funny that I still, just this morning I was on, I was seeing a Twitter thread of a bunch of really senior game dev people arguing about the virtues and costs of garbage collection.

You will run into some people that are top-notch programmers that just say, no, this is literally not a good thing.

Yes, that it makes you not think about things.

I think that there is so much objective data on the vulnerabilities that have happened in C and C++ programs, sometimes written by the best programmers in the world.

It's like nobody is good enough to avoid ever shooting themselves in the foot with that.

You write enough C code, you're going to shoot yourself in the foot.

And garbage collection is a very great thing for the vast majority of programs.

It's only when you get into the tightest of real-time things that you start saying it's like, no, the garbage collection has more costs than it has benefits for me there.

But that's not 99 plus percent of all the software in the world.

So JavaScript is not terrible in those ways.

And so much of programming is not the language itself.

It's the infrastructure around everyone that surrounds it.

All the libraries that you can get and the different stuff that you can, ways you can deploy it, the portability that it gives you.

And JavaScript is really strong on a lot of those things where for a long time, and it still does if I look at it, the web stack about everything that has to go when you do something really trivial in JavaScript and it shows up on a web browser to kind of x-ray through that and see everything that has to happen for your 1 little JavaScript statement to turn into something visible in your web browser, it's very, very disquieting, just the depth of that stack and the fact that so few people can even comprehend all of the levels that are going on there.

But it's, again, I have to caution myself to not be the in the good old days old man about it because clearly there's enormous value here.

The world does run on JavaScript to a pretty good approximation there, and it's not falling apart.

There's a bunch of scary stuff where you look at console logs and you just see all of these bad things that are happening, but it's still kind of limping along and nobody really notices.

But so much of my systems design and systems analysis goes around, you should understand what the speed of light is, like what would be the best you could possibly do here.

And it sounds horrible, but in a lot of cases, you can be a thousand times off your speed of light velocity for something and it still be okay.

And in fact, it can even sometimes still be the optimal thing in a larger system standpoint where there's a lot of things that you don't want to have to parachute in someone like me to go in and say, make this webpage run a thousand times faster.

Make this web app into a hardcore native application that starts up in 37 milliseconds and everything responds in less than 1 frame latency.

And if somebody wants to go pay me millions of dollars to do software like that, when they can take somebody right out of a boot camp and say, spin up an application for this.

Often being efficient is not really the best metric.

It's like that applies in a lot of areas where It's kind of interesting how a lot of our appliances and everything are all built around energy efficiency, sometimes at the expense of robustness in some other ways or higher costs in other ways, where there's interesting things where energy or electricity could become much cheaper in a future world, and that could change our engineering trade-offs for the way we build certain things where you could throw away efficiency and actually get more benefits that actually matter.

I mean, that's 1 of my – 1 of the directions I was considering swerving into was nuclear energy When I was kind of like, what do I want to do next?

It was either going to be cost-effective nuclear fission or artificial general intelligence.

And 1 of my pet ideas there is like, you know, people don't understand how cheap nuclear fuel is.

And there would be ways that you could be a quarter the efficiency or less, but if it wound up making your plant 10 times cheaper, that could be a radical innovation in something like that.

So there's like some of these thoughts around like direct fission energy conversion, fission fragment conversion that, you know, maybe you build something that doesn't require all the steam turbines and everything, even if it winds up being less efficient.

So that applies a lot in programming where there's always, it's always good to know what you could do if you really sat down and took it far.

Because sometimes there's discontinuities.

Around user reaction times, there are some points where the difference between operating in 1 second and 750 milliseconds, not that huge.

You'll see it in web page statistics, but most of the usability stuff, not that great.

But if you get down to 50 milliseconds, then all of a sudden this just feels amazing.

It's just like doing your bidding instantly rather than you're giving it a command, twiddling your thumbs, waiting for it to respond.

So sometimes it's important to really crunch hard to get over some threshold, but there are broad basins in the value metric for lots of work where it just doesn't pay to even go that extra mile.

And there are craftsmen that just don't want to buy that.

See all Lex Fridman transcripts on Youtube

John Carmack: Doom, Quake, VR, AGI, Programming, Video Games, and Rockets | Lex Fridman Podcast #309