For C++ I never even tried it because I'm usually content with qt creator.
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.
It's sufficiently comical to be satire
If I care about that, I’ll probably care about Electron using hundreds of megabytes of RAM I shouldn’t even have to buy in the first place. It’s thinking like this that make people say sad things like "16GB of RAM is a bit tight nowadays, maybe you should go up to 32".
(Edit: to people who think buying a bit more RAM is no big deal: remember that our resources are finite, that computers are one of the most polluting industries out there, and the climate clock is ticking.)
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 tools we can find.
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 whatever, the sheer volume of the resulting electronic waste does not exactly increase my faith in humanity.
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.
I've configured $EDITOR to start `emacsclient "$@" -a ""` with necessary arguments (I get emacs frame instantly when necessary).
https://stackoverflow.com/questions/4458800/how-to-use-one-i...
JetBrain's IDEs are extremely slow and memory intensive - well beyond VSC and ST - and yet, complaints are always directed at VSC.
I like to be able to edit new text files instantly, and the simple, pragmatic solution, is to keep an editor always open in the background.
VS Code is not just mildly popular, it's significantly more than twice as popular as any text editor has ever been in the modern era.
Source, it's currently used by 74% of programmers (https://survey.stackoverflow.co/2022/#technology-most-popula...), the next highest text editor, since the survey started in 2015, was Sublime Text in its prime (2016) at 31%.
It's fair to call VS Code's popularity unprecedented and historic. And it's already being used to shape the future of the industry. E.g., we're watching the decline of local development right now (outside of specialized use cases) largely through VS Code's support for remote development features.
This is most likely just beginning of how VS Code will leverage its position to shape the future of programming.
74% of the respondents to the latest Stack Overflow survey, you mean.
Then it has to be Windows Notepad. Android does not have a default text editor, if it did then I'd agree.
I think you are missing out the part where it's technology developed continuously for almost half a century.
VSCode is very nice, but I quickly become frustrated by it's lag in comparison.
It does beats the pants of every other GUI IDE out there, with JetBrains IDEs coming a significant second place.
But Vim or Emacs with LSP are extremely capable IDEs and have unmatched speed compared to any GUI IDE you can name.
I do not doubt that they are. I use Emacs with a simple config as the default editor to open files with, but I do not know elisp to set up something more feature-rich, and have not felt the need to yet, but I would like to try some day. It is a truly unique piece of software with lots of love put into it, and it is also GPL which I like. The problem is just that the defaults are painful and I want to know exactly what my elisp is doing, and this would take some work. Yes I know that Spacemacs and Doom Emacs exist.
But my comment (the phrasing could be clearer) was about the choice of TUI vs GUI if one was to start creating a new IDE today, in response to the parent comment:
> 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.
In such a case my preference would be to have a decoupled architecture which would allow for both. You can make such nice things with today's computing power and graphics cards, that it would be a shame to not take advantage of it. And the performance can be stellar. We are talking TFLOPS nowadays.
The underlying problem with Electron is that browsers are also massive resource hogs and I don’t see people switching to elinks anytime soon.
Maybe I’m stuck in a cycle of consumerism - accepting slower software and buying faster hardware - but I value convenience a lot and in the grand scheme of things vscode using up like $5 worth of RAM is not enough to look for alternatives.
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.
I agree. The reason Electron got popular is because front end devs can quickly build a desktop app for use cases where a web app will not work.
And I say that as a web dev who has worked on probably a dozen apps with Electron. Mostly internal tools, but also stuff in production for end users.
For the end user projects we ended up replacing Electron with native apps using the native web view. Each app had a tiny native layer for stuff like downloading files, etc. I don't remember the exact numbers but our macOS app went from +100MB to about 5MB download. Memory usage was also great reduced. The macOS app barely used something like 15MB of RAM IIRC. That was in 2018. Today there are projects that already do this.
I think Maui will rather compete with Flutter and QT, not Electron.
I don't see this as a lot different than MacOS spraying .DS_STORE files everywhere. It's not a big deal to add to .gitignore, but it does leave a fingerprint. It's just that tries to determine reasonable defaults if the path doesn't exist instead of Netbeans/Eclipse/whatever forcing you to pick them with a wizard if you want any of the "real" features to work.
It's hard to start at anything specific :)
I haven't seen a single person who seriously used both and went back.
Search, VCS, keymapping, defaults, heuristics, refactoring wide of use, AI-based autocompletion - there's simply no real adversary.
Last time I was blasted when copying an old DB to a one in a new DB it correctly guessed the renamed columns based partly on type and size, partly on column names.
Also I love its suggestions so much that when learning a new language I always look at Jetbrains' respective autosuggestions - simply because it makes me a better programmer, faster.
The biggest selling point for me for vscode is good defaults (I like vanilla configurations to get started fast on new machines) and discoverability. I want to be able to install 10 plugins and try all of them in a few minutes, and learn shortcuts as I use the plugin (with emacs each extension is an investment)
I found use-package, try elisp packages make it easy to try new packages in emacs.
I use VSCode with a Vim plugin. I get all the best keystrokes from Vim, and the GUI of VSCode.
For me, going to Vim would be worse, and going to plain VSCode would be worse.
1: https://marketplace.visualstudio.com/items?itemName=asvetlia...
One thing I have issues with is autocomplete and using . to repeat the last edit (which includes the autocomplete). Other than that, all fine.
Edit: all the vim commands give me a huge advantage on productivity when editing. All the GUI with plugins gives me a huge advantage on project navigation. Would love to see anyone do better using either one or the other.
I agree. I just can't stand the git CLI, and love the GitGraph plugin in VSCode. But like you say everyone has their preferences.
unless you got both to work?
Vim multiline editing works fine :). Not sure what the VSCode offers thoug (maybe I'm missing out)
There are edge cases but I can’t think of a specific right now. When I run into one, which isn’t that often anymore, I’ll open vscode’s terminal panel and do a quick edit in nvim there.
I would also like his take on Pharo, which I like and many years ago released an open source NLP library for Pharo.
Not really: the linked text shows it is a costly strategy to avoid later «self flagellation»: it is meant to avoid the practice of mindless coding - of overly fast feature insertion, blowing amounts of low quality code to maintain. Torvalds: «I'd rather not work with people who aren't careful».
Also: «I happen to believe that not having a kernel debugger forces people to think about their problem on a different level than with a debugger ... that mindset where you know how it behaves, and then you fix it from there. [...] It's that you have to look at the level _above_ sources. At the meaning of things. Without a debugger, you basically have to go the next step: understand what the program does. Not just that particular line».
At no point has anyone suggested using the debugger in lieu of understanding what the program does and that’s a pure strawman. Understanding is step 0. Once you’ve done that piece, a debugger levels up your game. Same with other tools like profilers, printf debugging, EBPF debugging, etc. Hell, even simple things like executing the code in the first place / running tests / gathering metrics is a debugging tool. It’s rare that someone stares at a difficult bug until they see the matrix. It usually involves iteration cycles of some kind to test out different hypothesis / collect data and a debugger is one tool to speed up those iteration cycles.
There was a story on HN a while back about how one of the inventors of Ethernet had to hook up oscilloscopes to figure out what the electrical signal was doing to figure out why CSMA wasn’t working properly. An oscilloscope is an analog debugger and you can’t tell me that the inventor of Ethernet didn’t understand Ethernet or that the oscilloscope hampered that in any way, especially since the bug turned out to be very nuanced with a chip generating a spike switching modes.
That is not implicit: it seems explicit and literal. Apparently, Torvalds must have had different experiences - and evidently within a strongly different framework: it looks like the project manager in a drastic effort to propagate the will about what is part of the project and what is not.
— Brian Kernighan
I wonder to what degree this contributed to the eventual downfall of the platform. The learning curve was so steep and the IDE and tools placed so many mines under your feet so relentlessly that it must have driven some talent away.
(An example: you closed the emulator and it left over some running background processes that you had to fish out and kill in the Windows process manager. If you forgot to do that, you could restart the emulator, but breakpoints would stop working. But if you mistakenly killed another important background process, the restarted emulator would freeze and you had to restart the entire Windows.)
On the contrary, I just love working with JetBrains IDEs. The debugging functionality is so great that I feel no one is trying (deliberately or out of neglect) to waste my time. Given that I am 15 years older than I was in the Nokia days, time has become a more valuable resource for me.
We went through several IDEs, Visual Studio, CodeWarrior and finally Carbide.
I’m not saying the OS itself wasn’t complicated though.
If you are working on a relatively small or modular codebase for a long period of time Torvalds perspective makes sense, since the codebase will also benefit from that kind of introspection (ok Linux is not exactly small but excluding drivers is on the order of ~100k AFAIK, which is small relative to the time it's been active); id games are on the order of millions of lines of code (according to Carmack) and while the different engine generations are related they still draw a line under each one after a certain point and move on so they are also very time limited.
I enjoy playing computer in my head in fine detail on small code and find a lot of joy in small code. But I can also respect that on a large and unwieldy enough code base where it's necessary, it's going to make more sense to lean on a debugger and other tools more often.
I miss sometimes Emacs but i prefer to use VSCODE nowadays as its a much modern environment and brings me directly to the point of comfort. I also tried Neovim but i was not convinced to replace VSCODE, i mostly use it on the console for quick and dirty editing.
Now I like to have a GUI that has things like a right-click menu instead of having to rely on maintaining muscle memory for everything.
Of course, another part of that, I think, is becoming older. Mastering some aspect of the computer or software like Vim just isn't interesting to me like it used to be.
As a sidenote I wonder if he's ever used Pharo, it seems like the kind of thing he'd like.