Lex Clips
1 HN recommender · recommended in 8 months, 2022–2025
15:20 · 961K views · Aug 6, 2022
A clip of John Carmack on the Lex Fridman podcast discussing his programming setup, why he favors debuggers and IDEs, and his puzzlement at developers who avoid them.
HN debugger-versus-print-debugging threads point to it as Carmack's authoritative case for using a real debugger.
8 comments from Hacker News
This was one of the more interesting parts of John Carmack's interview on Fridman's podcast: this video
Print debugging is a disaster. If there's one widespread practice among non-beginner developers that wastes hours of time it's print debugging. I honestly can't tell how often I have seen people, even experienced programmers (usually because they insist on running some bespoke vim setup) refuse to use a graphical debugger to actually step through a program, and instead they spend hours hunting down bugs they could have found in ten minutes. There's a section of an interview with John Carmack ( this video ) where he laments the same thing. It's what the Windows/game development corner of the programming world actually got right, people generally use effective tools for software development.
vim bindings are worth learning, vim/nvim itself is not. Two reasons. One, graphical debugging. Almost every hardcore vim/nvim user I've met has terminal (no pun intended) printf-debugging disease, or uses an IDE on a second monitor. Carmack talked about it in an interview ( this video ) Secondly people, especially with neovim, seem to be hellbent on turning the thing into a GUI editor anyway, with bespoke search interfaces, file tree plugins, graphical plugin installers, and so on. At which point I don't understand why you're not using something made for that purpose rather than painfully try to reinvent it in a piece of software designed to output text
Thanks for your take. What do you think of John Carmack's[1] suggestion that using a debugger is the best way to program? I am by no means comparing myself to Carmack :-) I find debugger a good way to "see" what the program is doing. But that leads to a lot of time wasted. [1] this video
Contrasting perspective from John Carmack [1] who drops into a debugger all the time to explore state, understand program behavior, debug things, etc. Looks like there is no universal golden path. Differing environments make different approaches effective. [1] this video