John Carmack: Best programming setup and IDE | Lex Fridman Podcast Clips
Summary
TLDRThe 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
💻 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.
🛠️ 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.
🔢 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.
Mindmap
Keywords
💡Debugger
💡IDE (Integrated Development Environment)
💡Game Development
💡Silicon Valley
💡Emacs
💡Vim
💡Linux
💡GDB
💡Static Code Analyzers
💡Assert
💡Visual Studio Code
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
Weitere ähnliche Videos ansehen
CH03. L03. Static analysis
My Minimal and Beautiful VSCode Setup
Claude 3.5 Sonnet Explained: Real-life use cases (No More GPT 😱)
Scrum Master é um Inútil (não é só sobre isso)
ISTQB FOUNDATION 4.0 | Tutorial 23 | Static Testing Basics | Reviews & Static Analysis | CTFL
Writing Code vs. Drag and Drop for Website Building
5.0 / 5 (0 votes)