John Carmack: Best Programming Setup and IDE – Lex Fridman Podcast Clips • Hacker News Board

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

#301

Post by alanek2007xD » Fri, Aug 19, 2022, 5:15 PM UTC

heynowheynow wrote: post #36

Barrin92 wrote: post #16

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.

lol you probably never wrote a live of code in your proffesional life xD i've used Idea and it's shit and slow as fuck. VSCode works fast even on a laptop, with intellisense scanning code in background. Noob.

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

#302

Post by SantiagoElf » Thu, Aug 25, 2022, 1:42 PM UTC

Carmack said he is using Visual Studio - the full, big, freaking IDE. Not Visual Studio 6.0, but the latest version ( I assume 2022).

So, to repeat Carmack IS NOT using VS Code, but the full Visual Studio on Windows.

Amen.

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

#303

Post by laumars » Sat, Aug 27, 2022, 2:05 PM UTC

badsectoracula wrote: post #298

laumars wrote: post #294

Earlier quoted context omitted.

> You could do that from pretty much any Windows language, Visual Basic wasn't special in that regard You mean “Microsoft” language surely? You couldn’t access DLLs from Perl, PHP, Java, and a bunch other other languages that had been ported to Windows. And my point wasn’t that VB was special. Just that you could still interface with C++ code albeit only via compiled libraries (you also could access COM objects too).…

> You mean “Microsoft” language surely? You couldn’t access DLLs from Perl, PHP, Java, and a bunch other other languages that had been ported to Windows. There were languages that weren't able to call such DLLs, but there were also many that could that weren't made by Microsoft - e.g. Borland Delphi, Power BASIC, a bunch of Smalltalk implementations, etc. > I got that was your point but they weren’t part of the same…

> there were also many that could that weren't made by Microsoft - e.g. Borland Delphi, Power BASIC, a bunch of Smalltalk implementations, etc.

I know. I’m not saying “only Microsoft languages” could. I’m responding to your absolute stating that not “all” Windows languages could. I’m simply saying that absolute only works with regards to Microsoft languages. I’m not suggesting it’s limited to only Microsoft languages.

You really need to calm down a little here mate because your comments are an over reaction to the replies being made.

> I know what they were, what i referred to was what they should have been considering that they were (potentially) part of the same package

But they weren’t part of the same package. So your argument falls flat on the very first assumption.

> made by the same company who had access to the source code, libraries, etc to make these two programs "know" about each other in a more integrated way than what external 3rd party development tools were able to do.

This is another assumption. If you’d spent any time working for a company like Microsoft you’d quickly realise that different products might fall under different teams who have very little cross pollination. I’ve seen this problem time and time again in larger tech companies and it’s often just as frustrating for the employees as it is for the customers.

> This was about a what could have been, not about what it was

I got your point was about “what ifs” but the problem is your “what ifs” are based on assumptions that don’t hold true. So you’d need to stack up a number of other “what ifs” just to get to the stage that your original “what if” is even imaginable.