John Carmack: Best programming setup and IDE | Lex Fridman Podcast Clips
ฝัง
- เผยแพร่เมื่อ 5 ส.ค. 2022
- Lex Fridman Podcast full episode: • John Carmack: Doom, Qu...
Please support this podcast by checking out our sponsors:
- InsideTracker: insidetracker.com/lex to get 20% off
- Indeed: indeed.com/lex to get $75 credit
- Blinkist: blinkist.com/lex and use code LEX to get 25% off premium
- Eight Sleep: www.eightsleep.com/lex and use code LEX to get special savings
- Athletic Greens: athleticgreens.com/lex and use code LEX to get 1 month of fish oil
GUEST BIO:
John Carmack is a legendary programmer, co-founder of id Software, and lead programmer of many revolutionary video games including Wolfenstein 3D, Doom, Quake, and the Commander Keen series. He is also the founder of Armadillo Aerospace, and for many years the CTO of Oculus VR.
PODCAST INFO:
Podcast website: lexfridman.com/podcast
Apple Podcasts: apple.co/2lwqZIr
Spotify: spoti.fi/2nEwCF8
RSS: lexfridman.com/feed/podcast/
Full episodes playlist: • Lex Fridman Podcast
Clips playlist: • Lex Fridman Podcast Clips
SOCIAL:
- Twitter: / lexfridman
- LinkedIn: / lexfridman
- Facebook: / lexfridman
- Instagram: / lexfridman
- Medium: / lexfridman
- Reddit: / lexfridman
- Support on Patreon: / lexfridman - วิทยาศาสตร์และเทคโนโลยี
If John Carmack says my brain is a faulty interpreter, then my brain is a faulty interpreter - nothing else to say.
Yeah, felt good to hear him say that, if he can't read and understand a code base, nobody on earth will.
My brain tells me it is the perfect interpreter, wich in turn has to mean its faulty.
Glad to hear a programmer who understands the fallacies of programmers.
I can't find fault with anything he's said, but I do wonder if I simply happen to share his particular dogmas.
@@Falcrist Maybe the fault of not knowing Emacs is an IDE and has massive debugger capabilities out of the box? A minute in and the guy is just factually incorrect. Or the fact that using VI(M) doesn't preclude the use of a debugger? Debugging is done at runtime and is affected by compilation (whether symbols are included, at least in most languages). Most "Silicon Valley" companies don't "debug" things, due to most problems stemming from integration failure, rather than a particular file containing some type of error like in a game. Debugging a system that relies on an API doesn't do much when the problem could be any number of upstream (or depending on the situation downstream) systems.
@@dbob132 What a ridiculous statement. Wow! Lol. The smartest guy in the room, huh?
@@dbob132 Interaiton failure tends to be exactly where I want a debugger the most, because I want to see what values are wrong etc. But making a debuggable system is hard.
@@dbob132 Also, webdevs have access to debuggers built into the browser so why do you need to bloat your plain text editor with one. I debug occasionally writing web apps, and I do it with chrome's dev tools. Another positive of decoupling debugging GUI from text editor is if I ever decide to change editors I don't have to relearn the UI for debugging. Nothing wrong with debuggers, but having them decoupled from the editor is a huge plus in my book
Man, I love this format of interviewing. None of this is dumbed down. These talks are excellent. Hell yeah, Lex!
the mirror techinique - just repeat what the guest says
@@FunkyTRAnd have the guest be John Carmack.
Developer: these statements are ridiculous! No one believes this crap! 😡
John Carmack: I wrote Doom.
Developer: You make a compelling argument 🤔
I've been programming professionally for 30 years. When proper IDEs came into existence, it was a "halleluiah" moment in developing. Why anybody wants to make it harder on themselves I have no idea. Now with stuff like intellisense and code analysis, code is much more rock-solid than it used to be.
You really have no idea.
@@kuromika_ Vim is an execption tho, but some people exagerate.
I think there is just one negative side for IDEs its slow and if your machine not good its slow as shit
To understand you need to take the point of view of someone who started programming 5 years ago.
Learned programming in a high-level of abstraction, used the mouse for pretty much everything, and some day you realize that you don't really know how computers work and that's going to :
- Prevent you from becoming a competent CS engineer
- Make your life really hard in the long run
- Prevent you for applying to higher-paying companies
- Make you dependent on unstable and fast moving libraries (i.e: stuck with react web FEs)
.......
For the youth today, using text editors and POSIX shells, is about learning how computers work to become a better engineer, but also learning how to touch-type, learning better keyboard workflows (vim keybindings are useful even in modern IDEs) etc.
I understand it's a reality very far from what someone like you, that probably programmed in C in the early days, experiences. You already have all this knowledge.
As of myself, I'd been stagnating the first years of my career because of over-abstraction. Using vim and bash forced me to learn the Linux OS and many other things that really made me happier and gave a boost to my career.
Yes it's about making it harder on yourself, but only for you to grow.
@@e.c-machiavelli9659 The difference between an old version of Visual Studio and a new version is that the old version is not written in C#. That's one reason, why a new version is often slow, but not the only one.
As an embedded developer, the debugger is invaluable. You can only debug so much with a blinking LED or sending data out via SPI or on a UART, if you're lucky enough to have that on the hardware you're working on. I mean I've done it, but only when there was no other option.
If you’re lucky, you could debug using Visual Studio. That’s assuming the codebase supports compilation and has enough infrastructure for a simulated environment.
I also write code for embedded systems and have done so for almost 40 years. For at least 30 of those years, most of my development has used in-circuit emulators with integrated source debuggers. The user interfaces back then were TUI instead of GUI, but otherwise very similar to today's VScode. So I was shocked when Carmack suggested that "hard-core" programmers look down on IDEs and visual debuggers. It just ain't so and never has been.
Ok interesting, i do embedded stuff to and basically live in debuggers full of memory and timing screenshots. It's usually USB or Ethernet nowadays, especially UART over USB like you find on most ARM chips.
Haven't used LED's in a while either. Toggeling an LED is still a good technique to benchmark code sections but i prefer more sophisticated HIL tools today.
A debugger is absolutely invaluable, but that doesn't mean you're locked into using Visual Studio. You can absolutely leverage Vim/Emacs, GDB, and other powerful Unix tools for debugging - or you can choose the rich feature set of VS. The point is, debugging is essential, and there are many effective ways to do it. Find the workflow that empowers you the most!
Wouldn't it be possible to target a VM and debug there?
Finally someone that makes some sense. I've seen so many "ex-google employee" etc videos where they advertise programming with sticks and stones because that's what the "pros" do. I worked as dev for over a decade now and always wondered if they're trying to troll.
someone that makes sense? that 'someone' is the benevolent hyper intelligent architect of the post singularity simulation we all live in, John Carmack.
What's amusing is that so many of these types think linux on the command line is a superior environment for programming, as if gdb and valgrind were actually good tools one should aspire to use.
@Rick Carmack is a smart guy but you don't have to worship him.
@@isodoubIet that's a joke from Civvie, a TH-cam channel that makes gameplay of 'boomer' shooters such as Doom and Quake.
@@cykes5124 Debugging with gdb and valgrind is generally a horrible experience regardless of what you're doing.
@@cykes5124 gdb's failings have nothing to do with what it _can_ do, but rather with how its user interface is clunky, undiscoverable, and all around cumbersome to use. Contrast the experience with something like visual studio where it's hard to find some place to rest the mouse where it won't end up inspecting some variable. It's easy to use and hard to misuse, whereas gdb, valgrind and its ilk are the opposite.
If you happen to work in a field where nothing better than gdb exists, sucks to be you I guess, but that's not because gdb is good.
I think a big part of why programmers at the bigger tech companies tend to avoid debuggers is because those companies tend to be the first movers into the big, complicated microservice/service mesh/distributed dev-ops heavy architectures. As a consequence, they often have really complicated in-house stacks running on huge clusters with protobuffs being pushed around to countless different places for any given action. With games, you at least have the luxury of running everything on a single box. Of course multithreading is still a problem, but your IDE is going to have visibility to most of the code you're actually concerned with. On backends where a call flow can take many jumps between different services, you're severely limited with what your debugger can actually see at any given time. I personally prefer to use a debugger, but I've found that I often have to write purpose-built integration tests or set up really specific scenarios just so that I can get a consistent point to step through the code from. So I can see how the aversion to them could be a sort of adaptation to the environments that a lot of devs at large tech companies are developing in. Then again, I'm not John Carmack. I'm just some dude on the internet
There is some truth to that I guess. Though probably the real reason is some misguided idea along the lines of "real programmers don't use debuggers" which of course is stupid.
True(ish) but misguided. You can still take advantage of debuggers for the small part that you do have access to, and there's also remote debuggers to extend that reach a bit further (still not all encompassing as if it was all run in a single box, but better than nothing).
If you have a problem you'll still have to debug, and with an IDE and integrated debugger you at least have that level of control on that portion of the code, even if you don't have over the rest... it's limited but like I said, better than nothing.
On the systems we worked on the software ran on servers that had no graphical interface and there was no way to remotely connect any kind of debugger IDE to the running software.
@@Ian-eb2io "no way" is impossible
@@miraculixxs I must not be a real programmer then. I always run in a debugger while developing. I look at myself as being human, and therefore, very capable of Derp! moments.
So much respect for this man. Lex this might be one of your best podcasts!
been in a super dark place, getting sober, going back to school etc, thanks for keeping me going with these convos. forreal
Soubds like you're growing a lot, keep it up bro ❤
Sir this is a Wendy’s
Just remember that nothing lasts forever.
That includes the bad times too!
When John hired me after I made Threewave CTF, one of the first things he did was buy me a copy of Visual Studio. Been using IDEs like that ever since.
Quake 1 CTF! Sooooo many memories. Thank you for helping get that "wave" started. Good times.
CTF was some good shit back in the days!
@@hurmeli I played a lot of threewave ctf, it was a blast.
Hey Dave, miss playing Diablo 2 with you - I created the Singing Barb, you came up with the "Electric Monk" Holy Shock Paladin, those were fun times. Threewave CTF was a blast. The memories, the memories!
Addendum, I was unaware of your name change, and I apologize - I intended no offense.
Been a programmer for over 25 years now.... I still to this day feel like a noob when it comes to programming. So much to continually learn and improve upon. I hate looking at older code for the pure cringe factor of what I was thinking and doing at that time. lol John is such a legend. Man, what I would give to be a fly on the wall watching him work. I'm sure most of us would learn so much just by observing his programming habbits.
I wish he would livestream his "retreats". He wouldn't have to look at chat, or interact. Maybe try to speak his mind, so we could follow his train of thought, but that's about it.
shows that feelings shouldnt be entertained, 25 years and you still feel like a noob? cmon man, almost 10 years now, wrote life saving code alone and even before that I got more confident with each thing id learn
@@claudiubele4892 you should look up the Dunning-Kruger Effect. :p
@@claudiubele4892 that means your growth potential is very limited. Or that you have already reached your cap in terms of skills.
You see... Knowledge only grows exponentially, more fields of study and deepening of the current ones. You however can only study one thing at a time. That means that inevitably, the ratio between the things you know and the things 'known' is only ever decreasing.
@@Michallote there's so much to talk on growing - growing right, grow rate, whether the right lessons were learned, etc
4:10 exactly this. Run the code, check its doing exactly what you want, examine the stack, every variable, etc.
One of my favorite things to teach new graduates and less experienced programmers is how to sit down and use the debugging tools in Visual Studio or Jetbrains IDEs. Conditional breakpoints, putting a watch on variables, and the ever powerful intermediate window. How anyone would ignore these tools, knowingly, is beyond me. You can sit there and write your print("i got here xx1234") all over your code if you want... i'll be busy actually getting stuff to work. Also, the code refactoring tools in modern IDEs will actively train you to be a better programmer and learn new language features. I understand the romanticism of sitting there in a console and banging it out, but you're making your life harder than it needs to be
Have you seen the delays on recent VS versions? There's a reason Remedy exists, and why it's called "Remedy". Moreover, unless you're writing technically trivial software, chances are most of your problems are concurrency and timing related. Good luck debugging that with your GUI debugger, or any debugger that introduces changes to timing. It's a question of culture - growing up writing kernelspace code, you use the console because your dev box is also your crash box and because of the difficulty of debugging (WinDbg isn't a lump of sugar either), you develop habits that make it unnecessary to debug your code to "understand it" (the correct time to understand it is at time of writing). What is then left are hard problems which are nearly all non-trivial or impossible to "just use debugger X". I like Jetbrains' IDEs well enough for dynamic languages and use them from time to time. C, otoh, when used correctly is just a high-level assembler and you need to know what you're doing. I get why someone who came up in a different culture likes graphical tooling and finds it hard to give it up, nor is it necessarily optimal - they would need to learn a whole new set of habits and it's not clear gains, if any, amortised over all future work would exceed the cost in time and incidentals.
@@paulie-g This is just a huge wall of cringe. I wonder how MS was able to remove their giant kernel lock entirely way back for Vista. While it took years and years for Linux to declare it gone. BSD is still struggling with it in some distros so who know where XNU is at with it. Seems like better tools lead to better productivity, even in the kernel and even with concurrency. Who would have thought? Apparently John Carmack would have thought.
@@gilbes1139 The common denominator there is manpower, not tooling. It's so patently obvious it necessarily follows that you're either a troll or a cretin.
This. I learn more from IntelliJ showing me better ways of doing things than I could learn on my own looking up documentation on some new language release version.
Showing people who have never used a proper IDE or debugger how to make the best use of the tool vs their print statements is like trying to explain cars to someone who has only ever ridden a horse
I came from a background of using IDEs and then worked on a system that could not be run or debugged through an IDE. We could edit the code in anything we liked of course, but it had to be compiled and run on a remote system.
1:23 Hats off to Borland! I think their Turbo Pascal IDE was an excellent environment for coding back in the old 80286 days!!! Their technical manuals were superb, also. You really could dive into the manuals and learn a lot about coding.
More effort was given into manuals in those days.
My first language was Delphi! :)
😂😂
Clearly the Firmament of all integer Integers. Pure primal coding with Pascal, as an IDE with it's own language.
I wonder if there is an undiscovered Easter Egg.
@@tru2thastyle Stack Overflow didn't exist ! Where else were you going to look ?
@@rustyhill7575Man, I miss Delphi still.
Have you done much C# development? The language was designed by the same guy who did Object Pascal and I've always said it feels like home! :)
What John talks about at 04:08 is what I do. And then after stepping through the new function I'll write a unit test for all the things that went wrong during the initial development of the function. Debuggers and TDD are a godsent for me.
Surprisingly funny and very informative. Carmack is a great interview.
This interview is a goldmine. Carmack finds words for concepts that are hard to put into words.
@@godsofohio6734 he's an incredible communicator
I've always been pretty good at debugging stuff, even other people's obfuscated code. It's nice to hear I'm not the only person running with debuggers connected all the time. Mostly I do JavaScript these days; I like to write code directly inline to check what I'm looking for is going to work.
This style of interviewing is great! I love how low level and technical these conversations are. Lots of people out there love hearing this kind of stuff.
John Carmack is a legend and it's so inspiring just listening to him 👍
I could literally listen to him give a talk about cardboard boxes and be glued to the screen. He's very charismatic.
You can tell his mouth is a limitation to the pace at which he speaks. What a guy.
have y'all read Masters of Doom? It's meant to be a great read!
@@thefulcrumIt's alright, but it's very different than a Carmack talk. It's an interesting Silicon Valley story to be sure but it's dumbed down quite a bit.
@@thefulcrumIt's alright, but it's very different than a Carmack talk. It's an interesting Silicon Valley story to be sure but it's dumbed down quite a bit.
Re: min 08:55, since Lex loves asserts so much, I would encourage him to take the time to tryout Eiffel and "Design by Contract", the language that takes asserts to the next level, with many specialised forms, each with their own keyword.
It's refreshing to hear a programmer that I've always looked up to reflecting my feelings on using an IDE like Visual Studio. My first course after high school was one in game development and I'm forever grateful that they had us using Visual Studio from day one. When I went to a more traditional university a few years later it was all about command line tools and print statements. I appreciated being taught how to use those tools, especially gdb, and the different way of debugging when it's just you and your code staring back at you. But I never understood why IDEs were so fervently ignored. I watched so many others struggle to get even simple C++ programs to work because learning the language was already a huge mental leap and learning when they got it right and when they got it wrong was too much at those early stages. I think it turned some of those students away from programming for good when some guidance from industry standard tools like VS would have gone a long way to helping them. I'm currently studying again and the university I'm at loves Linux and gdb, but for all the assignments I find myself using VS or VS Code and the remote debugging features with WSL2 to write and debug my code because it's where I'm comfortable, and I think ultimately it saves a lot of time.
@@tripplefives1402 Because both are what they were taught at the institutions they attended? I don't believe they're pretending like those are the only options, they're complaining about how those were the only options taught.
@russelg is on the money. I was simply relaying my own personal experiences with various educational institutions. I wasn't pushing some manifesto in the hope of bringing more people over to my Visual Studio worshipping cult.
Yes, my undergrad was the same. A lot of bias against IDEs because they are “crutches”. I’ve never found that to be true. I’ve actually found the opposite, Jr Devs with bad habits going into the workplace and having to spend time learning how to use the IDE and debugger because the system they’re working on is exponentially more complex than the little school projects they did.
I’ve learned a lot and continue to learn from Visual Studio and IntelliJ giving me warnings or recommendations on line fixes. Even the simple ability to click into a decompiled external library class and see what that code is actually doing that you’re depending on is huge and a lot faster than trying to look up documentation
@@Joelyrancher1 it’s actually really unbelievable how many people are stuck in the past with their own ignorant views about vim or emacs.
You can navigate huge codebases with vim and emacs. Who ever said this is hard to do? Have you even tried navigating large code bases in vim or emacs?
In neovim there’s a tool called telescope 🔭 which allows you to navigate huge codebases with very few shortcuts that you can program to your liking in lua.
Emacs has a an even better tool but why bother mentioning it when people are so stuck in their ignorant backwards view.
Also, there’s gui representations of gdb that you can grab from the repo of your distro with a single command.
I really don’t understand how people think that vim and emacs programmers are stuck in the past with 90’’s dev tools, it’s so laughable 💀💀💀💀
This comment section pretty much shows the difference between real programmers (in the video) and the "look I made a toy project in Emacs/Vim in college that no one will ever care about".
Every time John Carmack speaks, it's time to pay attention. He's always got something useful to say. He's so right about the value of IDEs, I feel crippled when I can't debug PHP code on a remote Linux server or I have to resort to printing of variables to debug something. It's lazyness, because it's hard to set up debugging in some environments. Visual Studio has gotten amazing with static checking of C# code. I should use it more, though I absolutely love VS Code because of how many languages it can support and how lightweight it is.
I've started using static analysis right in 2022 and it's quite awesome
This is just a lovely down to earth chat and very nice to know my setup and methods are similar to Johns ;)
As a unix admin I use vi (not vim) - it works on all flavors of unix. As a programmer I use visual studio code. The world is not black and white. Don't judge the tools people use. Admire masters no matter what tool they use 🙂
Always admire masters but then get sad that the master could be so much stronger with better tools.
vi is like your mom, always there for ya.
Life is too short to be dogmatic about text editors.
I must go down to the code again. To the lonely C and Py
And all I ask is good editor and a debugger to steer her by
In addition to debugging and assertions (as mentioned in this video), it's also very nice to have logs to help follow a live process up to an error. It makes finding the erroroneous code much easier.
they can make classes of errors disappear though.
Agreed. Good fail fast assertions and error logging should always be the minimal requirement for systems. Nothing worse than having to always depend on an IDE to troubleshoot issues.
Absolutely. There’s nothing like being able to have some idea what the user actually did last night when things went south, and being able to see some of the black swans flying around at the time.
I’m thrilled to hear a lot of this. It makes me realize my approach to coding is sound.
These are the same foundational concepts we learned at my University for coding. Glad I kinda got my money's worth but my professors were never actually in class so they left it to grad students who had no idea why we were doing things.
John is very humble to admit to the obvious that everyone makes the same types of mistakes. Sometimes it's about how much effort someone puts in. I found in my experience that there are varying degrees of how far someone will go down a rabbit hole to understand something. There is also a varying degree of how honest someone is with the "psychology of programming" or the psychology/process of learning. Understanding our fallibility is the first step. Second step is all the consequences of that fallibility. In my data science/data engineering programming, this means retesting, refactoring, making a little assumptions as possible even in the face of strong belief. I am always amazed at how counterintuitive things turn out to be after I think "maybe let's test this". I have become an empiricist because of this - nothing is true unless tested.
From a QA perspective, I really enjoy working with people like you 👌
So many devs overlook unit testing or even testing as a general concept and more often than not you'll end up with weak code that breaks the first second a QA tries to do something a bit exotic with it. This will imply debugging, fixing, re-testing, it's such a waste of time !
I use the modern IDE's, debuggers etc. But I also will do command line occasionally, to eliminate the feeling that IDE's give you of there being a layer of hidden magic going on. I want to do the magic (slowly) a few times myself. Then once am sure that I know the magic, then I can return to using the IDEs, with the feeling that I know what's going on under the hood.
Typically, IDEs are simply building and executing command-line instructions based on your project settings. The good ones show their work (as in letting you see all the arguments) and sometimes even let you edit the results.
VIP when editing is VI MOTIONS, all good editors/IDEs have plugins for vi-mode.
Learning VI motions (and macros) is one of the most useful things I did for editing skills and time saving.
Bind a toggle key while learning but take the time to learn it, big profit in the long run.
Then use your fav editor/IDE as you please. I hear you on debugging and special gui functionality, but still need the typing.
Add test driven/complemented development. Make tests for happy path, bad path and edge cases (like null). Then you have free inspection of your implementation through every iteration and refactoring of it in addition to language and static linting checks.
It's nice hearing this from Carmack. I _love_ Emacs (there is dap-mode now, of course), but debugging in IntelliJ has been super helpful.
IntelliJ is the one thing I miss since departing from doing any Java development. Great IDE. I now use VS Code 99% of the time on Linux / KDE.
@@JSDudeca have you tried KDevelop?
I like using the vim plugin for IntelliJ. Editing is fast, and I have the IDE’s structure, documentation and other tool panels available.
I also like how “ctags” style navigation works with the plugin. I can hit ctrl bracket to jump to a definition, repeatedly, then ctrl T to pop back where I was and continue.
As someone who lives in their debugger I feel validated hearing this from John.
Same! I have a senior who debugs (in Python) by raising exceptions with whatever variable he wants to read out, but that's simply not too compatible with how I work. Just use breakpoint() and then step through the code, print out values, etc, or use the abilities of your IDE's debugger.
Same, always check the behaviors that I expect in the debugger
I agree with you that modern IDEs have certainly demonstrated how much can be done to improve developer efficiency. However, the reason why plenty of people at companies like Meta, Google, Amazon, and Jane Street still use Vim/Emacs is because you can get many of the benefits of an IDE through the plugin ecosystem (and through Unix scripting - Unix tools are designed to each do one thing very well). These text editors are lightweight, portable (can run on a server for instance, on all platforms), and have their own useful featuresets (like Vim's great text editing and manipulation abilities
I'm a long-time -- as in decades long -- vi user. And also a long-time IDE user, starting with the Borland IDEs John mentioned, as well as Eclipse, NetBeans, etc. Because my fingers automatically remember the vi commands so I don't have to move from the home keys to a mouse or arrow keys, I would edit in vi, then compile and debug in the IDE. But I've been using Visual Studio and Visual Studio Code in recent years because they have the very best Vim extension ever, so I'm able to edit with my vi-savvy fingers without ever leaving the IDE. Now that VS and VSC are cross-platform, I'm rarely in anything else.
What Id give to hang out and listen to this man talk about code and talk about the development of doom etc.
I've been using Visual Studio for my entire life. It can be a slow, bloated mess at times, but intellisense and the debugger are just too good to give up. I tried to switch to vi last year, and even though I did manage to learn how to use it properly and get it set up with a lot of nice plugins, the lack of integrated debugging and intellisense completely destroyed my productivity.
I actually have the same thing, but I still use vim with Visual Studio as the debugger. So I write code in vim (mainly because I'm fast in it) and then I have a vim script shortcut (ctrl+s) that immediately compiles my code with msvc and then changes the window to Visual Studio for debugging, It works pretty once you get use to it.
@@khisrowhashimi That's an interesting workflow. I used to be good at those types of editors but succumbed to VS a long time ago (version 4, I think). A vim plugin may be available for VS.
The only alternative for me is Rider. It's pretty amazing.
I never used VS, so take my suggestion as is; Could it fit your workflow using a very old version of VS? Like at the end of the interview when Carmack talks about a friend that still uses VS6 ?
Maybe then it will be 'less' of 'a slow, bloated mess'. Then again, how much of recent workflows it'd support is a matter of your use, I never messed with .NET but if you
Visual studio is as good as it gets.
When I started programming in C (after a couple years in assembly language), the use of CodeView, especially in the mixed C/Asm view was invaluable to not only debugging, but also optimization. CPU cycles and memory were a premium commodity (in the 386/486 world) and CodeV was a necessity. Now commercial programs are sloppy and tolerate way too many "bugs".
Well, there are some sloppy ones, but I wouldn't get as far as saying that trading some CPU cycles and few megabytes of memory for development speed is sloppy, you just do that because the performance of most of the code you are writing doesn't matter on modern machine - only few choke points really need an optimization. Think about it this way: code is a bridge between humans and machines, it must be "good enough" for both species, if you write some tricky code that saves few CPU cycles, but you make multiple people reading your code spend thousands of hours to understand it or, even worse, find a bug in it, then it's not effective way of developing software.
It's all about features, not expert gold plated code.
You don’t really need to worry about that kind of stuff anymore on modern machine for the day to day stuff.
@@proosee This is an extremely dangerous mindset. Having a mindset that is not optimization-focused is the reason why so much modern software is genuinely bloated and broken, looking at Visual Studio and pretty much all Microsoft development tools (even just stock windows CMD) with a critical eye will reveal flaws that decreases execution time often times by orders of magnitude. Want examples? Try this: th-cam.com/video/hxM8QmyZXtg/w-d-xo.html , this th-cam.com/video/GC-0tCy4P1U/w-d-xo.html, and this th-cam.com/video/r9eQth4Q5jg/w-d-xo.html . Sure, these are all from the same person, but the things that he is saying are undeniably true and he provides alternate examples of how everything wrong with Visual Studio can be done. We don't need to sacrifice optimization for "good enough" performance. Maybe, we as developers should grow up and care a little bit more about the code that we are putting out, or at least we could get corporations to care more about quality rather than meeting deadlines. We used to care, now we don't. The same types of software that took X seconds to run in the 1980s-90s takes X seconds or even longer to run on modern machines that are hundreds if not thousands of times faster. There is a problem, kidding yourself and saying that cutting corners is OK is ruining software quality.
@@h4ze979 I never said optimization is not needed. Read again and comeback when you understand arguments I made.
Love the clips. Sometimes I need a Lex fix, but don’t have the time to hop into a podcast!
I am glad I have applied my outlook on life to programming. While I am happy to hear what others think my life is all about me and my boundaries, comforts, and tolerances. I started programing in compiled BASIC and then VB6. After moving on to C/C++/Java/Scheme/Ruby/Python/Etc I still really appreciate a full IDE with built in debugging as it works with my mind set to produce working code the in the most efficient way for me. I appreciate that other can and do use "stick and stones" tools becasue they perfer that but I also get the strong feeling it is more about being "seen" as a real serious programer by doing so rather than it is truly better. I also don't apreciate the condesention I have received from other programmers becasue of my work modality. I conquer it by producing good code, my way, in reasonble time, predominantly trouble free.
@Dave B Far more often than not I meet or exceed delivery requirements. In most cases where I havent, feature creep and realtime constant evolution of project spec is present. In that case I make sure that client understands the time (and cost) consequence of the situation. I make my timeliness accoutnability for project with all changes factored in. This is not to say thast clients are still not unhappy at times. In fact many want all changes for original time and cost budget. I however don't deal in fiction, I deal in reality so some jobs are lost altogether. Some are completed with me meeting my own accountability standards but client was still uinhappy. Thankfully most have been fully satisfied while allowing me my own standard for accountability. I am unsure if this is anythihng like an "average" experience as I work in a very narrow industry supplying very specific, and mostly on the smaller side, single delveloper projects. I have little team or full on enterprise development experience. The litte I have had was mostly a "tag your it" situation where I got handed a project that needed my unique experience to complete or I was the only one left to do the job. I was also a hardware engineer which lead to me becoming a programmer out of necessity. Over time I was asked more often to help get a project unstuck or completed under deadline stress. All these factors have lead me to do freelance all on my terms. I certainly losse out on my more than my fair share of easily doable jobs becasue I refuse to engage in work without concrete terms and contingencies. But I can say I still like what I do.
I agree with you that modern IDEs have certainly demonstrated how much can be done to improve developer efficiency. However, the reason why plenty of people at companies like Meta, Google, Amazon, and Jane Street still use Vim/Emacs is because you can get many of the benefits of an IDE through the plugin ecosystem (and through Unix scripting - Unix tools are designed to each do one thing very well). These text editors are lightweight, portable (can run on a server for instance, on all platforms), and have their own useful featuresets (like Vim's great text editing and manipulation abilities).
Unix tools are in no ways "sticks and stones". You just have to learn the benefits to them
Incredibly humbling to hear these words from one of the GOATs. When Carmack tells you that there are no inhuman gods among low level programmers, you better believe him.
Debuggers can do much more, for example conditional breakpoints can help catch rare bugs that only happen once-a, under certain conditions, where stepping doesn't reveal the problem. And I've seen the resistance of programmers to use them, especially in real-time programming, where the debugger can be a bit clunky and require setting up.
That was when I needed a debugger. Most of the time I found stepping through extremely inefficient.
Module testing was where I would find and fix 99.9% of bugs.
@@RobBCactive I'm a beginner programmer. What is module testing? How's that different from unit testing?
@@encapsulatio consider it as equivalent, specific testing of the software part in development, as opposed to integration testing.
Professionally the term unit was never used in my software engineering, though it was a term on the commercial software side of my Comp. Sci. course.
Good luck with your programming!
I agree with you that modern IDEs have certainly demonstrated how much can be done to improve developer efficiency. However, the reason why plenty of people at companies like Meta, Google, Amazon, and Jane Street still use Vim/Emacs is because you can get many of the benefits of an IDE through the plugin ecosystem (and through Unix scripting - Unix tools are designed to each do one thing very well). These text editors are lightweight, portable (can run on a server for instance, on all platforms), and have their own useful featuresets (like Vim's great text editing and manipulation abilities. You can use debuggers anywhere
Get the best of both worlds by learning and using Vim keybindings in a modern IDE of your choice 🙏
this is an incredible interview.
Truth! The faults written by programmers are the same across all trades. Humans make many mistakes. Most people are in denial, believing they're perfect. We all must be humbled, and should operate on the premise that faults are occurring in everything we do. Attention to detail, and self-auditing are attributes too many people lack.
Guy is so right about debugging. Sometimes it isn’t always convenient because it can require you to recompile.
I've only started getting back into programming, as a hobby, it's so fun because you see progress
Vim is great for visual mode and it's c bindings. Though I agree it needs to be a lot more friendly and easy to configure. Don't get me started on the fact that c+p c+c and c+a don't work out of the box as expected! I do like using it with vs code
I love using the debugger in visual studio. I use it heavily when I'm trying to figure out how to work with data. I'll start to write a function that sends a web request, after I get the data I'll set a breakpoint, then I use VS to see what the data looks like and figure out how I'm going to parse it.
Yeah me too. When working with MVC and something isn’t being displayed in my view I’ll put breakpoints after I retrieve data from the database and after I pass that data to the controller to see exactly what’s happening. I don’t think I’m intelligent enough to figure it out without being able to see the data at each step of the process. I mean it would be stupid not to use those kinds of tools right? It would take me days to figure out these problems without a debugger lol
Also not to mention intellisense and code completion and all that nice stuff. I get that it’s good to know how to write things on your own but after you know what you’re doing, why not use the tools to make your life easier?
@Tony-cm8lg 😅 for me the "you have to know how to write by hand" is the modern way of saying "you wont always have a calculator around you". With my phone i have access to a supercomputer by old standards 24/7, and with tools like gitCopilot or GPT you will have access to extremely powerful code suggestions and autocomplete tools.
That doesn't mean i can't do my math in my head or on paper, or that i don't know my go to structures in programming. It's just once i know when to use which tool i can practically scale it to infinity. So the effort to create something vastly complex get's smaller and smaller. But you really need to know your stuff otherwise you scale BS to infinity in an instance.
Exactly. Also if you’re programming generically it’s pretty much impossible to know the object without evaluating it at runtime
I agree with you that modern IDEs have certainly demonstrated how much can be done to improve developer efficiency. However, the reason why plenty of people at companies like Meta, Google, Amazon, and Jane Street still use Vim/Emacs is because you can get many of the benefits of an IDE through the plugin ecosystem (and through Unix scripting - Unix tools are designed to each do one thing very well). These text editors are lightweight, portable (can run on a server for instance, on all platforms), and have their own useful featuresets (like Vim's great text editing and manipulation abilities
He has a good point about debuggers. I have definitely seen that in the more Linux-y kind of programmers (which e.g. Google has a lot of) who just never even thinks to use a debugger, and only begrudgingly uses gdb when they really need to, whereas my first reaction would be to use one to inspect the code (even on Linux you can use VSCode to debug code now). And this is coming from a Vim fan/contributor myself (I have no shame in using an IDE when the situation calls for it).
I do wish Carmack tried modern Vim or Neovim instead of Vi though. Vim came out in 1991, so he's literally missing out on 30 years of continual progress (Visual Studio wasn't even out back then) so him trying Vi was mostly just a historical detour… And also because there's a larger move by some of the (Neo)Vim folks to try to incorporate more utilities to combine Vim's raw editing power with more IDE features. This could be done by either writing plugins to talk to Language Server Protocols / debuggers, or directly embed a core Vim editor into a more full-fledged UI.
I haven't used a debugger in years, but guess you can dynamically insert a breakpoint without restarting most programs, might be a good practice worth revisiting. debuggers are amazing tools, I wish I understand how they worked better.
I usually go with IDE + vim keybindings
Comments are focused on IDE, but I'd like to see a video exploring different developer cultures. Their differences, strengths, weaknesses, to learn the best that each has to offer. Gaming, Silicon Valley, defense, research, university, finance, etc. I am surprised he doesn't seem much into hardware. I could have spouted off my PC specs / brand / CPU /ram / monitor sizes / major app tools in 30 seconds in response to the first question, then ventured into the rest. All we learned was "3 monitors and visual studio." Windows running in Parallels on a Mac? Does he use VMs? Only one PC? OS version? VS version? I have ten computers in one room alone for misc. testing and training. I cannot imagine John developing on only one computer, but I suppose it's possible. Thanks for the interview, Lex!
Not only that, but his general desk setup and ergonomics. Even something such as a height adjustable desk and a comfortable chair has an impact on your work, even if you don't realize it sub-consciously. Most people don't realize the improvement until they actually make the change because they've become so accustomed to the discomfort they've worked in for years.
I love debuggers too, but if you follow the dependency inversion principle, you are sometimes lost in finding the implementation for the interface.
I actually started out with visual studio tools, and over the course of 2 decades began working in more advanced and disparate environments with all kinds of security and resource constraints that required me to drop the IDEs and windowing systems altogether. These days if I can get on a bastion host or embedded box that's got docker installed, I feel spoiled to be able to pull down an image with all the niceties I've built in my toolbox. Muscle memory for the UNIX toolkit can make someone a 1%-er in any environment, but it's an investment.
Indeed, get good at Unix tools and you'll be so far ahead of so many people
Well, so much for his monitor set up
I love this guy, he is a true role model...
Nothing quite like stepping through that perfect code you just wrote to keep you humble.
Nobody talks about this stuff. Thank you, thank you. You're having the discussion I've only had with myself.
I grew up with Second Life, which doesn't really have a debugger, so I was forced to do all the inline debugging and recompiling because of it. As a result, I didn't really learn the importance of a debugger, despite knowing they existed. I always figured "I can just view the log and see what is going on." It wasn't until I ran into situations where the logs were failing and unless I viewed more of the stuff in memory, I wouldn't be able to solve the problem.
I feel a strong chunk of why the modern culture of "no need for debugging" is based on something similar. When people start learning programming, it's with flows and usually shown debugging very later on, rather than early. We're shown how to print "Hello World" but never how to break through it. We know how to put text on a screen, and that comfort becomes the only thing we come to respect, rather than the tools that actually help us.
"Your head is a faulty interpreter" are words to live by.
Indeed, 4:05, for anyone looking for the quote.
You can tear my Jetbrains IDEs out of my cold dead hands.
My computer literally shut down the two times I tried using vscode in it so I learned to use and love Neovim. I have a good debugger plugin in it. It was very hard to install and make the debugger work. But it's super easy to use and I do it all the time.
Carmack is 10000% right about just using a debugger. One thing I like to do is keep a second terminal window open that I just run GDB in with GDB-dashboard.
It’ll put you leaps and bounds above those who don’t even know what GDB is.
14:03 -- old school game dev guy that still uses Visual Studio 6. Would that be Sean Barret, creator of the stb libraries that he's referring to?
"Civil War reenactment phase"!!! That's perfect! 🤣
I've been using vi and gdb for over 20 years... debugging is easy and one of the first 'things' I start up when I start programming.
Asserts to remind future self when assumptions have been surpassed is quite the priceless nugget. Loads of insightful reflections from a great man. Excellent interview Lex, appreciate your work immensely.
Love these programmer ones.
Yes, I'm always a bit worried that he will become to big and stop talking about the more nerdy stuff.
It's actual good content when he's not interviewing white supremacists
You can integrate a debugger into Neovim that works at least as well as the ones that come bundled with some IDE's. It's just that you have to set it up first.
Any speicifc names I should Google?
Just found this interview. Carmack wrote the engine for the Xeen series back in the day of 286's, I believe. Brilliant coder and mathematician, and Lex, of course and always, is brilliant in his own right in every interview, tech or not. This is a thoroughly satisfying interview with all of the right questions and high points (although being dismissive of hardware always hurts - with my observation that Si Valley "tends towards" hardware engineers vs coders. LOL)
This guy had a MONSTER wide screen CRT in the 90's! check out the 28HD96
This takes me back to Julie Zelenski's gdb "Zen of Debugging" sessions that effectively showed how to get a trace of what was happening in Objective-C.
could you elaborate a bit more about these sessions? what exactly were they? I can't google anything with this name.
My peace treaty was VS code with Vi key bindings.
DTrace is a comprehensive dynamic tracing framework originally created by Sun Microsystems for troubleshooting kernel and application problems on production systems in real time. Originally developed for Solaris, it has since been released under the free Common Development and Distribution License (CDDL) in OpenSolaris and its descendant illumos, and has been ported to several other Unix-like systems.
Only halfway through, but based on his sentiment around debuggers, IDEs, and trusting computer analysis over programmer analysis, and his C/C++ expertise, I’m curious what his opinion on Rust is. Since Rust heavily leans on the compiler/tooling to check that the code is valid
I got into coding in the last couple years. I use Vim to do minor edits of config files because its quick and easy to work out of the terminal for basic stuff, but I can not imagine not using vsCode when I'm actually sitting down to do actual work or studying. Its tough being newer in the Linux community because I feel like its kind of blasphemous to like vsCode but damn its awesome. I guess I just don't see the point in switching to something else, especially considering Code OSS is open source.
I know how you feel. It does seem like the Linux community tends to have a lot of elitists who think if you're not using Vim, Emacs, or Nano, you're a sinner. But I'd say that's only because they're the most vocal ones. What you don't hear about is the regular devs who use vscode / intellij / whatever, because they don't have anything to prove or just don't care. They're just trying to get work done.
Use whatever feels comfortable for you, that's what's important. They all have their pros and cons. If you feel more productive using vscode, why change? I've seen developers who use vscode, IntelliJ, and even Sublime Text, and they're some of the most productive people I've seen because they are comfortable with their IDE. I know of at least 3 developers who mainly target the Linux audience, are Linux users, and they use Sublime Text because that's what they like.
Talking about slow IDEs: I would love to see Casey Muratori exchange ideas with Carmack. Casey has been on a crusade against slow IDEs and terminals - getting pissed that Microsoft said making their Terminal faster would be "a doctoral research project", he built a faster terminal in about two weekends, just to prove them wrong. It's called "termbench"
Except his terminal couldn't even render things properly. Casey is a clown. Though the microsoft terminal is still shit but its better to compare it to something like Alacritty
@@poni-sz2pm he did that project in a weekend or two. It's fine it didnt render everything perfect, because that wasn't one of the goals...
Interesting you called him a clown, because now I'm curious if you can do better in the same time. Put or shut up.
@@poni-sz2pm Calling someone a clown for their 16 hour project not being perfect is maximal projection
@@NostraDavid2 I'm calling him a clown because of the 'drama' not because his terminal is shit
@@poni-sz2pm What possibly could have prompted you to call Casey a clown? Are you OK?
1:36 Exactly, thank you.
I love to hear John Carmack talk about how powerful working with a debugger is. I always tell this to my team and young devs. It's crazy to me how many professional developers don't use good tools.
Vscode is a good balance between vim and a full slower ide, you can incrementally add features through extensions specific to each workspace, or keep it lean and mean. Like you can still have a good Java debugger, or have a widget tree visualizer for flutter, or like just syntax highlighting and a terminal
You could do the same and even more to vim...
@@dizzy2020 Even if they abandon it, I highly doubt it will disappear. VSCode is open source, so if they stopped supporting it there's a fair chance someone else might make a fork of it and start working on it. But I can definitely see them doing something to ruin it. I already hate the fact that there are some plugins that only offer limited features unless you pay (such as GitLens).
Still VS Code is much slower than Visual Studio 6. It can do a bit more with but I've not had any dev environment as snappy as MSDEV 6.
@@andynn6691That's one of the great boons of SW development.
We managed to make software constantly slower, in a rate exceeding the acceleration speed of hardware - which is staggering!
I don't think vim/emacs and IDEs need to be framed as diametrically opposed. You can have vim with a language server plugin for intellisense (and vim 8 has built in gdb debugging). You can have visual studio with a plugin for vim keybindings. Some will prefer the vim experience, others visual studio, and thats okay. I'm sure it is similar with emacs although I am not as familiar with it.
I've never seen any features in an IDE that I couldn't get in vim/neovim with the appropriate plug-in. The primary reason for choosing an IDE over vim or emacs is simply that the IDE will make a lot of choices for you so you don't have to think about them, which is perfectly legitimate. Programmers just need to understand that they are giving up a great deal of power by letting the IDE take care of most things in their environment.
@@zenshade2000 Personally, debugging and profiling have been a more clunky experience for me in vim even with plugins like vimspector. For linux I can always use command line utilities for these things. But windows on the other hand... lol.
I do have faith that I can always get vim/nvim to implement an IDE feature even better than the IDE can, but sometimes the time cost of configuring it is not worth it. Anyone who has ever had to debug a vim plugin will know what I mean. Also some people just like the IDE experience (color scheme, buttons, hotkeys, etc.). Aesthetics and UX preferences are just as important considerations as speed and power when you have to code for 8 hours a day.
@@rdd-technical6824 I fully agree that configuring these types of excusable text editors, comes at the cost of time. however I would like to point out an alternative to ether spending time configuring editors / just using an IDE and that's preconfigured editors.
I used to use vim and I loved it however I had to agree that it took some time to keep configuring so I switched to doom emacs. now all I have to do is uncomment a few lines to get it to where I had my old editor was at and if I ever wanted to spend more time fine tuning I still can.
I think what really matters isn't if you do or don't use an Integrated Development Environments, but instead if your Development Environment is good enough. its just tools at the end of the day and I don't think it matters how those tools are packaged or by whom they are packaged by.
@@solidsumo1976 Thats a great point about using a preconfigured editor. Also love your philosophy about development environment as a tool, it makes a lot of sense. Thanks for sharing this.
@@zenshade2000 jupyter notebooks :(
Good IDEs and debuggers is what changed my mind about programming - took an entry-level compsci class in college using Linux/C/no IDE... absolutely hated it. 5 years later, took a class using Eclipse/Java (okay, that was fine, got me more interested - like, I can do this, it can be a little fun)... and then took another class using Visual Studio/C# making a desktop app... and I WAS HOOKED. It felt like magic (intellisense, debugging, etc). Felt productive and happy. Never looked back.
very riveting question
People often assume that professional programmers at large corporations do things efficiently, using the best tech but that's rarely true. I have also noticed myself that almost nobody uses proper tools for development in c and c++. I can see my seniors navigating code in emacs, taking minutes to navigate code while I just use modern IDE with plugins and navigate the same code in 5 seconds. They are not really aware of valgrind and clang sanitizers either that can automatically catch thread race conditions and undefined behavior.
That doesn't mean you cant use emacs, but if you use emacs you should use modern plugins to improve your workflow (using language server for example).
emacs is really out of date, do they even still develop this?
@@Cenot4ph Emacs 29 has everything your modern IDE has + you can actually have maximum control over everything in your workflow. Neovim is even more up to date and has more plugins since it has more users.
Tmux, vim, linters and command line for me. IDEs do offer a lot of value in terms of incremental compiling and code completion. This in addition to debugger access.
You can pretty easily use a debugger and LSP inside neovim... John is talking a lot of BS about vim, probably because he doesn't know the possibilities
I don't think he doesn't know the possibilities. I think people, even someone as talented as him, like to live with tools they're familiar with@@hugohabicht6274
You use linux most probably because you're a web dev. You don't need to work with a computer hardware anr ship your software to the massed of braindead windows users. That is why you can do tmux fzf blah blah blah. Been there done that.
@@friedrichmyers Nope, I'm an OS dev for a big company that uses Linux on their devices, you're on one of their platforms. Unless you're a game dev or Windows desktop OS dev you should use macOS or linux
@@TH-camd-jv5oi I still miss my unix/unix-based OS days but now I'm in Game Dev so that's why I need to use Windows. I still tweak around in BSD from time to time. However, I think most of this "fad" of using Tmux, Vim, Fzf, etc comes from the fact that the 90% of the web developers don't do any real work. Most of the problems are solved for them by the top 10% web devs who are actually making things. And I don't think that the top 10% developers I've met care a lot about the fad and just do whatever they like to do. But the 90% developers are the ones who are the loudest in creating the clout and making themselves seem superior. For most developers these Neovim configs are just a time sink.
All my python code is run in Visual Studio Code with debugging. Logging output with fail fast code style is often the only datasource needed but having debugger at hand is fantastic.
debuggers help so much understand the program flow, much more efficient than doing log statements everywhere.
The best questions anyone do to Carmack, seriously.
with the advent of LSP I feel like the gap between editor and IDE has really closed. I use an editor but I have smart autcomplete, rename etc etc right there if I want it. Maybe an integrated debugger would be nice.
That's where DAP comes in.
before LSP it was 90% diff , after lsp maybe close to 60% diff but still IDE are way ahead in some important features, also polish in IDE like Intellij is way ahead
VSCode + vim key bindings is nice.
Where can I go to find the best programmer ready to co found a start up with myself?
I used vim for 5 years. Switched to vscode a couple years ago. Loving it
wow everyone here is onboard visual studio
@@stant7122 I've never used visual studio before (I see a lot of people in the comments are into it). VSCode is a nice middle ground for me. I don't really use the debugger, or auto-completion. I just like the editing experience. And the diff editor is really nice :)
I also have caps+ijkl mapped to arrow keys on my laptop which makes editing so much nicer
@@abcd-jr5ek Oh wow, this is like the opposite of me. I really like the editing experience in vim (and the like, in my case kakoune really fit the way I think about text while editing) but the tooling for vscode is what makes me open it.
@@stant7122 I wasn't before this but if Carmack is on board, I'm on board. The man is a legend.
There is another way that also works quite well.
Use TDD to create and refactor code. Try to get 95%-99% of your code to be pure functional. Split functions using descriptive names (long names that describe what the function does - like a comment). That way your comments get refactored and are up to date. Using TDD+Functional allows you to use dynamic typing and a data centered approach. ("dictionaries" instead of class/struct)
What that does in essence is: you write your compiler checks yourself. You are not limited by the basic non extensible tools the compiler gives you. Functional+Higher-OrderFunctions+Data Driven/Centered allows you to forgo templates and makes the "generic" code much more readable and concrete. This also allows you to use the divide and conquer approach for things you never thought you could use it. Code becomes extremely modular. What would have been a class is a little module now with a clearly defined api. Each function is so simple that you can reason about it. Almost too trivial to write even a test for it. But TDD helps to pin the million little behaviors that you want to keep and know are correct.
That was the spiritual awakening moment for me. We are all so used to the limitations the current tools and think that is the only way it ever can be. It was like learning programming anew for the second time.
If interested check out Uncle Bob (TDD), Rich Hickey (Functional and Clojure). It takes a couple of month to wrap your head around it but it might be exactly what you were looking for.
Well said. I’m glad you called out TDD. I was reading through all these comments and couldn’t believe nobody else brought up TDD. 👍🏼
vim and neovim extensions works great with vscode
That's my major complaint about VS Code too, that even on preposterously powerful hardware there's friction and lag between my brain and its streaming of the code into files. One of the reasons I secretly use Sublime for real productivity and then use VS for learning new things and experimenting.
I agree with him about debuggers. In my experience, a surprising number of otherwise competent programmers don't know how to use a debugger.
I use IntelliJ and it feels like I'm coding with Swiss Army Knife. I love the refactoring capabilities!
I switched to Visual Studio Code and i'm happy with it.
Very interesting. Ty