Hacker News Reader

I think the way people use IDEs is a lot deeper than just reducing them down to "purist" or "ideologist". That sounds a tad bit dismissive for something that is essentially your trade tool. It's akin to saying all keyboards are created equal because they have the same keys. The way you lay the thing out and the perspective that you build it for matters quite a lot. Distilled in a quote, "the whole is greater than the sum of the parts."

I got used to JetBrains' key mappings when I was at my last company, I also adored their debugger. My new company uses VSCode and I started down the venture of remapping all of them to JetBrains keys. I ended up with a lot of collisions and things that no longer made sense because the keys were mapped using a different perspective when laying them out. I'm sure I'm not alone being in a pool of engineers that primarily navigate using their keyboard.

VSCode's debugger is better now, but it still doesn't really stand up to JetBrains'. On the other hand, launching VSCode on a remote box is much easier and their configuration is much more portable with their JSON based settings files. I like using VSCode, but it took me months to get up to speed with how I navigated, and more generally operated with, JetBrains' IDEs.

A person using Vim or Emacs has had best in class integration with the unix environment, modal editing, and remote development. Today, both editors have integration with VCS via fugitive or magit, fuzzy finding, LSPs, tree sitter, and code generation tools using LLMs. These tools have not stagnated, they've continued to evolve and stay best in class in many areas. So the "one tool is better than the other" argument doesn't really sway me. My point still stands that the community and open architecture are more important than any one editing feature.

> Equally, I can say purists or idealogists are so concerned with theoretical changes and breakages, and so afraid of the possibility of something changing that they miss out on game changing improvements to tooling.

Blindly following the crowd is also dangerous. Making choices based on principle is what allows good things like open source communities and solutions not swayed by corporations to exist, even though they might require more up front investment.

The problem with these tools is that despite having worked with computers for 35 years, I don‘t get them. My brain is not made for them.

I only use out of the box vim when I work on consoles (which is still a fair amount of the time), I can exit (hey!), mark/cut/copy/paste (ok, yank!), save, and find/replace if I must. Everything else is just beyond what my brain wants to handle.

A lot of Jupyter lab and some VSCode otherwise. I can‘t say I know all about those either.

The last IDE that I knew pretty well was Eclipse, in about 2004. I even wrote plugins for it for my own use. That wasn‘t too bad for its time, I don‘t quite get why it got out of fashion.

There are those of us that still use it :) productivity gains lie elsewhere. And running various maven and git commands from command line instead of clicking around... something about keeping the skills in better shape

> My point still stands that the community and open architecture are more important than any one editing feature.

No, it doesn't, because it's essentially a matter of opinion, not an objective fact that can be measured and proven. You prefer to have an open architecture and a community of enthusiasts. I prefer to have most of my editor features available out of the box, and modal editors just confuse me.

At the end of the day, developer productivity is not a function of their editor of choice, so what matters is that each developer is comfortable in the environment they work in, whether that be Vim, Emacs, IntelliJ, or VS Code.

Learning curves are uncomfortable, so by your logic we should all always take the path of least resistance and use the tool that makes things easy up front without considering the long term benefits of using something like Vim or Emacs. I find this to be counterproductive to having a great career as a software engineer.

Rapidly assimilating difficult to understand concepts and technologies is an imperative skill to have in this field. Personally, I find the whole notion of Vim being difficult to learn, or not "ready out of the box" perplexing. Writing some code that's a few hundred lines or less, where it's mostly just importing git repos, is easy. Vim has superb documentation. How hard must regular programming be if it's difficult to just understand how to configure a text editor?

It's not that configuring the editor is hard, it's that it's unnecessary—the only thing you've been able to identify that I'm missing by using IntelliJ is an ideology and a community, neither of which are important to me in a text editor.

If it matters to you, that's fine—use whatever you're comfortable with! I just don't understand why you feel the need to shame others for choosing to focus their energy on something else.

> I would much rather have to spend a few days to relearn a tool every few years and to get the benefit of that tool, than accept a lower quality tool just to avoid a few days work.

I've worked with engineers who studiously avoid configuring any sort of quality of life improvements for their shell, editor, etc. because they claim it makes things easier when they have to use an environment that they can't as easily configure, like sshing into a shared box without a separate user for them to customize. This mindset has always been hard for me to understand; not only does it seem like they're optimizing for the rare case rather than the common one, but it seems like they're actually just lowering the quality of their normal experience in order to make the edge cases feel less bad without actually improving them at all

> optimizing for the rare case rather than the common one

This has been a common enough case for me to not get too used to super customized local environments. I'd rather learn the vagaries of commonly available tools than build myself a bespoke environment that I can't port anywhere easily. That's not to say I don't do any QOL changes but I try to be careful about what I end up relying on.

I’ve usually had this attitude in the past and for me it came from my background: I worked IT, help desk, PC repair, etc for years before I got into programming and none of those contexts allow customization. And then for a while I did infra work where I’d be ssh’d into a vanilla VM or container instance to debug a deployment issue. Even though I mostly work in my own bespoke environment now, I still try to stay fairly vanilla with my tools. It’s pretty nice to be able to reset my workstation every year to get a clean slate and know that it’ll only be a couple of hours of customization to get back to what I know.

> I've worked with engineers who studiously avoid configuring any sort of quality of life improvements for their shell, editor, etc.

This is me. It's really easy to explain my mindset here, though. If I get used to a nonstandard tool or tool configuration, then it causes real productivity issues when I'm using a system that lacks that tool or the ability to customize.

This is not a rare edge case for me at all. I constantly work on a half dozen very different platforms. Having each platform work as much like the others as possible is a quality of life improvement, and improves the efficiency and quality of my work.

But isn't that why we have config files that you can easily copy to a new system?

But I guess you have to look at how much time you'll gain from your copying your personal config, vs the overhead of copying your personal config itself. If you often switch to a new system where you would have to copy the config file, but if you only really edit 2/3 files on that system for which a personal config won't have much benefit, then it is understandable. If I need to setup a new server for example, that doesn't need to be configured heavily, but just some installs and small config changes, and won't have to touch it anymore after that, then why would I spend time putting my personal editor config there? But if I have a personal computer that I use daily, and I edit a lot of code, it would benefit me greatly to optimize my editor for my use cases. And whenever I get a new PC or I get a PC from work for example, I can just copy my config and benefit from it.

>I would much rather have to spend a few days to relearn a tool every few years and to get the benefit of that tool, than accept a lower quality tool just to avoid a few days work.

Vim police has issued your red warrants. Justice will be served.

Jokes aside, I'd say yes. I have worked with Eclipse, NetBeans, JB and nowadays I'm happy with VS Code. For a polyglot, it's the best out their at price point $0.0 and tooling is pretty good for me.

I'm doing Python, Go, Typescript and occasional Rust without missing anything.

Few keystrokes faster with command kata would not going to save years of labor. Actuall effort in software engineering is not in typing text or in text editing. Not at all. The battle is far far beyond that and bigger than that.

EDIT: Typos

just to add my $0.02 WebStorm makes writing NodeJS feel a lot more like Java - it's pretty good.