Each was going to kill Emacs.
Somehow, I think I'll be using a version of Emacs until the day I can no longer type.
Meanwhile, everyone else is wasting months getting up to speed on the latest and greatest thing every 8 years or so.
This adds up over a career.
Oh, and by the by, this was written in Emacs using GhostText as the link between Firefox and Emacs.
Yeah I used to think this way, because you're right: becoming proficient in emacs takes significant effort and time.
But becoming proficient in VS code takes maybe 25 minutes. 25 minutes to change IDEs every 8 years or so doesn't seem like an onerous requirement to me.
Emacs just has extremely poor defaults and out of box UX.
Becoming proficient in kicking a ball takes 5 minutes. Becoming proficient in football takes slightly longer. Magit alone makes VS Code look like a child's finger painting.
Magit is indeed a great git client, but I don't see what that has to do with emacs having bad defaults and an out of box experience that could be charitably described as antique.
When you've been using the same thing for 20 years changing defaults to be trendy isn't a plus.
You'll understand in 20 years when you're on your 4th IDE which will change the world^tm.
And it also means obsolete.
>You'll understand in 20 years when you're on your 4th IDE which will change the world^tm.
How condescending.
But no, I probably won't mind changing editors every few years because I am capable of learning new things and do not require a safe space to keep me insulated from the outside world.
So there is nothing wrong at all with switching to a new editor… it just means things are getting even better!!!
He's right about the defaults though. Use something like Spacemacs or Doom if you just want to dip your toes in the goodness that is Emacs.
One header read: "Not better enough". Inasmuch as Visual Studio Code does anything better than Emacs, it doesn't do things better enough to justify expending the high activation energy of switching, unlearning my Emacs workflow and learning all that I need to know to do things Visual Studio Code's way.
Recent research has confirmed that this is an actual phenomenon: https://link.springer.com/chapter/10.1007/978-3-031-35017-7_...
Discussed on Hackernews: https://news.ycombinator.com/item?id=36721055
If IDEs help you work better, that's great. Do not presume your experience and preference generalize to all.
The one exception is maybe untangling particularly gnarly git conflicts.
Not really my thing but I guess it works for them.
There's no way to unify it given how many different moving parts are involved. Trying to fit this all within an IDE would be a project of its own...
* rg with telescope window to quickly find text in very large code basis is essential.
* Pressing spc, spc, to bring up a telescope window of my open buffers and typing in text to narrow them, very important.
* To date I still struggle to get the LSP to work the Linux kernel on VSCode, but on Neovim I got it working.
IDE's have a lot of menu clutter that I struggle to make good use of-most programmers working on user-space apps, it is likely fine, but for the kernel, we often need more control.
First I've heard of this. As a long-time vanilla Emacs user, I'm using consult-ripgrep and rg-project for ripgrep interfaces, consult-buffer for fast buffer and file switching, Eglot for LSP integration (mainly with clangd), etc. I've also got org-mode for note taking, magit for speedy Git manipulation, etc.
And all without any visible menus or clutter.
I suspect that a power Emacs user and a power Neovim user are more akin here to each other than to VS Code users.
Spacemacs got me into mnemonic key bindings, but it was too buggy and development had slowed. I got some things working with Doom Emacs, but it had a lot of bugs as well. Part of that reason is projectile also seemed to no longer be worked on. They were converting over to project.el but that seems to be slow.
-- debugging with print statement because they don't know how to use a command line debugger
-- using find and grep to find files/methods
-- hand-formatting files because they don't have a inline formatter or something to notify them when they've missed a semicolon or spelled a method wrong.
I strongly encourage them to move to an IDE because I can't stand looking over their shoulder and watching them code so inefficiently. There probably are vim plugins to handle many/all of these things, but if a developer doesn't put the effort in to find them than they're just hurting they're own productivity.
Besides, typing speed is usually not the limiting factor in programming speed. I think overall efficiency needs to take a broader look.
The fun begins when you can't debug by printf because the buffer is shared by multiple processes that change it while the printf command is running.
- Do you know which service tier has the issue?
- Can you halt one thread that sees the issue, not all of them on an instance?
- When the request times out, do you have to start over and make another prod user sad?
I see your point though. I guess I just disagree with the premise that using an IDE will increase productivity.
The developer will always have to invest some effort into learning the tools, be it find and grep or an IDE.
As for the click: all IDEs and all code navigation tools for popular text editors like vim or emacs have full keyboard support. And M-. Or F2 or whatever are much quicker to type than "grep function_name".
I was like that about 20 years ago, working with Eclipse and later NetBeans for Java and Visual Studio for C# .net v1 (anyone remembers whole tomato extensions?).
I needed the IDE , the autocomplete, the debugger and all that. Nowadays, I do mostly Vim and Vscode for more complex projects. I don't know why, but I "grew out" of needing an IDE.
Some features that I do not have in nvim, but use daily in IntelliJ: Run configurations, proper debugger, SQL integration, hot reloading, and most importantly everything just working OOTB (auto complete, snippets, docs, ...). Can (n)vim do these things? Probably, but it'd take me days or even weeks to get it configured to the point where it's as seamless as IntelliJ.
I do use the IdeaVim plugin, so not all of my muscle memory is wasted.
ive never seen any vim-with-plugins setup come close to this
Whereas with VSCode, I really never have to leave the VSCode environment to do what I want. I can pop open a shell within VSCode and don't have to switch windows. I can easily open random files not associated with my project and VSCode does the right thing (usually). It opens images easily, renders markdown well, etc. my favorite feature is that you can pipe cli output directly to VSCode in the shell and then it opens a tab displaying that output. You'd be so surprised how often that feature comes in handy.
I really hope you’re wrong about that. I don’t want to be ruled by another Microsoft product
Example from VSCode Terminal: $ echo hello | code -
I think you missed the point of my comment you are replying to. You can get things done in any editor. The point is that Vim/Emacs have been around for decades and last your whole career, VSCode has been around for a fraction of the time and killed off the previous editor, Atom, that everyone though was "the editor".
I would definitely much rather install VSCode or an IntelliJ product on a Jr's machine, show them how to setup their terminal, get their dev environment setup, how to run and debug the app, and off they go. Edit code. Run code. Debug code. Rinse repeat.
Much more reasonable and preferable to having them spend months learning Emacs. Let's remember, they likely don't know how to use the terminal either these days.
Would that still be true if the ordering of your menus (and the items within, recursively) were randomly shuffled each day, and which side submenus opened on were also randomized? How about if the speed of your mouse or mouse acceleration behaviors varied?
I think you may be discounting memorization which benefits your workflow because that memorization is spatial rather than symbolic. Perhaps there's an argument to be made that such memorization is more natural, gradual, or easy, but there's definitely memorization involved in mousing around with any degree of efficiency or speed.
Which is a huge issue. If all you know how to do is crank up a GUI and write code, you are easily replaceable in a world where the demand for SWEs has gone way down. The best thing I ever did in my career is invest in learning how things actually work. Learning how something like Vim works is just a litmus test for absorbing and applying information quickly. Vim is just one in hundreds of tools I've learned how to use and string together.
I am also excited by the fact that the text editor configuration is programmable in a Turing-complete language, as opposed to pure JSON configurations that VS Code offers (correct me if I'm wrong, but settings are just a JSON file right?). It means that anything is possible.
In VSCode, my biggest complaint was that, for the Vim extension, the status bar was not configurable - I wanted to make the whole page change color when in "Normal" mode, versus "Insert" mode. Not possible in VSCode, but it's only a handful of lines of Lua in Vim.
Is that a huge productivity boost? No, but it makes me happy. Just as much as I want to be productive, I also want to be happy while programming
Just posting to balance things out for any entry level SWEs reading.