Live data from Hacker News

John Carmack: Best Programming Setup and IDE – Lex Fridman Podcast Clips

youtube.com

91–100 of 303 posts

Re: John Carmack: Best Programming Setup and IDE – Lex Fridman Podcast Clips

#91

I'm one of the people he talks about who moved from diehard Emacs use slowly to more and more VSCode use largely due to the better UI experience around debugging and integration of a lot of modern tools. His point about features not being used when they're complicated to reach despite people claiming that they'll use them is a true observation in particular. You always can set up a lot of those features in your unix-…

I tried VScode twice and despise it. Cold never get it to be much more useful than a text editor with syntax highlighting. Tried setting it up for java and even with fiddling and tweaking it didn't work nearly as well as the default eclipse setup regarding code navigation and maven integration. It felt just like trying to get vim to be modern and useful. Maybe possible, but a lot of effort when there is other solutions that work right out of the box. Second try was for PHP, and that was even more futile. For PHP it actually seems like jetbrains is the only one providing an ide that doesn't make you lose your mind with that language, so not necessarily a sign that VScode in particular is bad.

For C++ I never even tried it because I'm usually content with qt creator.

Re: John Carmack: Best Programming Setup and IDE – Lex Fridman Podcast Clips

#93
post #42

Earlier quoted context omitted.

That note always struck me as pride in self flagellation. Having been around many talented kernel developers, most are perfectly happy with a debugger or any other tool they can use to debug something.

“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” — Brian Kernighan

That doesn't really refute the point that Carmack made. Namely that a lot of the supposed inherent difficulty in the endeavour of debugging is actually incidental from a general cultural attachment to crap old tooling.

Re: John Carmack: Best Programming Setup and IDE – Lex Fridman Podcast Clips

#95

In 2000-2006 I implemented garbage collectors in C on Linux. I used Emacs and GDB, and likely also DDD and GDB from within Emacs. I don't think there was anything better back then. It's been a long time since I used C, but I wonder whether VSCode really gives a better experience than Emacs. Nowadays you can use Emacs with an LSP server, which is likely also what VSCode is doing. And there are Emacs distributions like…

> Regarding the comment about the debugging. For me personally, I always take the time to study the code first before I start debugging. A lot of times I already find the problem by just reading the code and even if that is not the case, I have a much better understanding about how the code is supposed to behave and that makes the debugging session a lot more useful. And I say that because I have the impression that…

> I have seen the same argument about syntax highlighting. That pretty colors makes for sloppy code reading and monochrome text means you read slower and thus more thoroughly…

The amount of times color change has indicated syntax error to me makes it a no brainer. Sure, some systems may have an older editor that doesn't have color highlighting, but that's a rare scenario for me. I'm not going to give up the huge benifit just to "train" my mind for such rare cases.

Re: John Carmack: Best Programming Setup and IDE – Lex Fridman Podcast Clips

#96
post #59

Earlier quoted context omitted.

I understand your point, but I can’t say I relate at all. I start my code editor maybe once or twice a day, so the launch speed does not even register RAM and computers in general are so cheap that I just max out every laptop configuration I buy. If you’re a programmer and will use a machine for work spending $3-4k every couple years should not be a problem, we’re paid very well and should therefore use the best tool…

> I start my code editor maybe once or twice a day I start my main editor (with the shortcuts I like and all) every time I write (or edit) a commit message. And back when I used Mutt, every time I wrote an email as well. (Now I’m using Thunderbird, but I did like the ability to use my preferred text editor everywhere.) RAM is cheap at the individual level. But if the entire world needs to go from 16GB to 32GB or what…

Have you tried Magit in Emacs? It's an embedded git client with a very smooth workflow. No need to open and close Emacs just to edit the commit message. Once I got really used to Magit, it's definitely my favorite way to interact with git.

Some valuable advice I got about Emacs after switching from Vim is that it's not really a text editor, it's more like an operating system. You shouldn't need to reboot the OS between saving a file and commiting it. I typically only start Emacs once, then do everything from inside it. That being said, it's a very different workflow from Vim or VSCode, and not everyone's favorite way to work.

I even got it setup so I open multiple projects in the same single instance, and slightly change the background color based on what root directory a file is in. This way I don't get turned around when working in both a client and server, or producer and consumer.

Re: John Carmack: Best Programming Setup and IDE – Lex Fridman Podcast Clips

#97

I'm one of the people he talks about who moved from diehard Emacs use slowly to more and more VSCode use largely due to the better UI experience around debugging and integration of a lot of modern tools. His point about features not being used when they're complicated to reach despite people claiming that they'll use them is a true observation in particular. You always can set up a lot of those features in your unix-…

VSCode is based on Electron, a glorified hack/resource hog of Chromium than even Github largely abandoned. It maybe "great" and mildly "popular" here and there, but it's built on a foundation of mud. Build native apps that work and are performant. With enough effort and care, a frictionless experience can be made with a TUI should some "Jetbrains" come along and try to make a commercial product out of it.

>Build native apps that work and are performant.

The ‘native’ there is redundant. The only thing that matters is if VSCode works well enough and is performant enough to be a viable option.

Often native apps will win on the ‘works well enough’ criteria, due to superior OS integration and familiarity, but that isn’t a given. If you use multiple platforms then having a solid cross platform option also has advantages in that area.

Re: John Carmack: Best Programming Setup and IDE – Lex Fridman Podcast Clips

#99
post #13

I am curious: how does this guy Friedman make a living?! His full time job seems to be running this podcast interviewing people. Every few days he publishes a 2-hour long interview. He distributes ads, I am not sure how much that brings in.

A semi successful YouTube video with less 2m views can easily bring in several thousand dollars in ad revenue. He is way more successful and has multiple sponsors. https://www.atomic14.com/2022/07/27/successful-youtube-video...

Several thousands for what time duration?

That’s one month of rent.

I would be interested in some estimates of revenue per audience.

Re: John Carmack: Best Programming Setup and IDE – Lex Fridman Podcast Clips

#100
VSCode is definitely the first IDE I've ever felt satisfied with. I still run it with vim keybindings and will often pop up the VSCode terminal to run actual neovim for certain workflows, but it feels smooth switching between the two. Eclipse, IntelliJ, and especially XCode feel so frustratingly slow and confusing in comparison.

The tight focus on the developer experience with TypeScript was what won me over. Functionality like live share has been a game changer. The extensibility is also pretty great and doesn't feel like I sacrificed that aspect of vim either. If anything, it even surpasses it because of the UI possibilities. Some personal examples that come to mind are:

* Live preview rendered markdown as you edit

* Live preview MermaidJS diagrams as you edit

* Live preview MJML email templates as you edit

* Live preview draw.io/diagrams.net diagrams as you edit

* Live preview SVG images being edited/generated by code

* Work on Jupyter notebooks and actually run them

Post reply on HN