John Carmack: Best programming setup and IDE | Lex Fridman Podcast Clips

Summary

The speaker reflects on their development setup and preferences, advocating for the use of debuggers and IDEs in game development. They critique Silicon Valley's aversion to such tools, emphasizing the importance of experimenting within the system to understand complex code. The conversation touches on the evolution of development tools, the value of static analysis, and the role of AI in code generation and understanding. The speaker also discusses their personal experience with classic vi and Emacs, and the growing adoption of Visual Studio Code, highlighting the balance between tool efficiency and flexibility.

Takeaways

• 🖥️ The speaker has a preference for development environments that include powerful debuggers and IDEs, contrary to some Silicon Valley cultures that are less reliant on them.
• 🛠️ Debugging tools are essential for understanding complex systems, as they provide a window into the inner workings of the code, which is too complicated to grasp by reading alone.
• 🔍 The speaker emphasizes the inefficiency of using log statements and recompilation for debugging, advocating for more interactive and immediate feedback through debuggers.
• 🌐 There is a cultural divide between game development and Silicon Valley tech companies, with the former valuing interactive debugging more than the latter.
• 📚 The speaker experimented with classic vi (an older version of vim) but ultimately preferred returning to Visual Studio for its modern features and convenience.
• 💡 The importance of using modern tools and practices is highlighted, as they can significantly improve productivity and code quality, even if it means stepping away from traditional or personal preferences.
• 🔧 The speaker appreciates the value of static code analyzers and asserts in catching errors early in the development process, promoting a more robust codebase.
• 🔄 The use of asserts in code is a personal preference that helps catch mistakes that might otherwise go unnoticed, acting as a safety net for potential issues.
• 📈 The speaker discusses the benefits of setting limits in code, such as static array sizes, to be alerted when the assumptions about the world change, which can affect the performance of the program.
• 🔬 There is a suggestion that AI and advanced tools could play a significant role in understanding and working with large, complex codebases that are beyond human cognitive limits.
• 🔀 The speaker's setup includes a triple monitor configuration, which has been a significant improvement over dual monitors, but there is no mention of any special keyboards or mice.

Q & A

What is the speaker's opinion on the use of debuggers and IDEs in big tech companies like Google and Meta?

The speaker finds it surprising that big tech companies can be hostile to debuggers and IDEs, suggesting that they can learn from the game development culture where debuggers are used frequently and effectively.

Why does the speaker advocate for the use of debuggers during the development process?

The speaker believes that debuggers provide a powerful interface to examine and manipulate a system in real-time, allowing for a more interactive and efficient debugging process compared to traditional compile-run-debug cycles.

What is the speaker's stance on the use of static code analyzers and automated tools in coding?

The speaker is a strong proponent of static code analyzers and automated tools, arguing that they are essential for maintaining code quality and catching errors that humans might overlook, especially in large codebases.

How does the speaker describe their experience with using different development environments and tools?

The speaker has experimented with various tools, including classic vi and Emacs, but ultimately prefers an IDE with a helpful debugger and tools, such as Visual Studio, for its efficiency and user-friendliness.

What is the speaker's view on the role of AI in code development and analysis?

The speaker suggests that AI could potentially play a significant role in understanding and analyzing large, complex codebases that are beyond human comprehension, possibly through tools like GitHub Copilot.

Why did the speaker decide to use a debugger for their C++ code?

The speaker uses a debugger to interactively work with their code, setting breakpoints and stepping through functions to ensure the code behaves as expected, which they find more efficient than relying solely on their mental interpretation.

What does the speaker think about the importance of setting limits and assertions in code?

The speaker values setting limits and assertions in code as a way to catch unexpected changes or errors early, arguing that it forces developers to reevaluate their initial assumptions and code design choices.

How does the speaker feel about the transition from older development tools to modern ones like Visual Studio Code?

The speaker acknowledges the shift towards modern tools like Visual Studio Code and sees it as a positive development, noting that it might be a solution that satisfies a wide range of developers, including those who previously used Vim and Emacs.

What is the speaker's opinion on the use of triple monitors in their setup?

The speaker has transitioned to using triple monitors and finds it to be a significant improvement over dual monitors, describing it as a 'pure win' in their setup.

What does the speaker imply about the culture differences between game development and Silicon Valley venture culture?

The speaker implies that there are distinct cultural differences between game development and Silicon Valley venture culture, with the former being more pragmatic and tool-oriented, while the latter may be more resistant to certain tools like debuggers.

Outlines

00:00

💻 Debuggers vs. IDEs: A Game Dev Perspective

The speaker reflects on their transition from game development to Silicon Valley's tech culture, emphasizing the significant differences in attitudes toward tools like debuggers and IDEs. They express surprise at how some large tech companies, like Google and Meta, underutilize these tools, favoring text editors like Emacs and Vim. The speaker advocates for the importance of debuggers in understanding complex systems, criticizing the inefficiency of relying solely on reading code or adding log statements. They stress that better tools, such as interactive debuggers, can streamline the coding process and help catch errors early.

05:01

🛠️ The Importance of Code Analysis and Guardrails

The speaker discusses the value of static analysis tools in maintaining code quality, sharing their experience of thoroughly analyzing a large codebase to uncover numerous hidden errors. They emphasize the inevitability of mistakes in any large codebase and advocate for the use of automated tools and guardrails, such as static types and warnings, to catch these issues. The speaker also highlights the need for an ego check among developers, acknowledging that even experienced programmers produce flawed code. They argue that while test-driven design and unit testing are valuable, analysis tools that prevent errors from being compiled are more effective in ensuring code reliability.

10:02

🔢 Balancing Flexibility and Constraints in Programming

The speaker reflects on the balance between flexibility and constraints in programming, using their experience with fixed limits in early game development as an example. They argue that while making systems completely generic can be beneficial, it is also important to set limits and use assertions to ensure that the system adapts correctly when the world around it changes. The speaker prefers static array size declarations over continuously growing collections, as they provide a way to monitor and adjust for changes in usage patterns. They also share their approach to using asserts in personal code, finding them valuable for catching mistakes and ensuring that assumptions hold true over time.

Keywords

💡Debugger

A debugger is a tool used in software development that allows programmers to test and debug their code by stepping through the execution one line at a time, examining variables, and setting breakpoints. In the video's context, the speaker emphasizes the importance of debuggers in understanding complex systems and improving the efficiency of the development process, contrasting the traditional compile-run-debug cycle with the interactive approach of using a debugger.

💡IDE (Integrated Development Environment)

An Integrated Development Environment is a software application that provides comprehensive facilities to computer programmers for software development. The speaker mentions IDEs in the context of their importance in the development setup, discussing the preference for modern IDEs that come with helpful tools like debuggers, as opposed to older, more text-based editors like Emacs or Vim.

💡Game Development

Game development refers to the process of creating a video game. The speaker discusses the unique culture within game development, which is distinct from other tech industry cultures. They highlight how game developers often rely on tools like debuggers due to the complexity of game systems, which is a central theme in the video.

💡Silicon Valley

Silicon Valley is a region in Northern California known for its high-tech innovation and venture capital funding. The speaker contrasts the attitudes towards debuggers and IDEs in Silicon Valley with those in game development, suggesting that Silicon Valley companies may not fully utilize these tools, which is a point of discussion in the video.

💡Emacs

Emacs is a highly customizable text editor that is popular among programmers, especially those who prefer a keyboard-centric workflow. The speaker mentions Emacs as an example of a tool that some developers prefer over modern IDEs, despite the potential for less efficiency in certain development tasks.

💡Vim

Vim is a highly configurable text editor built to enable efficient text editing. It is an improved version of the vi editor. The speaker refers to Vim as an example of a tool that, while powerful, may not be as user-friendly or efficient for certain tasks compared to modern IDEs with integrated debuggers.

💡Linux

Linux is a family of open-source Unix-like operating systems. The speaker mentions a 'Linux bias' as a reason why some developers might not use debuggers as frequently, suggesting that the preference for command-line tools in the Linux community might influence development practices.

💡GDB

GDB is the GNU Project Debugger, a powerful command-line debugger that is primarily used for C and C++ programming languages. The speaker mentions GDB as an example of a debugger that is used when developers are at their wit's end, highlighting its role as a last-resort tool for some, but a first-choice for others in game development.

💡Static Code Analyzers

Static code analyzers are tools that examine source code without executing it, to look for potential errors, bugs, and nonstandard coding practices. The speaker discusses the value of static code analyzers in identifying issues that might not be caught by other means, emphasizing their importance in maintaining code quality.

💡Assert

In programming, an assert statement is used to check during runtime that a condition is true. If the condition is false, the program will terminate. The speaker mentions the use of assert statements in their code to catch mistakes and ensure that certain conditions hold true at various points in the program's execution, illustrating the proactive approach to error handling.

💡Visual Studio Code

Visual Studio Code is a free, open-source code editor made by Microsoft. It is highly extensible and customizable, with support for a wide range of programming languages. The speaker mentions Visual Studio Code as a modern IDE that is gaining popularity, suggesting it might be a compromise that satisfies both the need for powerful tools and the preference for lightweight, flexible editors.

Highlights

The speaker emphasizes the importance of debuggers and IDEs in understanding complex systems, contrary to the Silicon Valley culture that often avoids them.

Game development culture is highlighted as having distinct practices and values compared to the Silicon Valley venture culture.

The speaker shares a personal anecdote about the efficiency of using a debugger for immediate problem-solving within code.

The concept of using a debugger as a regular part of the programming process is introduced, rather than as a last resort.

The speaker discusses the limitations of relying solely on reading code to understand complex systems, advocating for experimental approaches.

The importance of using better tools to increase efficiency in the development process is underscored.

The discussion of AI's potential role in coding and its ability to understand and work with large, complex codebases is introduced.

The value of static code analyzers and dynamic tools in catching errors before they become problematic is highlighted.

The speaker recounts a personal experience using code analysis tools on a large codebase, revealing numerous errors.

The necessity of automated tools and guardrails in coding to prevent syntactical errors is emphasized.

The speaker shares thoughts on the use of asserts in code to catch mistakes and ensure program correctness.

The discussion of the changing world and its impact on code, advocating for static array sizes and asserts to catch unexpected changes.

The speaker's preference for an IDE with helpful debuggers over Emacs or Vim is mentioned.

A personal account of trying to adapt to classic vi and eventually returning to Visual Studio for its efficiency.

The speaker's setup preferences, including the use of triple monitors and a standard keyboard, are described.

The potential of Visual Studio Code as a unifying solution for developers, gaining popularity even among Vim and Emacs users.

The trade-off between the flexibility of older development environments and the responsiveness of modern IDEs is discussed.

Transcripts

what about your setup how many screens

what kind of keyboard is there something

interesting what kind of i ide

emacs vim or something modern

uh linux what operating system laptop or

any any interesting thing that brings

you joy so i kind of migrated cultures

where early on through all of game dev

there was sort of one culture there

which was really quite distinct from the

more uh the silicon valley venture you

know culture for things it's they're

different groups and they have pretty

different mores and the way they think

about things where

and i still do think a lot of the big

companies can learn uh can learn things

from the hardcore game development side

of things where it still boggles my mind

how

i am how hostile to debuggers and ides

that so much of the the kind of big

money get billions of dollars silicon

valley venture-backed funds are well

that's interesting sorry so you're

saying like

like uh big companies that google and

meta are hostile to they are not big on

debuggers and ides like so much of it is

like emacs bim for things and we just

assume that debuggers don't work most of

the time i for the systems and a lot of

this comes from a sort of linux bias on

a lot of things where i did come up

through the the personal computers and

then the dos and then

windows and

and it was borland tools and then visual

studio and

do you appreciate the buggers

very much so i mean a debugger is how

you get a view into a system that's too

complicated to understand i mean anybody

that thinks just read the code and think

about it that's an insane statement in

the you can't even read all the code on

a big system you have to do experiments

on the system and doing that by adding

log statements recompiling and

re-running it uh is an incredibly

inefficient way of doing it i mean yes

you can always get things done even if

you're working with stone knives and you

know and bear skins that's that is the

mark of a good programmer is that given

any tools you will figure out a way to

get it done

but

it's amazing what you can do with

sometimes much much better tools where

instead of just going through this

iterative compile run debug cycle and

you have the

you have the old lisp direction of like

you've got a reply and you're working

interactively and doing amazing things

there but in many cases a debugger has a

very powerful user interface that can

stop examine all the different things in

your program set all these different

break points and of course you can do

that with gdb or whatever there but

this is one of the user interface

fundamental principles where when

something is complicated to do you won't

use it very often there's people that

will break out gdb when they're at their

wit's end and they just have beat their

head against a problem for so long but

for somebody that kind of grew up in

game dev it's like they were running

into the debugger anyways before they

even knew there was a problem and you

would just stop and see you know what

was happening and sometimes you could

fix things even before you you know

even before you did one compile cycle

you could be in the debugger and you

would say well i'm just going to change

this right here and yep that did the job

and fix it and go on and for people

don't know gdb is a sort of popular i

guess linux debugger

uh

primarily for c plus

they they handle most of the languages

but it's you know it's based on c as the

the original kind of unix heritage but

and it's kind of like command line it's

not user friendly it's not it doesn't

allow for clean visualizations and

you're you're exactly right just so

you're using this kind of debugger

usually when you're what's end and

there's a problem that you can't figure

out why by just looking at the codes

they have to find it that's how i guess

normal programmers use it but you're

saying there should be tools that kind

of

visualize and help you as part of the

programming process

just a normal programming process to to

understand the code deeper yeah when i'm

working on like my cc plus plus code i'm

always running it from the debugger you

know just i type in the code i i run it

many times the first thing i do after

writing code is set a breakpoint and

step through the function now other

people say it's like oh i do that in my

head well your head is a faulty

interpreter of all those things there

and i've written brand new code i want

to step in there and i'm going to single

step through that examine lots of things

and see if it's actually doing what i

expected it to

it is a kind of

companion the debugger like you're

you're now coding in an interactive way

with another

being

a debugger is a kind of dumb being but

it's a reliable being

that is an interesting question of what

role does ai play in that kind of

with codex and these kind of

ability to generate code might be you

might start having tools that

understand the code in interesting deep

ways that can work with you because

there's a whole spectrum there from

static code analyzers and various kind

of dynamic tools they're up to ai that

can conceivably grok these programs that

no literally no human can understand

they're they're too big too intertwined

and too interconnected but it's not

beyond the possibility of understanding

it's just beyond what we can hold in our

heads as kind of mutable state while

we're working on things

and

and i'm a big proponent again of things

like static analyzers and some of that

stuff where

you'll find some people that don't like

being scolded by a program for how

they've written something where it's

like oh i know better and sometimes you

do but that was something that

i was it was very

very valuable for me when uh and not too

many people get an opportunity like this

to have this is almost one of those

spiritual experiences as a programmer an

awakening to

i am theod software code bases were a

couple million lines of code and at one

point i had used a few of the different

analysis tools but i made a point to

really go through and scrub the code

base using every tool that i could find

and it was eye-opening where we had a

reputation for having some of the the

most robust strongest code you know

where there were some you know great

things that i remember hearing from

microsoft telling us about crashes on

xbox and we had this tiny number that

they said were were probably literally

hardware errors and then you have other

significant titles that just have

millions of faults that are getting

recorded all the time so i was proud of

our code on a lot of levels but when i

took this code analysis squeegee through

everything

it was

it was shocking how many errors there

were in there things that you can say

okay this was this was a copy paste not

changing something right here lots of

things that were you know the most the

most common problem was something in a

printf format string that was the wrong

data type that could cause crashes there

and you know you really want the

warnings for things like that then the

next most common was missing a check for

null that could actually happen that

could blow things up and those are

obviously like top cc plus plus things

everybody has those problems but the

long tail of all of the different little

things that could go wrong there and we

had good programmers and my own codes

that i'd be looking at it's like oh i

wrote that code that's definitely wrong

we've been using this for a year and

it's this submarine you know this mine

sitting there waiting for us to step on

and

it was humbling it was uh and i reached

the conclusion that

anything that can be syntactically

allowed in your language

if i'm

it's gonna show up eventually in a large

enough code base i you're not gonna good

intentions aren't going to keep it from

happening you need automated tools and

guardrails for things and those start

with things like static types and or

even type hints in the more dynamic

languages but

the people that rebel against that that

basically say uh that slows me down

doing that there's something to that i

get that i've written you know i've

cobbled things together in a notebook i

i'm like wow this is great that it just

happened but yeah that's kind of sketchy

but it's working fine i don't care it

does come back to that that value

analysis where sometimes it's right to

not care

but when you do care if it's going to be

something that's going to live for years

and it's going to have other people

working on it i and it's going to be

deployed to millions of people

then you want to use all of these tools

you want to be told it's like no you've

screwed up here here and here and that

does require kind of an ego check about

things where you have to

to be open to the fact that everything

that you're doing is just littered with

flaws it's not that oh you occasionally

have a bad day it's just whatever stream

of code you output there is going to be

a statistical regularity of things that

you just make mistakes on

and i

and i do think there's the whole

argument about test driven design and

unit testing versus kind of analysis and

different things

i am more in favor of the analysis and

the stuff that just like you can't run

your program until you fix this rather

than you can run it and hopefully a unit

test will catch it in some way yeah in

my private code i have asserts

everywhere yeah uh

just there's something

pleasant to me pleasurable to me about

sort of the dictatorial rule of like

this should be true at this point

in too many times

i've

made mistakes

that shouldn't have been made

and i would assume

i wouldn't be the kind of person that

would make that mistake but i keep

making that mistake therefore and the

cert really catches me

uh really helps all the time so my co i

would say like 10 to 20 percent of my

private code just for personal use is

probably a certain and they're active

comments that's one of those things that

in theory they don't they don't make any

difference to the program and if it was

all operating the way you expected it

would be then i they will never fire but

even if you have it right and you wrote

the code right initially then

circumstances change the world outside

your program changes and in fact that's

that's one of the things where i'm kind

of fond in a lot of cases of static

array size declarations where i went

through this period where it's like okay

now we have general collection classes

we should just make everything variable

i because i had this history of in the

early days you get doom which had some

fixed limits on it then everybody

started making crazier and crazier

things and they kept bumping up the

different limits this many lines this

many sectors

uh and it seemed like a good idea well

we should just make this completely

generic it can go kind of go up to

whatever

and

there's cases where that's the right

thing to do

but it also the other aspect of the

world changing around you is it's good

to be informed when the world has

changed more than you thought it would

and if you've got a continuously growing

collection you're never going to find

out you might have this quadratic

slowdown on something where you thought

oh i'm only ever going to have a handful

of these but something changes and

there's a new design style and all of a

sudden you've got 10 000 of them

so i kind of like in many cases

picking a number some you know nice

round power of two number and setting it

up in there and having an assert saying

it's like hey you hit the you hit this

limit you should probably think are the

choices that you've made around all of

this still relevant if somebody's using

10 times more than you thought they

would yeah this code was originally

written with this kind of world view

with this kind of set of constraints you

were you were thinking of the world in

this way

if something breaks that means you got

to rethink the initial stuff and that's

it's nice for it to afford for it to do

that is there any stuff like uh keyboard

or

monitor i'm fairly pedestrian on a lot

of that where i i did move to triple

monitors like in the last several years

ago i had been dual monitor for a very

long time and i am and it was one of

those things where

probably years later than i should have

i'm just like well the video cards now

generally have three output ports i

should just put the third monitor up

there that's been a that's been a pure

win i've been very happy with that

but no i don't have fancy keyboard or

mouse or anything really the key things

is an ide that has uh helpful debuggers

has helpful tools

so it's not the emacs vim route and then

diet coke yeah so i did spend you know i

spent uh one of my week-long retreats

where i'm like okay i'm gonna make

myself use uh there's actually classic

vi which i know people will say you

should never have done that you should

have just used vim directly but you know

i gave it the good try it's like okay

i'm being in kind of classic unix

developer mode here and i worked for

a week on it i used anki to like teach

myself the the different little key

combinations for things like that and in

the end it was just like all right this

was kind of like my civil war

reenactment phase you know it's like i'm

going out there doing it like they used

to in the old days and it was kind of

fun in that regard so many people right

now

screaming as they're listening to this

so again the out is that this was not

modern vim but still i yes i was very

happy to get back to my visual studio at

the end yeah i'm actually i struggle

with this a lot because

so use a kinesis keyboard and um

i use emacs primarily

and i i feel like i can

exactly as you said i can understand the

code i can navigate the code there's a

lot of stuff you could build within

emacs with using lisp you can customize

a lot of things for yourself to help you

introspect the code like to help you

understand the code and visualize

different aspects of the goal you can

even run debuggers but it's it's work

and the world moves past you and the

better and better ideas are constantly

being built and that that puts a

kind of

i need to take the same kind of retreat

as you're talking about but now i'm

still fighting the civil war i need to

kind of move into the 21st century and

it does seem like the world is or a

large chunk of the world is moving

towards visual studio code which is kind

of interesting to me against the

javascript ecosystem on the one hand and

ids are one of those things that you

want to be infinitely fast you want them

to just kind of immediately respond

and like i mean heck i've got there's

someone i know i'm an old-school game

dev guy that still uses visual studio

six and on a modern computer everything

is just absolutely instant on something

like that because it was made to work on

a computer that's

ten thousand or a hundred thousand times

slower so just everything happens

immediately and all the modern systems

just feel

you know they feel so crafty when it's

like oh why is this refreshing the

screen and moving around and updating

over here and something blinks down

there and you should update this and

there's

you know there there are things that

we've lost with that incredible

flexibility but

uh lots of people get tons of value from

it and i am super happy that that seems

to be winning over even a lot of the old

vim and emacs people that they're kind

of like hey visual studio codes maybe

you know not so bad i am that may be the

final peacekeeping solution where

everybody is reasonably happy with i

with something like that

you