Hacker News Reader

In my experience, after University, I never see team members extensively dispute on this topic. I have a strong preference for Vim, but if other are fine with other tools, that's nice. We can possibly show each other how we manage things differently.

It's not like Vim is perfect, and even taken the sharp learning curve apart, there are many things that are not ideal. But so are other tools. I tried some IDE here and there, but never found an improvement in my productivity – which would be certainly easier to improve by not going to sites like Hackernews. :D

I do find some things in some IDE horrifying, like having the amount of RAM consumed by the application displayed in the default interface, and seeing it growing while you don't ask anything to the application. I mean, even dropping the fact that it does require so much resource to do nothing, what a strange idea to clutter the interface with this data if the goal is to let users focus on there issues.

But that's no reason to be zealot of any other editor, including Vim. I'm rather confident that going with a matrix with measurable metrics, Vim wouldn't have rated 100% everywhere nor any other tool would.

To me the greatest feature of vim is that it's available virtually everywhere, so you can take it and the skill you gained on it everywhere. It doesn't make it something should use all the time, but it makes the point on how it might worth the effort to start learning it. That also a positive retro-active loop, that explain "why Vim is so popular", I guess.

> there are many things that are not ideal

I’ve never used vim, mind sharing what it’s weaknesses are?

Code browsing and inspection is somewhat hampered by the fact its CLI.

I use ctags and macros to move around code but its not always perfect.

But then again there are many things I dislike in modern IDEs, I don't think there is a ideal solution, just like there is no one language to solve all problems.

There are graphical versions of vim. Gvim is my main editor. It's a bit of a hybrid, since many things that would exploit the GUI in an IDE are still textual in vim. But it has quite a few benefits over pure command line.

> Code browsing and inspection is somewhat hampered by the fact its CLI.

That's interesting because code browsing and inspection are by far the most important reason why I use a modern IDE. I tolerate all their weaknesses (slow, high memory consumption, errors after updates, etc.) because of this. I am surprised that somebody would say "I am using editor XYZ despite its weaknesses in code browsing and inspection".

It's always seemed to me that vim and other lightweight editors are most popular among people who are working in dynamic and functional languages, and heavyweight IDEs are most popular among people who are working in big, static, enterprisey OO languages like C++, Java and C#.

I don't think that's just a coincidence.

What Vim lacks in browsing/inspecting code it makes up for with the speed you can make edits - using motions and macros can make tedious code changes nearly effortless.

So it depends on what you value more.

Vanilla Vim I would agree is not good for code browsing and inspection, but two things I've noticed when coding with Vim:

1. Code Browsing is an initial, one time cost when learning the code base. After you learn the code base, I've needed this ability much less.

2. Adding plugins like NERDTree and fzf/ripgrep have helped make code browsing much easier in Vim. The downside to this is that if you're new to Vim, you need to learn how to use these plugins on top of learning how to Vim. So it's just more to learn. But you can also think of this as another one time cost in general.

This is true for me too, I would often use Vim to basically do quick modifications, and use an IDE for refactoring/completion, and code navigation.

Recently a lot of quality plugins have been made leveraging Microsoft's languageserver capabilities to provide many of these features for NeoVim/Vim:

https://github.com/neoclide/coc.nvim

In many cases it's better than an IDE because the code-inspection, linting, etc etc, can be done using the same exact tools as what your CI is using behind the scenes.

Also, having a languageserver for Rust/C++/JavaScript/TypeScript/Bash etc etc, all configured through coc avoids a lot of the jumping between IDEs/editors/tools to get reasonable completion and code navigation between each.

I've been a Windows admin before but now on an app support team running almost all Windows systems as an analyst but came from a poly sci degree. My Linux experience is homelab and a few work connected systems over time like a Ubuntu Server box that managed IP cameras on site. My experience with coding is mostly Windows automation via PowerShell and its built into Windows IDE as I need a dev role here to get like Visual studio. Even then it would be overkill for what I'm writing like temp cleanup, file transfer, monitoring, etc with my recent success was a script that checks every day for a set of reports we should have received and ingested overnight and lists what is missing then emails that info to myself and another team member. Super helpful to double check the business has the reports they need at the start of the day and get us a head start troubleshooting.

With that in mind, I've used VIM for probably under 10 hours total, mostly for editing config files within headless Linux installs. For example, setting a static IP in Raspbian so I could SSH in once I put the pi somewhere it was online but not physically accessible. VIM is really neat for stuff like that. I'd love to have more reason to learn the interface but barring a weekly use I'd quickly lose familiarity and am focusing on javascript functionality as one of our apps can run js scripts.

So for quickly editing files with a known structure like setting an IP address in Linux or updating code you understand, I can totally see how VIM is amazing. Lightwight, almost always there already so standardized, quick to navigate when familiar, and more. As a fairly novice level coder I'll stick to an IDE with scroll ability and a mouse/etc for coding, even for a slight update to something I wrote the previous day. I'm just not confident in getting it right the first time and know how to test or trial/error a command in an IDE much easier than CLI. If I was trained and focused on coding I bet I'd be way better at that stuff too.

> As a fairly novice level coder I'll stick to an IDE with scroll ability and a mouse/etc for coding

Check out gvim - it's a graphical version of vim that gives you scrolling and mouse support.

It's not quite as graphical as a regular IDE but basic stuff like mouse and scrolling is fully supported. You can even use the mouse to e.g. resize tiled windows within the editor.

Did you not read TFA?

~25% of web devs in the SO 2019 survey said they used VIM as their editor. Amongst dev-ops that number is higher, around 40%.

https://insights.stackoverflow.com/survey/2019#technology-_-...

So your anecdotal example of "99% of people using VS or VSCode" doesn't ring true for the industry as a whole.

People could select more than one option in that survey (87,317 responses; select all that apply). You'll notice that the results add up to more than 100%. Most people who have to remote in to a server will be forced into using Vim sometimes, which will skew the results. Also, I would say that people who would respond to a SO survey arent a representative sample of all developers.

I do not use Vim as a daily driver at all, but I have to use it sometimes because I have no other choice (remoted in to a box). So if I had to say which editors I used, Vim would be there... sometimes.

You're misinterpreting that graph. The key detail to note there is that the bars don't add up to 100%. Meaning that it's showing what percentage of people use that IDE/editor at all. The phrasing, "~25% of web devs... used vim as their editor," implies that 1 in 4 web devs use it as their primary or preferred editor, which is not something that can be inferred from the data.

For my part, when I answered the survey, I checked vscode, intellij, vim, jupyter, emacs, and rstudio. Most of those are there because they're my preferred editor for some task or other, but vim is only there because it's the only editor I can expect to have available on every server I ssh into. So, while I did say that I use vim in the survey, I would encourage you not to count me as a vim user for the purposes of any popularity debates.

FYI, the guidelines state:

> Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that."

I think it's highly industry and probably project dependent.

If company policy is that "we use X", then probably you're not going to have many people stray from that. The bigger the organization, the more likely you are to have strict guidelines in place like that.

I would guess people on Windows are also less likely to reach for Vim than any of the many other alternatives. If you're using Linux, you probably have a different view on the world to begin with, and are more likely to go with vim over whatever is the "new hot editor". I've heard Mac users like to reach for XCode, but I don't actually know many developers outside of work, and none of them use Macs, so I don't know.

Besides the other facts mentioned by the other commenters, Vim has a sort of geek-chic aspect to it. It's "cool" to be a Vim user in certain circles. That inflates the numbers plus it also causes a "New Year's resolution" effect where someone would say they use it just because they know :wq and this year they're really, really going to go to the gym, oh, sorry, going to use Vim proficiently for a real project.

Almost every editor allows you to interact with it as though it's Vim. But most editors don't allow you to interact with them as though they're any other editor. I think that's a point in Vim's favor?

(I certainly don't use Vim for most of my coding. It's not good enough. But I do use Vi keybindings in VSCode, Visual Studio and PhpStorm depending on what language I'm using. I'm not particular enamored of VSCode either, btw, for the same reason that Vim isn't good enough - sure, it can do what you want. But you can't guess how to do it. You need to read the documentation. VSCode one ups Vim in just one way - it has a gui for searching and installing plugins. Visual Studio and PhpStorm allow you to browse the menus to find the facility you want. It may take for ever, but when you have some downtime, you can browse and use your learnings next time.)

This. I just want hjkl and dd in every editor, but I don't use any other vim idiom often, and things like multiple cursors or alt+up/down move lines are the editor's fancy features I rely on most. (Sadly the VS Code vim plugin is broken all the time)

But hjkl I need even in my webbrowser. (In Thunderbird I've send many mails to junk by accident.)

I use Autohotkey to map Caps+H to Left, etc. systemwide

Pretty much this. I'm learning Godot and love almost everything about it over Unity... except that its IDE doesn't have a vim-mode, which is ALMOST a deal-breaker.

As a data point, Mac OS native text controls have a handful of Emacs-style text commands that use Control -- like ^t, ^e, ^h, ^b, ... -- baked in.

That is too bad. I'm a Vim user and combine the best of both worlds: vim plugin in VSCode.

A few of my colleagues are vim users, and fortunately for the others we are not as vocal as you describe. I already accepted of being the weirdo that uses vim, because my programming skills make up for it ;).

I do have a shortcut to disable it, when we do some pair programming.

> vim plugin in VSCode.

How is that these days? I used it a couple of years ago but it had issues at the time, namely some performance problems and getting stuck in a particular mode.

I ended up abandoning vim bindings because the JetBrains plugin was also buggy, and I straight up had no feasible way to get those bindings in Xcode, but I hold out hope for a glorious LSP-based future where I can just use vim and get all the benefits of my other editors.

If you haven't already, you might want to check out coc.nvim https://github.com/neoclide/coc.nvim

Coc.nvim is awesome. Instead of trying to bring the UI of vim to another editor, coc.nvim brings the "backend" of the other editor to vim.

I tried using VSCode with the Vim plugin for a while but the latency and inconsistencies eventually got me back to proper (neo)vim. UIs are almost always more complex and subtle than people intuit, have a large surface area, and make lag and inconsistencies most noticeable.

There are a few. I am using VSCodeVim[1] with the default settings (besides the typical `jj` command)

I love it, and using anything else feels weird. I remember having some problems with it before as well, but I haven't bothered looking at the settings or anything for months. I had to go back just now to see if I had any weird configs set up, (I don't)

[1]https://github.com/VSCodeVim/Vim.git

Most vegans are actually quite quiet about it, so it’s a sort of survivorship bias, where you simply have no way to find out how many non vocal vim users out there :)

> I would say Vim isn't popular at all.

The fact that most popular editors and IDEs (every one you mention) have VI/VIM plugins suggests otherwise.

It's (usually) not the editor itself that people find appealing. It's the key bindings. It's the fact that you can navigate around a file without reaching for the mouse.

Saying vi and vim are not popular is like saying Unix and Linux are not popular.

Being at a company where most people do not use Vim definitely has caused a great deal of consternation and discussion about why I use Vim, and why I don't use a "real" IDE.

It becomes a hot topic of discussion without my wanting or really worrying about what other people are using.

I think the comparison to Veganism is a good one--- people think it's a flex, when in reality I just like it and it helps me get my work done.

Have you considered that every person who uses vim has sat down at a new job and been told by their boss how much they're going to love their IDE?

I sent this comment to my colleague, I'll see if it triggers him... :-)

> VS and other editors quietly get along with their work and feel no reason to advocate for their editor like it was a religion.

Well of course not, because their editors SUCK!

Well, I am the only guy on my team who uses VScode-Vim and I don't preach. I understand that editor is a personal choice when it comes to development.

So Vim has more champions. Sounds like you experience ineffective ones all the same.

Software engineering is far bigger than your niche.

sounds a lot like the IRC guy...

https://xkcd.com/1782/

IRC users don't use vim, but nvi. They don't need any more. They probably use entr(1) and make(1).

I think they are just being posers. When we compare the efficiency of debugging (p. ex.) it is clear who can find the problem fast.

Today if I'm conducting an interview and the someone tries to convince me he/she is a good programmer and just use vi/vim, I need to rethink my decision because it can compromise the whole project. I'm not saying they are not good, but having the capability of fast debugging and solving problems fast is crucial sometimes and is part of the whole package.

I was that kind of person someday and I understand the feeling.

But for devops, vim or emacs are the all-in-hands tool and everyday editor, just because they are available in everywhere and work very well on terminal mode.

I don't get it. Are you saying vim users are bad programmers and bad at debugging?

I believe the assumption is that IDEs are dramatically superior tools for debugging.

he's saying vim users are hampering themselves.

Spoken like someone who has never gotten accustomed to the power of vim :)

Do you know who would likely "compromise a project"? The junior dev that is unable to stray outside their IDE when getting things done.

Interesting comment. I've been programming for more than 25 years. Have used stuff like GWBASIC, TurboPascal/C , fancy ide like VisualStudio, Eclipse, Netbeans and the new kids like atom or vscode. I even used DDD at some point.

Line debugging becomes less and less valuable as you become more mature in you dev career. Sometimes you have a race condition bug, some times the target architecture just doesn't provide it (devkitpro/devkitarm or embedded) and sometimes bugs that are evident in production just cannot be replicated in your debugging environment.

In my experience it is more valuable to improve skills of building mental models of the system at hand, get effective with console logging for key info and troubleshoot issues that way.

>some times the target architecture just doesn't provide it (devkitpro/devkitarm or embedded) and sometimes bugs that are evident in production just cannot be replicated in your debugging environment.

It happens, yeah. What mostly happens is that 99% of software development has debuggers available and that they are infinitely better and more useful when resolving issues. Printing, then realizing you don't have enough info, chaning your code, recompiling, printing, etc, is just not good software development practices.

Live with your constraints when you have no other choice. Use the tools that have been a standard in the industry when they are available to you.

I think you should evaluate candidates based on the skill/knowledge they show in the interview and trust that if that is up to par, then they will be competent to choose the tools that work best for them.

IDEs are great for the early stages of a project, but once it hits production, this is the only debugging flow that has ever worked for me:

1. Read the logs.

2. Read the code that produced the logs.