Modern IDEs are magic. Why are so many coders still using Vim and Emacs? (2024)

Reply

I’m sorry to say that but that was a very uninteresting and badly informed article to read. I’m OK with people saying I use old and has-been tools, but then I expect solid and interesting arguments.

First, claiming that vim and Emacs are now united against “modern” editors, because they implemented each other’s keybindings is ridiculous. Yes you can now even run vim in Emacs and have the best of both worlds for example, but that has nothing to do with the availability of more recent editors.

I don’t know about Vim, but the reason Emacs is not “fading away in the sunset” is not because it is available and running everywhere (it is) and some old nerds are used to it (they are). It’s, I think, because Emacs is a mature, proven, stable, and powerful self-documented, fully programmable lisp machine, with hundreds of high quality plugins, and a vibrant community, still actively maintaining and evolving it.

Reply

I’ll give you my reason: It fits into the unix toolchain. I live on the command line and the fluidity of using vim there is unparalleled. And full disclosure I recently “switched” to nvim, so you’re totally wrong that I am adverse to change :P. IDEs are generally “top-down” apps that are essentially an entire environment unto themselves. Vim can be that too, but I find it better to work the other way. To start with the command line as the environment and use vim as one of the tools therein.

I grew up on old-school Macs with BBEdit and other non-modal editors. On Unices I used nedit for years, which is pretty much the equivalent, but via osmosis I slowly learned vim. Eventually I just decided to really learn it and bend it to my will, and I’ve never looked back. I find vim to be much like playing a musical instrument, you develop the chops with lots of practice, and you can always learn new techniques even after many years. Still I clumsily “miss notes” occasionally and wind up off in the weeds accidentally. Regardless I find it more fun and enjoyable to use since it is mine.

Reply

Reply

This is like old, grumbly climbers arguing as to why they’re ATCs are “good enough” in the face of safer, modern devices like the Grigri.

Us young whipper snappers just don’t understand/respect our cultural roots…

Reply

Reply

Reply

Reply

Thanks for the fun article. I’m glad you didn’t take sides 🙂

For those who are thinking “maybe it’s time to learn an IDE”, I’ve found that the best time is while also learning a new (and preferably modern) language. Especially in cases where the editor and the language are close friends (e.g., VSCode and TypeScript), learning the two together is a good way to trick yourself into being willing to ignore all the muscle memory your fingers have, and into being open to learning the tricks that the new IDE offers.

Reply

This is a profoundly clueless article. Many, if not most, Vim users *also use IDEs*. I spend virtually all my time in an IDE, and Vim is a crucial part of that.

First, Vim is more than just an editor, it is an *editing model*, and superior one. It’s a combination of several things:

1. Modal editing, where commands are issued using *non-chorded* keystrokes, which allows editing at the speed of regular typing (i.e. fast as hell).
2. A grammatical command language, where sophisticated instructions can be composed from verbs and nouns, then qualified with counts or repeated with a single keystroke. Because Vim is modal, these commands are plain text, human-readable and editable.
3. Every key on the keyboard is a register, which can store sequences of these text commands, which can then be played back or even composed into more complicated actions.
4. Commands, sequences of commands, or sequences of sequences (macros composed of other macros) can be bound to keys on the fly, again by *typing* plain text (which means you can even bind a command that binds a command).

Vim is much deeper than that, but these factors alone makes it absurdly powerful in the hands of an expert. It’s like a text manipulation *engine*, where you build up text transformation tools on the fly, quickly, intuitively, that you’d otherwise have to write custom code to do.

Second, crucially, Vim’s editing model is *portable*. Because it’s so ubiquitous, this editing model is supported by almost every major editor and IDE. If you have 10 different tools, you have ten different keystrokes for “copy line”, “copy to end of line”, “copy word under cursor”, etc. assuming the tool you’re even *has* keystrokes for those things (a lot of tools have poor/anemic editing models). This an exponential explosion of keystrokes you have to learn if you want to be maximally efficient in every tool you use, so most people don’t even bother investing in deep mastery of all their tools.

Or you can learn one Vim’s model once and use it everywhere. My current job requires both Windows and Linux. I use Visual Studio, IntelliJ, Visual Studio Code, and SQL Server Management Studio half the day, and the rest I’m working through a terminal. I use Vim, everywhere, all the time.

Vim is not some tool used by old dinosaurs clinging to the past. There’s a constant influx of new users, who often become converts once they reach a level of mastery that they grok the advantages of the model. If you’ve learned just enough to exit Vim, you’re arguing from a position of ignorance, which is obvious given the article.

tl;dr: Vim is a superior and portable editing model available in a huge number modern tools.

Reply

Reply

Reply

As a 6-7 years Emacs user, I have to say I do not recognize myself in your article. I started working as a developer using eclipse and other IDEs , and felt I was spending too much time switching between my keyboard and my mouse.

This incited me to try Emacs, which is mostly (but not only) keyboard-driven. I discovered a fantastic piece of software, extremely extensible and carried by a community who creates excellent packages.

From time to time I try newer IDEs to see if I can find something even better because yes, I realize the time I spend to fine-tune Emacs to get IDE-like features is a bit of a shame when newer editors have it out of the box.

But I eventually come back to Emacs. Org mode is so useful it became a major part of my work flow. Magit is so powerful I never get the issues my coworkers have with git. Emacs ‘ consistent textual interface spoiled me so much for years that seeing all these panels in modern editors that each have their own rules disappoints me.

So in the, I wouldn’t say I’m using Emacs because I don’t want change. I use it because I wanted change and I got “rewarded” for it.

My experience reading discussions in the Emacs community is that I’m not an exception. A lot of people actually use Emacs because common editors doesn’t quite suit them and they want to try something different.

In the end it’s all about people and their workflow, I think, Emacs and vim have a big learning curve but they worth it if you have the compatible mindset.

Now, I was a bit puzzled when I was reading your article. Emacs vs vim vs modern IDE war? The Emacs – vim war is, afaik, nothing more than a joke today. Each community benefits from each other. Regarding modern IDEs, at least in the Emacs community I don’t see any hostility toward them, they even collaborate on subjects like LSP which would have never existed without VSCode. I would like to know what gave you the feeling there was some hostility here, maybe I missed something.

I hesitated to write this comment to be honest… Everything that’s said in your article is very far away from my experience with Emacs and the Emacs community. I am not a native English speaker, so I thought I may not have seen some irony / sarcasm in what you wrote… Please tell me you are serious and I am not embarrassing myself by answering while having missed the point totally 😀

Reply

Reply

> That said, if you’re new to programming, a modern IDE could be helpful. With code completion, Git control, and even automatic deployment systems, modern IDEs are a Swiss Army Knife of features.

Quite literally every single one of those features has found it’s way into Vim and Emacs. With just a couple lines of elisp of vimscript you get access to LSP-powered autocompletion, formatting, refactoring and linting. A couple lines more and you get Git control as well. And then you can take all that and just use the same editor with any number of different languages.

Reply

Reply

Reply

“With code completion, Git control, and even automatic deployment systems”

I…have all of that in Emacs? I write Java, for a living, and use code completion in Emacs every day.

I’d also be shocked to find that Vim doesn’t have Git control.

This post makes it sound like Emacs and Vim are just Notepad with funny bindings. We don’t stick with Emacs because it’s what we’re used to – we stick with it because it’s powerful and, above everything else, flexible/configurable/rewritable through its near entirety.

Reply

Reply

Vim and emacs are still used not because developers are too stubborn to let go, but because their editing methods are simply more efficient that using mouse for navigating and keyboard for typing. Vim is a modal editor which means you can perform any command directly with the keyboard. no moving the mouse, no switching hands. Also vim and emacs are simple, fast and customizable. most other IDEs are not customizable as much and end up being annoying. Also an IDE is a conplex piece of software, which you really don’t want to deal with when you are coding. Vim just edits files. And if you need anything extra, you install a plugin. That is how a code editor SHOULD be, imo, it is not deprecated and modern IDEs are not doing it better.

I wish there was a modern vim. A minimal text editor with a scripting language and good plugins. but I don’t want to run a fully motorized software development kit just to edit a file or browse my project.

Reply

“IDEs will keep improving, keep launching, and serve an ever-growing segment of young developers who were never forced to thrive in Vim or Emacs environments.”

This kind of statement really annoys me. I’m 24, and I have used plenty of IDE’s, but I really prefer emacs for most things. Please don’t paint with such broad strokes. With apologies to the old guard who probably know the correct terminology better than I do, I’ll elaborate.

Sure, I am using cua-mode (which means I don’t have to re-learn the kill/yank stuff), but the fact that I can make emacs work the way I want cannot be understated. It has some great features, like multiple “panels” so I can look at two spots in a file at once, or look at a file and a terminal/python REPL/Lisp REPL at the same time for fast testing. I know more “advanced” IDE’s will do this, too, but while in the 80’s emacs was a butt of jokes for how huge it was it’s not really that big by comparison to something like Netbeans or an Electron-based program, especially if you’re not using a “fully-featured” build. Its startup time is also good, and it can run in a pure text mode, which is handy for SSH sessions where X11 forwarding would bring a huge performance penalty.

Also, emacs still has people writing metamodes and is still evolving today; it’s probably one of the most common places to see Lisp being written today.

I’m not going to say that more “modern” IDE’s aren’t cool or good (I don’t like writing Java without one, for instance), but it’s not always necessary and there’s a definite tradeoff.

Reply

This seems like you have never actually used emacs. Add emacs is able to do everything sin can do and is free and open source. After a decade of using vim I switched to CLion and was very happy since it had vi key bindings. Then I changed positions and couldn’t use CLion any more. Then emacs came to the rescue. I have it set up as a full fledged c++ ide with vi key bindings. Everything I could do in CLion or vim is there plus some.

I would suggest checking out spacemacs as an easy starting point.

Reply

Ahem, your article is very incorrect.

I’ll start off by mentioning that I use IDEs over Vim or Emacs most of the time. Nevertheless, I do use both these tools (yes, both!) quite a bit, on an everyday basis.

But you, my friends, talk like you’ve never used either tools in your life.

> Vim shortcuts

Anyone who has used Vim would not call them shortcuts…

> Atom has 4 GUIs

???

> With code completion, Git control, and even automatic deployment systems

Both Vim and Emacs have these. What are you talking about?

> Vim is always available. Any Linux machine has it.

NO. As a Linux distro dev, I can guarantee you that every system DOES NOT have Vim. I can’t express the stupidity of this. Most Linux systems have vi, because that is built into many coreutils packages. Vim is COMPLETELY DIFFERENT, only based on Vi originally.

[Editor’s note: I think there’s some valuable discussion in this comment, but I removed a lot of the hostility. We get that you have strong feelings, but keep your discussion civil.]

Apologies once more,

Bobbbay

Reply

Reply

Reply

Reply

Reply

Reply

You’re fundamentally missing the issue of why vim works rather than a “modern ide”. It’s all about how people program. We spend the vast majority of our time EDITING existing code, rather than creating new code. This is why vim is a text editor, and ides like Atom or VSCode are not. Vim focuses on keymaps, both built-in and user-defined to quickly and without a mouse, jump around, change and manipulate text and code, in a smart way.

The other thing is that vim is just fast. I spent a couple years in VSCode and everything about it felt slow and not well thought out. The git integration is not helpful and the opposite of intuitive, as such it would be better off left out entirely. It’s also using a terrible javascript based environment which is slow, buggy, memory intensive and might well be considered a memory leak by design.

Simply put, it doesn’t matter where I am, I can scp my vimrc over, and get to work without having any sluggishness or inconsistency due to different environments. Additionally, it doesn’t matter if I’ve got 16 cores at 4.7GHz or a single 500mhz arm core, vim performs the same.

Simply put, vim requires retraining to really understand, but it is better for people who care about rsi, people who care about speed and efficiency, and people who simply want a consistent environment across multiple machines.

Reply

“Beginning programmers are much better served by simple text editors vs. massive programming behemoths.” – Sure, if the IDE is cumbersome, arcane, or extremely sluggish then that can be a pain point, but a well-designed and reasonably unobtrusive IDE can be an absolute blessing for a beginning programmer. Questions on Stack Overflow from beginners who “want to use just Notepad” to “learn” Java end up in long discussions about classpaths and compiling and whatnot; it’s like having to learn how to build a kitchen before you can start learning how to cook.

Even though Python is much easier for a beginner to grasp environment-wise, a good IDE like PyCharm still offers code completion, integrated debugging, PEP-8 hints, smart refactoring (not just rudimentary find-and-replace), regex testing, and a host of other helpful gadgets. Beginners may not take full advantage of them right away, but (thanks to “tips of the day”) they at least know that they are there.

IMO, recommending that a beginner “learn” by just using Notepad (or Vim, or nano) is most likely doing them a grave disservice.

Reply

There’s also the understated issue of making sure the resources you need are not being controlled or paywalled by any future entities.
EMACS and Vi/Vim are forever free (as well as some of the others listed) and there is no chance that somebody Microsoft or Oracle will be able to copyright them..lest some government says it so.
Thusly, the ‘old-school’ users (not always cheapskates) may be able to make their devices work for their own needs..

As one particularly pugnacious plebian said to me:

‘Install Gentoo’

Reply

This article is clickbait, ad hominem, and the authors (who do not write programs for a living) are not able to conceive of the possibility that people would understand all of the claimed benefits that “modern IDEs” have to offer, and CHOOSE vim/emacs because it is better.

Framing it as “willful defiance” and “stubborn resistance” betrays the authors’ ignorance. But the ultimate conclusion is still right: it doesn’t matter what people say. Those of us who are willing to learn to use flexible, useful tools will continue to be far more productive than those that resign to be unable to do anything not given to them by their IDE.

Reply

Reply

I restrain myself from criticism based on the evidence that you are not a Vim user and don’t understand the most important points about which your opining.

There was never a war between Vim and Emacs. Emacs is a single mode editor like every other and requires use of chords, chords and more chords. Like one Vim user put it “it’s chords all the way down”.

Vim is a dual mode editor and that feature alone unleashes a storm of fast efficient functionality that can be used from second to second as you type. This effectiveness has never been bettered in any editor since, although it has been emulated many times.

I’ve tried using different IDEs to replace Vim, but it’s too frustrating to go back to the extremely slow and limited management, navigation and basic editing tools, and I don’t see the point. There’s no value proposition available today where that makes sense.

Stubborn and irrational resistance to change? The question I ask is why are so many coders, people that I would expect to be able to tolerate high information loads and deep complexity, why are so many coders resistant to learning the few basic Vim commands that would set them free to greater efficiency and power, not only in a windowed environment, but also when managing headless servers and working remotely?

Reply

Reply

> That said, if you’re new to programming, a modern IDE could be helpful. With code completion, Git control, and even automatic deployment systems, modern IDEs are a Swiss Army Knife of features. And, like most Swiss Army Knives, you don’t have to use all the features to find them useful, especially if you’re just starting out. Many of us won’t use, say, the hole punch or the toothpick, but it’s nice to know it’s there.

I mean, those are all available on Vim/Neovim and Emacs. I think you’re vastly underestimating how configurable Neovim/Vim and Emacs are.

Reply

Reply

Reply

There are two assertions here that are not accurate.

The first is that editors like vi are not as feature rich as a modern IDE, and it’s that simplicity that attracts developers shy away from the “weird new food” of an IDE. To the contrary, vi+plugins can be just as feature rich as any modern IDE or as feature lean as desired, and what makes it even better, the only thing needed to have a universal experience across all a developer’s terminals is an easily source-controlled set of dot files.

The second incorrect assertion is that vim users will go out of their way to use vi or to find “Vim mode” on modern IDEs because they’re “unable to let go of the past.” There is some resistance to change, but it’s not stubborn or dogmatic in nature. Learning the many keystrokes of vi and emacs takes time and practice, but the end result is a developer that can edit code much faster than a developer using the competitively narrow range of key shortcuts a modern IDE provides (see: efficiency competitions such as vim golf). vi and emacs keystrokes are, by intention, as complete and efficient as possible, and all without needing to switch hand position between keyboard and a mouse. Classic editors, once mastered, have a way of cognitively disappearing from the coder’s awareness, leaving the coder alone with the code and giving them enormous editing speed.

Reply

Very interesting. I ditched the IDEs to use Vim and I’ve never been able to look back.

(neo)Vim us amazing and today with the work that the community has done, birthing Coc.nvim, a LSP client for (neo)Vim and the numerous extension, (neo)Vim users have the power of language ItelliSense inside the amazing editor.

The limit is in the skies, but when you put tmux(terminal multiplexer) and fzf(command-line fuzzy finder), the limit is beyond the skies.

Reply

Modern IDEs are indeed amazing (always have been, really).

If you don’t use Emacs or Vim, and/or you don’t have a historical relationship with them, that is likely the source of your surprise that they’re still heavily used. Emacs is arguably one of the most powerful things ever developed, and I can make it do anything I want by writing Lisp. It’s opensource and it integrates natively with Unix in a way that no modern IDE would even…consider. That’s basically where it evolved. And the Emacs community in general is ridiculously intelligent.

Should someone with less computing experience prefer a pointy/clicky IDE because it’s easier for them to start learning JavaScript, then that is their journey, not mine. The new norm of inexperience with so many new people — who all kind of copy each other’s bad habits — is unfortunate, but it doesn’t mean there won’t always be companies producing really nice graphical IDEs for people to buy. 🙂

There is a disconnect between the knowledge of old Unix wizards and what the newcomers to Tech perceive as valuable. A lot has changed in 30-40 years, but a massive amount of fundamentals are unchanged.

Reply

Reply

Reply

Reply

Git control? You haven’t heard of Magit then? Have you heard of Org mode? Have you read the calc manual?

Very long and simplistic way of saying “I don’t really understand or know how to use Vim or emacs.

Reply

I think this is a bit harsh on vim. With the appropriate extensions, it’s as good an IDE as VSCode. Yes, this only became the case fairly recently: asynchronous extensions landed with vim 8 in 2016, and the invention of the langserver protocol (https://langserver.org/) gives the ability to not have to have vim-specific extensions for each language.

Still, through extensions, vim offers autocomplete, code actions, refactoring, syntax highlighting, linting and the like. It offers macros, which I miss when I move to other IDEs. And it’s the fastest editor I’ve used.

I expect the same is true for emacs, though I don’t have personal experience with that editor.

Reply

mmm, vim isn’t really an IDE it’s a text editor based on the original vi editor.

The reason programmers like me still use it is because it’s a text editor written by programmers for programming. There are lots of advantages with it that really aren’t possible with a text editor such as notepad. Things that only programmers need to do like changing the first character of each line in a section of code, or repeating the last thing you did multiple times, or using regular expressions in search and replace.

An IDE is an integrated development environment. This contains lots of tools a programmer needs such as a text editor, a compiler, a run environment, probably a visual GUI editor, some sort of source code control.

An example to show the difference is I use Android Studio which is an IDE for developing Android applications, and I have a plugin for Android studio which allows me to use vim as the text editor inside that IDE.

Hope that helps…

Reply

I never leave comments on things like this, but this blog post seems heavy on opinion and light on empirical evidence. I just became a developer 2 years ago by self teaching and working my ass off, and I _chose_ to use vim in order to have fast and efficient text editing from my keyboard. I use some modern plugins, like any sane individual would, and I never feel like my approach is “antiquated” or out of date.

Further, as a vim user, there’s nothing wrong with vim mode in ANY modern IDE, if you need/want the additional features of an IDE go nuts! Don’t lose sight of the fact that vim’s approach to editing text is just incredibly efficient once you put the time in to learn it. You already have to learn your tool and plugins no matter what environment you use. Modern IDEs _could_ learn from how vim has implemented text processing and text navigation, don’t listen to people like this who are well intentioned but clearly think that vim is just for old neck beards. Use the tool correctly, ANY tool, and get the job done in the way that YOU feel most productive.

Reply

Reply

Reply

> unable to let go of the past, unwilling to fully embrace the future of code editing.

To me this sounds like you did not even research the established editors.

> It’s mental mom’s spaghetti

Vim is more than an editor, vim is a language and a tool to translate intent into code. I can 2p to paste something twice, or 12yy to copy 12 lines. ci” to replace contents of a qoute. I can edit multiple lines at once, and substitute text using advanced regular expressions. All without any plugins. I can move freely through the document without my wrist leaving the home row of the keyboard. Putting it short, learning vim gave me a super power being able to control the computer in the speed of thought. Vim uses 12MB ram opening a 6MB file, VSCode uses almost 400MB and Atom almost 900MB.

If you want me to switch to your editor, and tempt me with a vim mode, then you need to give me something in return. All the plugins I have fancied in VSCode or Atom has equivalents in vim either by plugins or just being native. And the only thing can see being awesome in VSCode over both Atom and vim is the git integration. But again just using the git cli gives me more features, and allows me to simply type in what I want into my shell, and it will be done. No fiddling with the mouse, being in the dismay of the UX designer of VSCode. VSCode and Atom are not like the new Playstation, where I need to purchase the new system to be allowed access to buy the new games. VSCode and Atom are trying to take the fundamental graphical editor, designed for the computer illiterate person who does not want to learn how to command the computer, and tacking on programming helping features. This is great, I would have loved to have VSCode when I was in elementary school writing my first programs in notepad.exe, but today I am in a position where I can learn a new program if it saves me at least the time spent learning.

So why change from a program designed to efficiently translate intent into code. To a methodology of writing where its simply designed to allow a computer illiterate being able to enter text into their computer? Why change from vim to VSCode with the vim mode plugin, when it will use two magnitudes more memory, be slower, and require me to move the mouse around for the menu items?

You need to give me something more than the new editor looking fancy, and telling me that my editor is out of date for me to want to switch.

Reply

Reply

Reply

> Most IDEs create entire worlds where developers can create, but creating requires configuration. It takes time to adjust that world, to play god, to create shortcuts and hotkeys, to get used to different command structures and UI.

The authors seem to be describing Emacs.

> With code completion, Git control, and even automatic deployment systems, modern IDEs are a Swiss Army Knife of features

Which can all be done in Emacs. Arguably Emacs has the best git interface of any program (magit).

Reply

Reply

Reply

Reply

Any time I see an article mentioning Vim, it peaks my interest.

I find some of the history behind the Emacs vs Vim debate rather interesting, but I was not even born in the 80s. I found vi on my own during high school, (I graduated in 2012), and after climbing the rather steep learning curve, I now use it for almost everything. I tried Emacs, but I didn’t like it; that’s just me though.

I think the title of this article captures a critical point, “Modern IDEs are magic”. Most of the so-called modern tools do a lot for their users. And in my experience, I have seen many programmers that do not understand what their editor is actually doing.

A good example would be managing git repositories. Many modern developers do not understand how or what git actually does, they just press the button and it’s done for them, (That’s not necessarily bad or wrong; I think it depends on their role).

Vim and Emacs both are extremely customizable, and any feature that one desires can most likely be found in a plugin. Also, the latest release of Vim is only from last year. So really, I don’t think antiquated would be an appropriate term. Rather, I think the big divide is more of a philosophical approach; do you want it to do everything for you? Or do you want something that stays out of your way unless you tell it otherwise.

I think the worst IDEs are the domain-specific ones because then you end up with like six different IDEs because they are very opinionated on what languages or tools they work with, (specifically all the terrible embedded ones like uVision from Keil).

One last thing I didn’t see in this article, was Notepad++. I would say, that is the Vim/Emacs for Windows people.

Reply

This isn’t really…well… accurate nor to the point.

For one thing, vim is always there (well vi is), but emacs very rarely is. I’m not even sure how you can put it in the same category there. Vim is usable by anyone familiar with the key bindings whereas emacs without your personal customizations can be a nightmare.

For another thing, vim vs emacs is a meme that does not really reflect reality. One of the most popular plugins for emacs is evil-mode which brings in the vim key bindings. Ever hear the old saw that “emacs is a fantastic operating system with a terrible editor”? Yeah. It’s in fact so common to use the two together that the very popular spacemacs configuration system comes with evil selected as the default.

But beyond that, it’s awfully self indulgent to hash up the preference solely to using what works. I came to both after being an avid visual studio, crimson, jedit, sublime text (which I lectured on), intellij, and atom user. In fact most people I know making the switch are young developers. I would actually love to have more graybeards to pepper with questions but they’re all on irc and it’s too much hassle to keep that open when everything else is slack.

So why did I move to emacs over the darling of the hour vscode? It wasn’t to be different, not knowing the ins and outs of what the rest of the team uses is certainly an annoyance; but when you get down to it, emacs just has too many killer features that others cannot complete with.

– window management. Ever notice how vscode has no golden ratio mode? No ability to position the terminal the same way as other windows? To split and rotate windows at will? That isn’t just a matter of open source not getting around to it. I’ve investigated and was told the core windowing model prevents it.

– org mode. This beats the pants off markdown, jupyter notebooks, and jira (granted, that one isn’t hard) for 99.9% of my use cases

– TRAMP is super cool and mind bogglingly useful with a variety of other things

– which-key plus helm blows anything else away in terms of feature discoverability

– magit is easily the best fit client I’ve ever used

– dynamic scoping for an IDE is just a good idea that enables super cool extensibility features such as the dir-locals mechanism

And that’s not even touching on the vim key bindings that are not only super efficient but also transferable between various editors

I don’t use this stuff because I’m stuck in the past. I use it because for the most part, it makes me far more effective than the alternatives. There is much to be annoyed with in emacs and vim, but the newer IDEs need to mine then a heck of a lot more for ideas before I jump so again

Reply

If you’re using git and not in Emacs, then you’re not really using git.

With Emacs I can write my next novel in the same environment that I write email, PHP, Assembler, Python, C++, Lisp, and documentation that includes live examples of any and all of these and 30 other languages besides. I can easily switch to Kanji or ancient greek (and create Anki cards to help me with both). I can extend the editor and the UI, override anything to create a domain-specific editor for stuff no one is ever going to produce a commercial product to support.

Emacs is the Unix Philosophy taken to the ultimate extreme – it does one thing and does it well. That thing is “editing”.

Reply

Reply

Reply

“Modern” IDE usually means slow, point and click, and unavailable from a terminal.

There are people that think Atom, Pycharm or VScode are better than vim or emacs. They either work in management or are tech journalists.

Reply

Reply

Use what you want. Let people use what they want.

I’ll always commit a .vscode folder to my repos. If you contribute and don’t make use of the vscode settings it but still manage to keep the code they way it should, I DO NOT CARE.

The article is low key trying to start something, but people getting angry over it clearly enjoy a fight, too.

Ignore unimportant stuff, such as this.

Reply

Reply

“Our fingers are often the bottleneck between thinking up code and getting it in the app, so that’s where folks look to optimize shortcuts.”

I have been programming for 25 years. Never once did I think that fingers were the bottle neck. It was always the stuff between the ears. If typing is taking most of your development time, you are probably not doing it right.

Modern editors and IDEs are great. The older editors are too archaic and have key bindings and design constraints based on limitations of the eras when they were developed.

The only proper use for them is in terminals where better alternatives are still not available. They are good to have around, just in case, but rarely the optimal choices. They are fallbacks. Use rmate with a modern editor. VNC in unless you are constrained by the network. Use productive tools, not tools that just have you doing busy typing to make you feel more productive. People often confuse furious typing with productivity.

Reply

Emacs and Vim (originally VI) were the first IDEs.

Why do programmers use them instead of IDEs? Because they are IDEs. Both Emacs and Vim are designed by coders, for coders, have insane amounts of extensions, have scripting (in Lisp, infamously for Emacs), and are frequently used with built in tools that let coders navigate through source code, run compilers & other programming tools, get post-mortems from crashed code fed through the debugger, etc.

Reply

I used IDE’s. Then terminal VIM, Then switched back to an IDE (Visual Studio Code). There’s one little “secret” than many die-hard VIMers (like my former self) that don’t know about something new:

IDE’s now support vim bindings !

Yup, all that stuff you love for editing, the thing that made you a vim fan, is now available in many IDE’s.
Game over. Back to IDEs. Knowling that I can break out basic vim whenever needed, like on a server. win. win

Reply

Author makes a lot of baseless claims. Developer in 30s, work with many developers in 20s. Almost all of us use vim because it is so much faster once you know how to use it. All of us have used IDEs and rejected them. Vim offers power, speed, and fine grained control. It can be customized and extended to anything modern IDEs do faster with lower resource usage. Not as clumsy or arbitrary as an IDE, it is an elegant tool for a more civilized developer.

Vim is a safe haven for every developer who has ever finished typing a line of text and stared despondently at the screen while the IDE struggled to display it a bloody character at a time. Vim is a refuge to anyone who, god forbid, has had the misfortune of working with a very large project in Eclipse and gotten to experience it randomly deciding to re-index all the source files IN THE GUI THREAD. Vim is a swiss-army-knife that is not miserable to use over SSH.

Vim and emacs are tools for developers who would prefer a more efficient tool that requires effort to learn how to use over a less efficient tool with a lower skill threshold. I don’t personally see the need for a ‘development environment’ with git integration. My development environment is the terminal emulator. It already has the maximum degree of git integration possible. It is called ‘/usr/bin/git’. It can literally do anything git can do, and if you know how to use it effectively, it can do so faster than the IDE.

Reply

Reply

Reply

Reply

I’m a younger developer who started in IDE’s and moved to emacs instead. I don’t think this article correctly navigates the reasoning for using such editors. They’re not used simply because an older generation is used to using them, some antiquated editor existing only as a comfortable familiarity.

Emacs gives me the power to do a lot of the things other editors cannot, however those other editors don’t give me anything I can’t already do in emacs. Emacs is the epitome of customizable. Until something else provides all of the flexibility and power that emacs does, then I don’t see any reason to use them. Not to mention the sheer amount of hotkeys, macros, and extensions that you accrue over time using a single editor.

Reply

Could this author look further down from his high pedestal?

I’ve never fought the vim vs emacs thing, and I’ve used countless other “modern” IDE’s, including visual studio code and Atom.
Right now I’m using Doom Emacs which for me is the best balance of the Vim bindings and macros I love, and Emacs power. Atom … just kept crashing on me the moment I try more complicated things, VSC stoped working correctly on projects of certain sizes, and it’s solution for git integration cannot compare to maggit in emacs.

We get it… you like shiny things, just keep using it. But don’t throw shade at the millennium falcon just cause it looks like a rust bucket to you. Some people know how to operate it, and find it valuable despite it’s quirks.

Reply

Reply

Here’s a hot take: Forcing vim into the role of an IDE is an aberration. vim is perhaps the best text editor (or text input method) ever invented, and the more junk you pile onto it to try and make it do the job of the entire toolchains that power modern IDEs, the less effective it can be at what it’s designed to be.

Using modern IDEs with vim plugins/modes/whatever is where the real power is. Visual Studio streamlines just about every aspect of developing useful software, and vim streamlines every facet of actually inputting and editing text. I don’t want vim to be controlling a compiler in order to power code completion when VS already does it really well. I don’t want vim to try to guess which namespaces I need to import when I type out a method that is out of scope, because VS does that extremely well. I want vim to help me navigate text and type, which it helps me do really, really well.

This is all to say that it’s my opinion that putting vim and modern IDEs in separate buckets is a classification error.

Reply

Who cares? You like VI, use VI. You like Emacs, use Emacs. You like IDE-du-jour, use IDE-du-jour. Pick your poison.

This point-free article wasn’t worth the five minutes out of my life that I spent reading it.

Reply

This is a bit like suggesting a Latex user that the future of text publishing is Microsoft Word.

I find a multi-pane terminal configuration with Vim the most powerful development environment for my current needs. I occasionally fire up VS Code to work on Jupyter notebooks. Trying to open a data file of a few tens of megabytes on these modern magic editors, you will find that the program will just freeze.

I also once tried Atom, which was unbearably slow to just start up. I probably would use an IDE if I worked on something that requires tight toolchain integration, like Java/Android or iOS development.

The ability to choose the right tool for the job will come with experience.

Reply

Reply

This is really weird. Have you tried Emacs lately? I has support for LSP, code completion, git, multiple-cursors, project management, linting, real-time LaTeX preview, etc.

Emacs has a few tricks under its belt still: when you do a text search (grep/ag/whatever), the results are in a regular text buffer. You can edit it as regular text, search in it, etc. When you save it, your edits are propagated to the underlying files. Earlier today I had to flip the arguments of a function in a nice language that doesn’t have refactoring tools. I did a grep for the name of the function, placed one cursor on each line of the result, used a keybinding to flip the arguments on each line, saved, and I was done.

Here’s another trick: earlier this week I had photos that were named IMG-01-02-2019, DSC-03-02-2020, etc. I wanted to rename them to 2019-01-02-IMG, 2020-03-02-DSC, etc. I ran `ls` from Emacs, I edited the results as text, using a macro to flip bits around, and saved, which renamed all the files according to my edits.

Can you IDE do that?

Your article seems to have a bit of confusion, I think: Emacs is an IDE, not a text editor. The only difference with Atom or VSCode is that the whole IDE is built around text, which means that you can interact with all of it with normal text commands.

Also, we don’t hate vimmers. Vim is great. We don’t hate anyone, really.
This “wars” thing is a load of ***. Everyone wants great editors and everyone wants a thriving editor scene.

Reply

Pretty sure most vim/emacs users know more about modern IDEs than the authors know about vim/emacs, yet the article is so supremely confident that their choices are driven mostly by fearful love of familiarity.

Remarkable lack of curiosity here.

Reply

This doesn’t even address Emacs, beyond “it’s old like Vim”.

With Emacs it’s all about the hackability. Whether you want to automate part of your programming workflow, or just don’t want to switch screens to post questions to Stack Exchange and search the answers, you can implement it right in Emacs itself or often find a package someone already wrote for it (and when they haven’t, there’s still a decent chance to use a library that makes it easy enough to write). Making it even better, if you want to do something programmatic with that web browsing, feed reading, email, whatever it is: typically having it implemented in Emacs makes it possible to further script as needed. Everything’s extensible, including the extensions.

To get extensions in most other editors requires either building a plugin or calling out to an external process. For instance, if for some reason you wanted to write a server for testing your web code in real time, you would write it in some other language like Node and then have your typical IDE call Node… but in Emacs you can literally just pull down the web server package and spin up your server in the editor. And even then, I doubt you’d get the same level of scriptability/extensibility, since to automate stuff using the add-on you’d have to have the source for the plugin or external helper and mod it directly rather than being able to just write code in your editor’s personal space that utilizes it.

(All this is to say nothing of the “stupid geek tricks” like how people have written desktop window managers for X in Emacs or are halfway to being able to use it as a System D replacement. There’s no reason you have to replace your whole OS distro with Emacs, right? Though you just about could.)

Really it isn’t an editor, it’s a language environment with text interface provided out of the box.

I’ll grant it does require a lot of looking into the options to set up things that IDEs typically give you out of the box. But: there are usually already packages for most things you’d want to do, including typical IDE stuff (someone mentioned Language Server Protocol, we’ve got that; also spellcheck, project browsing, version control, you name it), so you’re not starting completely from scratch either. And there is usually more than one package, so if you don’t like the way one programmer decided to do it, you can often try a few alternatives. It’s a tradeoff, but one that appeals greatly to programmers: after all, scripting up whatever we need is our whole job.

Finally, I’d be remiss if I didn’t mention Org Mode in passing. You could write a whole article on Org Mode, so I’m only going to give a TL;DR here. Basically, imagine Markdown, except it can do more – say, if Markdown were powerful enough to replace spreadsheets, wikis, simple databases, and calendars – and, like everything else in Emacs, it’s programmable. (Simplest possible example, think adding tags to your headings and being able to search by tags. Small feature, more handy than it sounds. You can actually add arbitrary programmatically accessible data, and timestamps support various scheduling tools.) It looks a little more dense at first blush because one of the most common uses is TODO lists and it uses headings for entries (try doing that in Markdown and you have some idea why Org documents often look… busy); but it can be used for plain old human-readable markup if that’s all you need, or it can be used, like Emacs itself, for just about anything. Some people learn Emacs just for Org Mode, and while I will say it took me a while to learn it, I can also say I recommend as strongly as possible giving it a try.

Reply

The reason I stuck with vi(m) throughout the years is simple – it’s available everywhere. Back in the day I was writing code for mainframes, workstations, PCs, and even the odd embedded microprocessor system. Vi might have sucked compared to the bells-and-whistles editors on some of those platforms, but it sucked universally on every platform, so I didn’t have to keep learning a new editor.

This doesn’t mean I’m opposed to IDEs – ever since Visual Studio came along it’s been the environment where I develop and test much of my code. But I see it as primarily a replacement for (g)db; a tool for debugging the code once it’s written.

Reply

Reply

Reply

Reply

> the 1980s, a time when Vim and Emacs were the primary tools used for coding

According to [Wikipedia](https://en.wikipedia.org/wiki/Vim_(text_editor)), the first release of Vim was from 1991. In the 1980-ies, it was just `vi`…

Reply

I will share my own experience as i am a new comer to emacs world and i had been using other IDE/Editors for years.

I am not attached to ide/editors very much, i have always liked simple stuffs which get the job done. I have used simple editors like geany, gedit even notepad sometimes. I have used heavyweight IDEs like eclipse, netbeans, visual studio, aptana studio, intellij etc. I couldn’t keep using them as they seemed either too light in features or too heavy to eat up all the resources of my computer. The i found visual studio code, and i thought, wow, its great, i have finally found something simple but feature rich or at least has the features i need. I have used vscode for nearly 2 years. I loved it. Then came in Microsoft, started to mess around things. In a simple one python script editing session, i found my computer hanging over and over again. After investigating, i found the reason was the ms python language server was taking nearly 6GB of ram. It was just little script, a Qt application. Very tiny script to be honest. But the ms language server was eating up every bit of ram it found. May be it was some bug may be something else was wrong with it. I don’t care. I always knew vscode isn’t a lightweight editor itself either as it is based on electron. The same killing all the resources kept occurring for multiple projects/types of projects – java, c/c++, javascript etc. I was getting frustrated about it. I know 8GB ram by todays standard isn’t much, but think about it again, 8GB ram isn’t too little either. It wasnt just the ram, vsocde and its extensions were killing my processor too. So i started looking for something else. I know about vim and emacs from way back, but never used them in anything other than command line editing. I thought, ok lets give emacs a try, i tried vim before with ycm and a lot of other plugins, but didn’t quite like the setup, i guess it wasnt for me. I started learning emacs, from tutorial to intro to elisp. Soon i realized, emacs is not an editor ! Its a freaking editor framework ! I had tried doomemacs and spacemacs but as i didn’t know much about emacs itself at that time, i couldn’t figure them out. So i stayed with default emacs and built up from that. Now i am using a lot of packages, customized to meet my needs. Narrow-widening feature was really cool, i don’t think any other ide/editor has that. I could even use different language server for different buffer even for the same language. I had to use eglot for a python script as lsp was too slow or incomplete with any supported server for that script. It was a simple gtk app. Anyway, the daemon mode is too cool. And the org mode! Damn, its just awesome. I am still discovering stuffs about emacs, and the more i am learning the more i am impressed by the extensibility of it. I don’t know of any other IDE/Editor that has this level of extensibility.

I have uninstalled vscode, wont touch it again. The idea of telemetry within an editor and its extensions, bothers me. I have used vim, its awesome too. But i think i am gonna be stuck with emacs and i will keep loving it.

Reply

First a few points about your article itself.
– You contradict yourself: you claim IDEs are better than VIM (for coding) only to explain all the nice advantages of VIM.
– Contrary to your claim VIM (as any reasonably useful tool) has to be configured, tweaked and fine-tuned in the same way an IDE has to.
– It hasn’t been about license fees for 10 (15?) years now.

Also a few points you (conveniently, or because for lack of knowledge?) forgot to mention:
– Do you know what your talking about in regards to VIM? Have you ever tried to use a modern VIM/lsp setup? And spent as much time in it as in an IDE?
– IDEs are really good when designing UIs, but there is so much software written that has no UI.

Additionally:
– I know many colleagues starting out with an IDE and THEN switched to VIM. Why?
– Because its FAST. Man is it fast. I have many IDE-colleagues that are always astounded by the speed I’m navigating and editing with.
– VIM are everywhere, getting good and fast in VIM also helps with all the other tasks that an engineer might encounter, e.g. system administration, configuration and debugging. I can SSH into any box and have a powerful editor waiting for me and I don’t have to use Nano to configure a system.
– Did I mention its fast? Thats also because I don’t have to take the hands of the keyboard to use a mouse. (I can, nowadays, but I don’t have to.)

Again: IDEs have their place, everything touch UI (including Android) comes to mind. For everything else? For goods sake be glad that there is choice.

Reply

https://medium.com/@mkozlows/why-atom-cant-replace-vim-433852f4b4d1

’nuff said.

TL;DR: Emacs invented the extensible IDE model that everyone copied. Vim invented properly composable commands that are only now starting to get properly appreciated.

It has it’s unsolvable flaws, but that’s what editors like https://kakoune.org/ are for.

Reply

Reply

> It’s less a war at this point than a grumbling shuffle of ingrained habit and stubborn resistance to change.

I agree. The new generation of programmers really need to pull up their socks and actually learn Emacs or Vim. They will really understand the meaning of terms like “memory efficiency”, “programmer productivity”, and “clean interfaces”. I am not including “shell commands” here.

Reply

I use vim a lot, after you get over the steep (almost vertical!) learning curve its incredibly powerful.

But the reason I learned vi was because I had to. Stuck in a cold data centre with a sev 1 at 2 a.m. You could be pretty sure that everything but vi was stripped from the production servers and worse ksh was in vi mode.

“ksh vi mode” — well if you hit escape in the ksh commend line you were effectively editing the shell history with a primitive vi using a one line screen. Which was very nice as long as you could remember the basic vi commands (especially “k” for up).

Reply

I’ve just won a bet with people saying: “yes but you can’t do this and this with vim” (including live debugging of remote Php code with display of the stack call).

Once you know how to cook, use your favorite knives, but stop spitting on the other ones. It’s not clever (at all). Waste of time. I could explain why PyCharm is good, why Rider is good, why vim is good *too*.

Watch my question here: https://stackoverflow.com/questions/1218390/what-is-your-most-productive-shortcut-with-vim

I’ve learned vim. And I’m using Rider, and PyCharm every day. Even with the “vim mode” in PyCharm they dont do 1/100 of what vim does, so I have, sometimes, to copy / paste from Rider to vim, work on the code, and copy / paste back.

Vim and emacs are just tools.

Reply

You forgot one thing – each developer has different needs. Many IDEs, like Visual Studio or the ones from Borland or Jetbrains, tried to be an all-in-one development environment, not only an editor.
Creating an UI in a visual way, using drag&drop, compile and debug the application, to creating and editing a database table in a UI, or creating an installer in a visual way.
For a beginner, the ability to discover and use all that, in an intuitive way, was the main advantage.

Emacs, Vim or VS Code target a different category of developers.

Reply

Reply

Thanks to its communities both vim and emacs are easily as powerful as modern IDEs plus having the potential benefit of being heavily customizable. I’m a junior developer who fell in love with vim during university. I tried a bunch of IDEs at different companies already but there is always something that I find inefficient or even annoying about them which makes me come back to vim.

I just don’t get the idea of this post. What’s the point of questioning other people having different preferences about coding tools?

Reply

This Text misses the reason for vim completely!

Yeah a lot of people don’t change because they could not be bothered to learn another IDE. But why? The other IDEs are all the same and are not better at all. There is a reason vim is still here and every other old editor is gone (yeah emacs has not a lot of users left). This article does not explain at all why vim is still around. It explains why old stuff still gets used while pointing out that only one specific thing “from the past” is used. It does argument for a statement it denies itself. This is highly subjective and unscientific.

VIm is still a thing because it is another (better) approach to text editing. No new IDE has it. Even the ones with vim keybindings only emulate the approach and will never be as good and mighty in it.

The mistake you do is seeing a text editor in vim. It of course is a text editor, but it should not be seen as one. It should be seen as a text editing language. You just tell vim what you want to do with the text: (c)hange (w)ord, (d)elete (w)ord, (y)ank (p)aragraph. And so on. It is easier to remember and easier to think of. It does not break your flow of thoughts. It is always `action subject`. Plugins do work the same.

Reply

Reply

I think you have to devote time and effort to any tool to decide in the long run if it’s right for you. I still use Emacs for some things and vim for others. Glad I know them. I usually use Visual Studio Code for PowerShell development and Visual Studio for C# for various reasons including supporting existing code bases that were developed with those tools.

There are advantages and disadvantages to everything and there are no exceptions. If you love Lisp as a friend of mine does, you may absolutely love Emacs, for instance.

Also in my development group, most programmers are barely proficient to start. I make them use an IDE since they don’t know anything else and may never be motivated enough to learn much, sad to say. It helps us generate more uniform coding.

Reply

Reply

Reply

Reply

The reason experts continue using the tools they trained on is because they are experts. Imagine telling a world-class violinist that she should use the latest Microsoft Supopangolinophone, which is (after all) “the future of music”. She may give it a try, only to find that she’s an amateur at it and it would take years of her life to become as expert as she already is on the violin. If she makes the decision to dedicate a chunk of her life to becoming expert on the latest instrument, she will find out a few years later that the Supopangolinophone is now obsolete, and good grief, why is she even using that when there’s the so much better Google Neutronivalvolinovox, which is not only whizbang, it’s “the future of music!”

And, so, she goes back to the violin.¹ People write blog posts about how she’s in a “raging war” with progress, but she doesn’t actually care: she just wants to enjoy making music again.

____
¹ Well, technically it’s a “vimolin” now, but close enough.

Reply

Reply

This article is dumb; it’s not like if you use VIM, you can’t use a modern IDE. I use Rider with VIM emulation for C# development. By doing so, instead of dropping my pinky to the CTRL key constantly (not a comfortable key to hit), I can stay in the home row all day without tiring myself out. There’s also the added benefit of being able to navigate linux text editors from command line.

Also, I am not a dinosaur, I’m 27 years old, and I took the time to learn VIM to be more ergonomic. Food for thought…

People bash VIM because they’re too lazy to learn it.

Reply

Reply

Having been a software engineer for about 20 years, and a systems engineer 10 years before that, I have always tried new IDE’s to see what they can offer. I usually see a demo with some feature that looks like the killer one that will make this IDE my new favorite too. I have always come back to vim for several reasons (and I would imagine, emacs users will say the same).

1. I have always found a way to duplicate the “killer” feature of some IDE in vim. It may work a bit different but in the end gets the same result.
2. Anyone that has been developing software for more than a few years most likely has several languages under their belt. Most IDE’s are good at 1 language. Even those with a good plugin architecture often work very different with each language. And adding each plugin usually adds a lot of overhead. vim is lightning fast editing anything.
3. vim’s modal editing offers advantages once you start thinking like a vim user. I reference Drew Neil’s Practical Vim. Simply understanding how to chunk work to make undo’s work the way you want is something no other editor handles well.

And there’s another reason to stick with vim or emacs. To master one tool instead of spending massive amounts of time always searching for the perfect IDE. And use that extra time to read articles on software development, design patterns, algorithms etc.

Reply

Emacs provide same services like “magic IDEs” but its keyboard controlled as opposed to IDEs being mouse controlled. Of course, IDEs have some support for keyboard shortcuts, but its as good as mouse support in Emacs. Its terrible. Its impossible to not use mouse in IDE and its impossible to not use keyboard shortcuts in emacs.

Mouse control is slow and interrupts flow.

Second major Emacs advantage is its unparalleled extensibility and explorability. All emacsers use heavily customized Emacs to their needs because the price to do so is small.

Comparing your “magic IDEs” and customized Emacs is like comparing sword and gun. Both do the same thing, but latter a lot more effective.

Reply

I’m sure it’s not just me, but one of the things I appreciate most about Vim is that it gets out of my way, and doesn’t require me to look for my controls, or use the mouse to activate them. All of the GUI features are just noise and inefficiency from my perspective.

Most, if not all, of the revered features and plugins and features in VS Code and the like can be accomplished as competently, and probably more efficiently, with a little bit of Vim customisation.

Admittedly, the initial learning curve presents some challenges until you can fly, but once you get over that hump you really can fly. And for me, the grammar of Vim continually provides inspiration. I think it has the best UI of any application I have ever used – seriously.

Reply

The way that this article characterizes Vim/Emacs as residue from a past era seems to miss the point that Vim continues to attract new users for a variety of reasons other than some weird nostalgia for a time we weren’t even alive for. This might be forgivable if it stopped there, but to go further and say:

> there is a Vim Mode package [… for users …] unable to let go of the past, unwilling to fully embrace the future of code editing.

is simply ridiculous. Vim plugins enhance the abilities of an IDE (ignoring some conflicting shortcuts 😅) by adding Vim’s unique modal way of editing – a way that many of us find more efficient than the mouse-bound default. It’s not remaking the IDE in Vim’s image, rather just adding a bundle of helpful shortcuts.

Reply

Reply

“Our fingers are often the bottleneck between thinking up code and getting it in the app, so that’s where folks look to optimize shortcuts.”

This quote is self-incriminating in a sense as it reveals the attitude that code is nothing but keystrokes, sold by the pound-per-minute and that refactoring is some indulgent sin. It belies the attitudes of text editor purists who don’t appreciate that code should represent a semantic modeling of a problem/solution as it’s understood in the moment. Not just a clutch of text files that are fulfilling their purpose out of sheer coincidence, forever accruing complexity as changes are incrementally piled on in haste.

Now… I think people can have some degree of success with pure text editing, but having worked on many systems that were put out in a hurry under this philosophy, I’ve also come to understand that it does more harm and levies a cost on productivity. I think of it as a risk to business continuity for the vast majority of companies out there. Text editor purists often impose odd and highly personalized constraints and conventions on their team just to ensure that their fragile workflows and habits aren’t challenged. Topics like project bootstrap, directory structure or file names end up contentious as you progressively uncover generations of mnemonics and shortcuts they’ve bled into the languages they employ and the SDLC they apply. All to compensate for the absence of editor code awareness which – to me – is a metaphor for analysis and reflection.

As a result, the list of secondary symptoms I’ve observed is telltale… Weird userspace tools and build flows end up being concocted to perform structural chores – we could easily segue from this topic to a study of the overlap between preference for monorepos and text-based puritans. Inevitably, there are communication pains and gnawing deficiencies in onboarding that are either never organically encountered (lucky!), or sit perfectly in the blind spots of leadership (turnover!).

I make use of Visual Studio Code as a notepad replacement or for small projects where the deliverable is more declarative than procedural (terraform, docker compose). But if I’m working on core application logic in a C# or PHP (etc…) project? As noble as they are, text editor puritans are immediately at a disadvantage, even in the simplest of codebases.

So. Use what you want in the end and show me that it can work in the merge reviews. But I see more practical evidence against the productivity hype and I think if most text-mode fans put as much effort into a JetBrains produt as they do their text editor of choice, they would realize that keyboard shortcuts aren’t exactly new anymore. More importantly though, we might even benefit from having to hear less about vim…

Reply

Most of my tech-literate friends use all manner of GUI IDE’s, and pimp them until new coal plants need to be fired up to keep up with the increased energy consumption all the bling causes.

The primary reason I stick with vim is simply that I move around a lot; NetBSD, macOS, Linux (regular distros, plus a custom/minimalist embedded build), Windows. Sometimes I have access to GUI’s, sometimes ssh, and sometimes I only have a tty over rs232.

Not only do I use vim, but I use pretty plain vim. I don’t add a bunch of junk to it, because I don’t want to get hooked on a bunch of bling that I won’t be able to use in all places I need to work. I’ve noticed it’s a hobby of programmers and sysadmins I know to waste a lot of time complaining about not having access to their pimped up editors/environments. I don’t want to put myself in that situation, I want to get work done — not cry and whine about not having My Perfect Bling Setup.

I’m not ashamed to admit that if I could get all that ultra-bling, consistently, on every single platform I need to work on — I would probably call the energy company and tell them to fire up another coal plant for all my bling, but at the moment there’s nothing coming even remotely close to being both as portable and productive as a plain vim.

Reply

UNIX is the best IDE that can exists.

bash, sed, awk, grep, wc, head, tail, ed, etc.

You need to learn how to use it like any good software.

To grasp the nature of that you need to read between lines in the mind of their creators, Dennis Ritchie, Brian Kernigan, and others.

Reply

“…a grumbling shuffle of ingrained habit and stubborn resistance to change.”

And your point?

Learning new tools take time. Since the new IDEs don’t significantly increase productivity, why learn them? Give me something that saves me time and I’ll use it.

Reply

Some comments here can be summed up as “I love how lightweight vim is, but I use a bunch of plugins to make my life easier”. Well, why not just an IDE then?

Of course this doesn’t apply to everyone, but most people I’ve watched use vim were quite slow with it and took forever to do simple things that would be quite easy to do in an IDE or even just a graphical text editor like VSCode. I’m guessing in discussions like here only people who really love vim and customized it heavily actually participate, while there is a large faction of people who just use it out of habit, without ever questioning their habits and if another (more modern) tool would be a better fit.

Reply

“Most importantly for users who didn’t start coding in the last five years, there is a Vim Mode package. This has led users to literally turn Atom into Vim”

This creates Atom with vim keyboard bindings, not a clone of vim, least of all literally.

“unable to let go of the past, unwilling to fully embrace the future of code editing.”

Nothing in the article backs this statement. Moreover, I don’t think the generalizations of peoples’ behaviour/personality based on their editor choices, is grounded in anything. Personally, I think vim keyboard bindings are great. If you don’t think so, it tells me very little about you (and not “unable to break out of their comfort zone; unwilling to fully embrace their potential in coding”).

Reply

Reply

I work with Jetbrains IDEs and I can’t say no to the powerful refactoring features it has. Refactoring in vanilla Vim is way harder, if you gotta get plugins for all the languages of choice, then better go for a full featured IDE.

That being said, I think knowing how to use Vim at a basic level is an essential skill, due to this omnipresence of the editor in Unix systems. Being able to code comfortable for a few minutes with Vim lets me do some quick hacks in servers without having to scp the content… develop in my full IDE and upload back. That’s where vim excels at, code editing anywhere, just with an ssh session.

Vim is very powerful indeed. And I highly appreciate its features when I require them. It’s just not an IDE.

Reply

Reply

I have always been shocked at how little people who edit code for a living know about their editor — regardless which editor they choose. I doubt that this changes much with an IDE. I think the difference is if a team is required to use an IDE then someone else has made this all work for them and only through the IDE can they get necessary resources.

That said, I put quite a bit of effort into getting Eclipse working at a company, and since I could not make it mandatory, no one started to use it. Including me. It was too much trouble to keep it working just for myself, so I stuck with emacs. You don’t need anyone to handhold you with emacs/vim, and there is no downtime associated with problems with the IDE.

Do IDEs really make most coders more productive? I am not so sure. The folks that only know how to copy paste, search, and save are not commenting (or even reading) this thread, so we are really only preaching at the choir here.

Reply

Reply

Dude, editor wars are *so* last century.

There are a brazilian different kind of developers out there, from people who spend their entire day doing C++ for embedded systems, to people (like I was in my last job) who would work in three or four languages IN ONE DAY (in my case Bash, Perl, Python and a dabbling of SQL. Oh, and occasionally whatever that depraved stuff inside Excel is).

Some developers work *entirely* on their local machine and submit their code to a testing pipeline that ships it off to another machine to run. Others have their entire build infrastructure locally.

Others work *entirely* (or almost entirely) remotely.

Almost none of us work the way you do.

In my last position I was *given* a laptop running a corporate image (Windows 7) and was (barely) able to get Cygwin installed on it. But that job was doing Linux stuff for Linux servers, so *all* of my development took place on remote systems *THAT WERE NOT UNDER MY CONTROL*. Installing random IDEs was not possible. I could have (maybe) jumped through a lot of hoops to build and install one, but then I’d have been running it in a X Session through an SSH tunnel over a VPN over half a continent.

Or I could open 3 ssh windows, one for vim, and the others for running the code and watching logs.

As one of Shakespeare’s characters once said, “There are more things on heaven and earth Horatio than are dreamt of in your philosophy”.

Vim is for people who like Unix, and who think in Unix ways. It could be argued (and I have) that if something called “vi” isn’t installed by default, it’s not a unix-like OS. This is why people who *like unix* know Vi, and often use VIM.

There is a *vast* overlap between what you can do with vim (and/or gvim) and what you can do with even the most sophisticated

Reply

With LSP plugins, vim and emacs rival any IDE. (And just think of spacemacs, or neovim.) So what remains of any of the quoted arguments then? Is maybe the IDE the lazy, dated way to code at the end? I’m not saying that is necessarily the truth either, but the article sure doesn’t succeed at convincing me otherwise even though it really wants to. Please scrap this, and try again when you actually looked at how advanced users use vim and emacs, and write a properly researched article and not just a hit piece.

For what it’s worth, I’m currently using VS Code. But it’s not really for any of the shallow, misleading motivations given in the article.

Reply

Ok, there are a few Vimmers here who can’t seem to take a little tease 🙂

I love the sh*t out of Vim and use it all day, every day. But not for developing complex applications. Writing modern Java applications in Vim, for instance, would be pure torture if you’re used to IntelliJ and everything it can do for you in terms of dependency management, code suggestions, refactoring, ootb integrations with all kinds of extra’s, from integrations with ci/cd pipeline applications to version management integration to multiple types of code analysis to security scanning to test automation to logging integration to file management to documentation systems to issue trackers to local file backups (and that’s just a few things I remember I used this afternoon).

Vim however… Vim is what I use when I’m nerding out on the command line. It’s there when I’m on remote linux servers with only an SSH connection and no X environment, it’s there when I want to quickly browse through long text files, it’s there when I need quick regex search/replace in 1GB log files, it’s there when I want to do a controlled change in a dozen nginx configuration files, it’s there for writing and managing script after script after script, it’s there for quick in-situ changes to code that I wrote in my IDE…

IntelliJ is like having a co-pilot with you during development. It’s like a self-driving car. It’s like a life partner who never tires of trying to guess what you need and make you happy, who cleans up your bedroom while you go out dancing and kisses you goodnight when you come home drunk. It gives you true comfort.

Vim however makes you feel like Neo in the matrix. Like Gandalf in Lord Of The Rings. Like Jason Bourne in… well… Jason Bourne. It gives you true power.

I wouldn’t want to live in a world without beautiful IDE’s.
I couldn’t live in a world without Vim.

P.S. I never felt the need to try Emacs.

Reply

In the work that I do, developing instrumentation systems, IDE’s are almost always unnecessary and very often, counterproductive. The often hide too much, leaving the developer with scant knowledge of or control over a lot of what is being executed.

And where the IDE is for the purpose of facilitating untrained, unknowledgeable or inexperienced programmers, its use in high end technical computing is simply an oxymoron. The novice would do better to do it by hand, with make and an editor and learn how things work.

Reply

Why should I spend valuable time learning many different IDEs—IDEs that keep changing—when I can efficiently just use one or two familiar editors—editors where I know the keyboard shortcuts, etc, that empower rapid working.

What I want is software developers to make it easy and obvious for me to interface their software with my choice of editor. What is hard about that?

PS I also want software developers to stop grabbing my entire screen, so that I can use windowing environment as I want, not as they want.

Reply

Counterpoint: I’m 24 and use emacs. Contrary to what you say, not everyone my age is using VS Code or Notepad++ or Eclipse or what-have-you; I have a friend who writes his programs in nano. No, really, he does. So did I for a while, until I fell in love with emacs’ features.

I really like emacs, and I don’t think it’s about to die in favor of VS Code or whatever the editor of the month is. Nor is Vim.

Sure, I use cua-mode because the cut/paste (kill/yank) shortcuts are too ingrained in me at this point, but most other bindings are fine, if a bit weird to get used to (search-and-replace took a while to get comfortable with).

I had a much longer reply written up a day or two ago, but it looks like something ate it. Maybe I walked away and forgot to hit “post.” It was a little rant-like, though, so I think this is better anyway.

Reply

In my opinion, IDEs lower the bar for entry, but they don’t raise the bar for the quality of the end result.

Most IDEs promote mental laziness. They allow programmers to build programs that work with just a superficial understanding of the language facilities they use, with things like autocompletion. suggestions, etc. In the end, a lot of those programs end up on Stack Overflow piece by piece because of an edge case, a race condition, or simply wrong logic. The integrated debuggers do not help either because the developer simply doesn’t know the assumptions made by other developers. Once the necessary in-depth knowledge is acquired, the use of IDEs become unnecessary: you can simply be more productive than most IDE-users using any other editor.

In short, IDEs help with the process of writing only, not with the quality of the end product. That still relies on old fashioned know-how.

I use Emacs exclusively for writing programs and switch to VScode for debugging only. Everybody has their own toolset they are comfortable with.

Reply

Reply

I’m going to join in with the piling-on of the ridiculous “unable to let go of the past, unwilling to fully embrace the future of code editing” description. The author(s) who wrote that either didn’t read or didn’t understand the Medium article they linked. It is not about making Atom into a complete *clone* of Vim (using Vim plugins), it’s about making Atom *feel* like Vim at the keyboard. The author of the Medium article is using Atom with Vim keybindings. How is using a modern IDE being “unwilling to fully embrace the future of code editing”? No, using Vim keybindings in Atom is leveraging decades’ worth of experience of one set of keyboard shortcuts, and bringing those keyboard shortcuts into a modern IDE. It *is* embracing the future of code editing, and doing so intelligently by reducing the friction involved in learning a new tool.

This could have been a good article, but flaws like this misunderstanding of Vim mode undermine the article’s foundations, and leave me wondering what other parts of the article are wrong because the authors have misunderstood something.

Reply

This article does not make any sense at all. It states that people still use vim/e because they are used to it.
But you see, people with vim use git, they use linters, they use modern languages and they use a lot of features from modern IDEs.

So somehow everything has changed, but vim survived. And the reason vim survived should be the fact that people do not like switching to new things? That is why people still use ed… oh wait that one is dead, maybe it is too old? So surly there is still Netbeans? Yeah but the market share is pretty low.
And that is not the only example.

Somehow vim survived all this editors, and the article does not even try to understand why?

Reply

I’m grateful that I’ve never worked in a team that gave a darn about my choice of IDE and/or text editor.

There are very few tools which a development team actually need to agree on. The most important ones their version control system, their ticket/issue tracker, plus whatever lint/make/test/deploy recipes are deemed important.

Most other tools can be left to personal choice. Contrary to the theme of this article, your choice of text editor/IDE won’t make you a better developer – though they might make you a happier one! If one developer likes an intelli-sense sort of code suggestion, while their colleague prefers to browse API documentation, that’s totally fine. The same goes for your choice of file manager, window manager, SQL client, diff tool, terminal, input devices, log viewer, and what-not.

Pair programming and code review sessions sometimes warrant a compromise, if you’re looking at the same screen. In my experience the most important thing was finding a colour scheme and font size that we could all read comfortably.

I’d like to note that there’s some unpleasant casual ageism in this article. I found “a grumbling shuffle of ingrained habit and stubborn resistance to change” quite offensive.

Reply

Reply

I’m not sure you understood the point of editors like vim or emacs.

It’s true that modern IDE provide some more functionality out of the box (debugging for instance).
But they can’t provide the speed you can achieve with both vim or emacs.
Did you saw a dev who really know vim editing code ?
This tool is pure efficiency, once you grasp the concept you can never go back.

That’s why you will find vim keybinding, emulation or even neovim emulation in most of modern IDE (vscode has both vscodevim and vscode-neovim plugins).
The speed and mental resting you get from using vim is and always will be worth the investment.

Reply

I started my programming career back in the early 1980’s. I didn’t code on/for a Unix/Linux platform until 2015, and that was only for 2 years.
The argument over IDEs vs Vi/Vim/Emacs has been completely irrelevant to me, in my almost 40 year career.

There does seems to be a view by a lot of programmers that coding for the Unix/Linux platform is the ONLY programming worth considering!

Reply

Reply

Reply

Reply

I recently had my work laptop constantly slowing down with OS processes eating CPU and memory . I used IntelliJ IDEA extensively and it was a godsend. Unfortunately, it became unusable, not even reinstalling my OS install from scratch helped.

It will take a while for me to get a me a replacement laptop, so, I had to use something lighter. Even VS Code was weirdly slow. I decided to code from an EC2 instance we have for development and running services. After installing nvim and searching for some plugins, I configured coc-nvim, fzf and other ones.

I was surprised with how good it was as an IDE. Autocomplete worked just like in VS Code, syntax check was better (because the EC2 instance is very very fast), go to definition and find references worked like a charm. It took me a while to make it work like I wanted it to (I like to config small details to my liking), and the only thing that still sucks is Java development with Bazel: IDEA is still the only feasible choice. But for JS and Python development, Vim is pretty good.

BTW, thank you so much, COC creators! It’s an amazing plugin.

Reply

Sorry, this post is a little malformed. Vim and emacs are still there not because “old” people can’t switch to a “modern” text editor (or IDE, they are totally different things and have different purposes).

It all really depends on what you are doing, for example Vscode seems to have the best support for JS and its frameworks, but it’s not the case about Ruby.

I use vim and I’ve been trying to switch to Vscode or RubyMine for quite sometime, but there are key missing features it’s really hard for me to leave behind. One is tabs vs buffers, in vim you can have different split layouts for every tab. (like 3 splits in one tab, 2 in the other, 0 in the next, etc)

In neither of Vscode and RubyMine you can have fuzzy search (I’m not talking about file fuzzy search), I’m talking about fuzzy searching your files contents, it can be done on them using regex, but it’s way more complicated. In vim/emacs you can just add a plugin for ripgrep, plus it’s crazy fast. The new search editor in Vscode is promising though. Can’t wait to have fuzzy search on Vscode.

Go to definition using ctags. It’s been around for +20 years and it’s still my default way of going to definition on vim, not because I’m old, but because it is the best for the codebases I work on, plus there are plugins that keep the ctags file updated so I don’t need to worry about it. in Vscode (and vim) you have LSP servers that don’t always work if your codebase is larger or not exactly following popular code styles (it’s getting better though, I’ve been trying it our every now and then on vim and vscode). RubyMine in this case has the most amazing go to definition tool. The same thing is valid for seeing references where a method/class is used.

I feel like Vscode users don’t like to customize their editors other than installing plugins/themes and that’s ok (it’s not even possible to write functions without writing a plugin), some vim/emacs users also don’t like to have IDE-like features and that’s ok too.

I’m surprised that RubyMine still doesn’t have file previews when search for files, but it has a great previewer for when searching file contents, and you even can edit the file without properly opening it.

Just wanted to conclude that, every text editor or IDE has its own pros and cons, but I’m excited to see that their creators look at each other.

Reply

Reply

Reply

Reply

Reply

I actually started coding in Emacs by requirement, having come from Matlab and Eclipse because the toolchain for Fortran90 is basically non-existant in modern IDEs. I predate VSCode by about 3 years, and when I started doing more Python than anything else, I moved into Pycharm for a couple of years.

However, like most Pycharm users, while I liked its interface, I found its toolchain to be laggy, its design unintuitive and ultimately, it tied you to a particular set of products which meant that if you learnt the interface for one, you were stuck in their ecosystem. I ended up going to Doom Emacs, and when I move to a new position I will take most of what I have in Doom Emacs with me if I can. Otherwise, I will use VSCode.

The first advantage of Vim and Emacs is just that – a universal interface to coding. In a way, VSCode is the first real competitor I’ve seen to either Vim or Emacs, and honestly if Emacs were more user friendly from the outset and wasn’t programmed in Lisp, it would have taken the world over a long time ago. A combination of Vim and Emacs is a much better editor than VSCode is.

The second is their combined suite. Far from being competitors, a large amount of Emacs and Vim’s functionality has been ported between platforms and refined. The Emacs community long since conquered modal editing and in fact the main modified distros come almost exclusively designed for modal editing and leader keys. The Vim community, which is a little slower to adopt new ideas than the Emacs community, nonetheless has fully functional versions of most of the best aspects of the Emacs ecosystem, such as magit and alternatives to ivy/helm. Both have fully functional, well supported implementations of the LSP protocol, as well as faster, more conventional alternatives like rtags.

Third, IDE information overload. IDEs are designed to contain your full toolchain inside a single GUI. That makes them push a lot of information on a developer, and because they are doing this and the toolchain outputs a lot more information than any GUI can contain, they ignore the actual toolchain behind it. Emacs handles this by providing a general interface to similar capability for every language it knows. That’s a massive simplification for any individual using more than one set of tools.

Fourth, modal editing. Vim or evil-mode is the only way you should be editing code. Being able to move around the screen without so much as ever touching a mouse frees up so much effort that it’s actually hard to describe until you learn it. The ability to pick a word, or a line, or 10 lines, and just kill whole regions, moving them around, undoing and redoing with a literate undo tree and without ever using your mouse is incredible. After learning modal editing, using a non-modal editor actually feels like you’ve lost use of your thumbs. Vim and Emacs naturally allow you to ignore your mouse almost completely, so are natural extensions of this practice

Fifth, it gently introduces you to the actual toolchain. Emacs and Vim don’t tend to mess around rewriting capabilities that already exist. What’s your choice of C++ LSP? Well, you can use rtags, the legacy system, the inbuilt dumb autocompletion, or any of the language servers available on the Unix platform. Or you can use nothing. By and large, it will assume you’re using nothing, but getting it working is the work of about 15m.

The main disadvantage is that it never works straight out of the box, but in programming almost nothing ever does. As a consequence I’d actually recommend an IDE to a beginner, but as soon as they have their teeth, I’d say pick either vim, emacs, or VSCode.

Reply

I disagree with the article a lot. Working with Vim definitely isn’t a sign of resistance to change, it is just a choice that lot of people prefer. I for example came to vim much later in my career, after using Eclipse, Intellij, VS, VSCode and others. I at first also thought using vim nowadays is kinda crazy and more suited for OPS guys living in the shell all day every day. But once I got a taste of what Vim can do, and of the perspective of never having to leave my keyboard for mouse again, there was no going back.

Don’t get me wrong, I am not die hard fan of vim. I still use other IDEs every day (thought with some vim plugins) usually for server side coding, while I use vim for frontend or maintenance tasks fully. I don’t view it in religious terms, like we are waging war against some differently minded group of people or similar nonsense. I just use the tool that I feel more productive with, or as in case of vim, I see the productivity curve going up in the future. Yes, after 1 year of using vim, I still feel that I have blind spots and I have a lot more room to improve using more of vim features, or that many things were somewhat easier in IDEs, but still using Vim feels great.

You see, one of the reasons I didn’t give up on vim, is that using it is honestly a lot of fun. It’s a great feeling to edit text in a smart way, engaging your brain in how to edit code in as easy way and using as few keystrokes as possible. And doing so gives you that rewarding feeling when you manage + it adds new skill to one’s toolbox. I never had this fun feeling with other IDEs.

Last but not least, recently I switched coding yet another project to Vim because it just doesn’t consume that many resources as eg VSCode (with all language servers and pluging, Vim still consumes ~1GB less of memory) nor does it take that long to initialize as eg. Intellij Idea. Especially if your hardware is somewhat limited (yeah, it can still happen nowadays), performance is yet another reason to switch to more light weight tools like Vim or I guess Emacs.

Lot of people love to use full blown IDEs and I totally get it. But frankly speaking, if eg. NotePad (exaggerating here) makes you productive, why not use it? Whatever floats your boat. And yes, we vim users get some crap from our colleagues, but I actually find that very funny and it only makes me want to get better in using my tools. So no, I don’t see the text editors’ user base dwindling, resisting change or unwilling to improve. I see people having different preferences while still maintaining productivity, and I also see old tools refusing to die, and in fact continuing to thrive (old is gold), and it is frigging awesome to observe.

Reply

Absurd that you didn’t really consider the intrinsic benefits of so-called legacy text editors.

The arguments in favour of them, such as they were, seemed to boil down to ‘developers are stubborn…set in their ways…muscle memory’.

I’m a relatively new developer who has gone from bells and whistles VS Code to Vim. I’m more efficient as a result. I’m not alone in this. Some of us also have standards/ political awareness and hate the current second coming of Microsoft hegemony. They now own VS Code, Atom AND Github.

Reply

Vim and Emacs are not dinosaur editors for dinosaur programmers. I use vim (I’m 18) even though I have access to pretty much any other IDE such as eclipse and vscode. Yes, vim and emacs are older, that doesn’t mean they are bad. They are fast and they don’t have all the bloat and memory leaks that come with graphical IDEs. The code was actually written well, rather than allowed to be slow and contain memory leaks, and whats more is I can have any functionality with vim/emacs just by installing plugins. I can have autocomplete suggestions and my project tree in vim, just like the features in a graphical IDE.

Another thing about vim and emacs is I can run them over anything, on anything. I can run them over an SSH connection if I want, i could do it on a terminal emulator, or over an old serial display. I can run it just fine on an ARM based system with a 300 MHz processor and 32 MB of ram with no issues. I couldn’t do this with an IDE like atom, eclipse or vscode. Another thing is keyboard shortcuts: I’m much more productive with just the keyboard rather than aiming and clicking with a mouse. And I want to stay in my terminal, too. So if I want to test my code I quickly save, go to terminal, then build and run my program. In this scenario, I know exactly what the build process is, because I set it up. This makes it more universal, so if I send the code to a friend they know how to build it too regardless of their IDE.

This post is clearly trying to start an argument. I use vim because I want to stay in my terminal, I like keybinds, and its the most productive for me. I’m not intimidated by a terminal, and I want to know what everything is doing.

Reply

Reply

I use Vim for a few years coding occasionally for fun and pleasure. It is so great because it is just what you want it to be. I have a great desire of not seeing all the icons, text, features, just the black screen with some code. No toolbars no clutter, no asking for anything, just extremely efficient operation.
Not touching your mouse is an enormous advantage, it’s only neccessary to take a few months dive into Vim to get it.
If plugins ant fireworks are required they can be added, sometimes with a lot of trouble and frustration. When after days of fiddling and not getting there you install VSCode and it’s all there just like that, the question arises inevitably…
I guess there are people who like these editors and one’s that are never going to like them, great coders on both sides, it’s a matter of brain structure.
Vim in all it’s convoluted self is very simple and clear. Like a knife with a restaurant grade kitchen in the handle.

I’m also not sure if it requires to agree with a 100 page license.

Reply

Reply

I admit that i am “unable to let go of the past, unwilling to fully embrace the future”.

Sometimes there is a tool that is a joy to work with…

For example. let’s say I want to reproduce something i did. In a modern IDE of the future i could triple click on a line, right click, find and choose copy, move the mouse, line it up oh so carefully, right click and choose paste. The reproduction is perfect, it will even copy any formatting. Or, I could be more antiquated by using vim and type “yyp”. There is a bit more joy in the simplicity of this, even though the reproduction may not be as perfect without formatting, but it is good enough really. Or then, I could be extremely antiquated and use the Proterozoic technique of old fashioned sex. Personally i am a relative newbie to this 1.2 billion year old tool, and i have found that this older method definitely takes a lot longer, and the eventual reproduction is definitely less than perfect, but it is a tried and true method that is an absolute joy to use… It may be old, but i’ll stick with it. Sometimes, the older ways are simply better.

Reply

Reply

IDE’s, particularly Intellisense type features, can be extremely valuable on a large or unfamiliar codebase, or with a language/framework one is learning.

On a familiar codebase with a well-known language/framework(s) and a well-curated set of snippets, nobody using an IDE is going to come anywhere close to the productivity of a coder using a fast editor (unless they turn off intellisense and the other features which essentially replace long-term and/or muscle memory).

Reply

Does this article seriously try to argue that devs use emacs and vim because we don’t want to customize an ide but instead just want to sit down and use vim? Yes, of course the bloated IDE is more customizable than bare-bones infinitely expandable editors with tons of packages made over the last 30 years. Obviously it’s easier to customize a closed-source IDE with 5 million SLOC than a comunity driven project like NeoVim.

Vim and Emacs have outlived many generations of “the future of editing” IDEs, and will keep doing so.

Reply

My preferred IDE is Codelobster – http://www.codelobster.com

Reply

Reply

Use the right tool for the job. I use IntelliJ for Java + Scala development and I use GVim for almost everything else (Python, Perl, YAML, shell-scripting, etc.). I will typically use GVim for most things because IntellIJ, while I appreciate how productive it is to use this IDE, consumes an upwards of 5G of RAM, which is beyond absurd and even with 32G of RAM I still find my machine touches the swap file because as a developer I’m also running Slack, Teams, FireFox, Minikube, Email as a bare minimum. Don’t forget that these dev tools spin up persistent Java compilation daemons as well, I have 4 running right now that add-up to another 5G of RAM.

A well designed Java-based IDE (IMHO) would reuse objects as best as possible and employ soft and weak references where appropriate, particularly for plug-ins and features that aren’t always used.

We’ve taken Moore’s law and used at as a crutch instead of a gift, and that is why comparable applications run no swifter today than they did 30 years ago.

Reply

Reply

I’ve found that applying perspective to situations and looking for a balance applies to, well…EVERYTHING. Even if you excel using an IDE and understand the things it is doing in the background, if you open up your vim’s, nanos, etc. and are sheepishly pecking around like a hen, scared you’re going to blow something up, then you are limiting yourself. I say you should learn those and be comfortable with them. You won’t always have an IDE.

Conversely, what if you’ve known vim your whole life and are pretty great with it? That’s fine … I know I’m going to get someone screaming at me for this … but I still think you should open yourself up to learning AT LEAST 1 modern IDE. Just to be clear, I’m not saying I’m leaning towards IDEs. I’m saying you should adopt BOTH – older AND modern.

I work with someone who primarily uses vim. He’s super fast with it and can for sure duplicate IDE functionality at times, but is also stubborn and completely unwilling to even TRY an IDE. I’ve never really understood this. As programmers, we generally embrace automation and love tools that CAN help us be more productive. Why does having an IDE that does this, for some people at least, get overlooked here?

Again, I think you are just limiting yourself if you say “X is always better.” Be willing to learn and use both. In my eyes, a good programmer is the one who is willing to adapt, and just to be clear, that means ALSO LEARNING an older text editor. I prefer vim in this case and use it all the time – very quick and great for opening something on the fly, finding text, doing a quick edit, etc. I often treat it like a great investigative tool. If there’s an issue, I tend to go to the server and will pull up vim. However, if some big request comes in and requires changing multiple files in a repository, then I will usually opt for the IDE – I prefer Jet Brains – though this isn’t ALWAYS the case.

So there you go. I like to use Jet Brains IDEs AND vim. If you have something say, please keep the criticism constructive. There’s rarely a reason to be unkind to someone.

Reply

Reply

Reply

What a lot of prejudiced drivel. After a career of approaching 40 years in IT; as a developer/devops/sysadmin, even somewhat bad network engineer, I can tell you that one thing I love about IT is change. I love scripting in (ba)sh, but then found Perl, which I found ugly. Moved to Python, it’s OK – and I like(d) that indentation matters. Then found Ruby. Ah, home at last! For compiled languages, it was c, then C++, a smattering of D, then I finally found go(lang). Ah, home at last. Of course, being an oldie, I’m resistant to change. I don’t much _like_ systemd for some glaring problems, but I accept it has become the default. Oh, but I’m resistant to change. I do devops, have a lapsed AWS certification, and embrace the cloud. But I’m resistant to change.

Throughout my career, vi, then (as someone else has pointed out, silently) vim. I’ve tried IDEs. None have seemed as logical and intuitive as vi(m). I’m not averse to change, but I already have a nice, sharp scalpel which fits my hand nicely – and I’ve had the joy of introoducing vi (and the Unix toolchain) to new programmers, who already know IDEs. They have enjoyed using vi.

I have no problem with change, actually. What I have a problem with is arrogant idiots, young and inexperienced or otherwise. What a pair of ******s.

This article is uninformed, pejorative, inflammatory. Flame-bait. Nothing to see here. Move along.

Reply

Reply

I find the notion that Vim/Emacs users only use those editors because they are stuck in the past rather funny. For many of us, it’s the end of a long journey.

When I started out in computers, I used funny command-line things in DOS like “QEdit”, “QuickBasic”, and Borland’s C++ environment; I also have fond memories of editors like “The Bank Street Writer” and word processors like WordPerfect 5.1. When I started to use Linux, I quickly discovered Kate and fell in love with it, even though it fell way short of the ideals it promised to deliver on (and it fulfilled those promises over the years). Indeed, I did most of my development in Kate, and when I wrote my dissertation, it was in LaTeX written in Kate.

At a couple of workplaces, I was required to use Eclipse or IntelliJ, while co-workers used SublimeText. I didn’t second-guess this, though I had a couple of times when my computer had crawled to a standstill (in part because I kept files open from tickets in testing, which meant having lots of files open, to be ready in case they came back to me) — and when I had something critical I needed to complete during this time, I found that using Vim, as clumsy as I was with it, was a lifesaver!

I first took Emacs seriously when I looked into Common Lisp, and I found the environment was quite impressive, even though I never fully “took” to it. About a year later, I saw presentations on the power of Vim, and I started using Vim myself — and I fell in love with it, and have been using it ever since (even though I still have a great admiration for Emacs). Between Bash, TMux (and the occasional Screen inside TMux), and Vim, along with a few plugins and command line clients like MyCLI or HTTPie, I have discovered a *fantastic*, *very* lightweight, and *very* flexible IDE. Indeed, I have found that when I have multiple projects, or wish to have multiple tickets open at once, I can *easily* have them available in the background of my system; I can *also* save some of these via session tools, and open and close things as I find fit to do so.

I do not use Vim because I am old-fashioned, and resist change. I use Vim (and TMux and Bash) because I’ve tried “modern” IDEs, and have found them lacking. (And to the degree I *have* resisted change — in particular, I have heard *very* good things about Zsh, it’s with a sigh of regret, wondering when I could find time to try those things out, and whether I could find time to port my customizations of Bash to Zsh.)

Reply

Summary
VIM PROS:
– Open Source, strongly invites you to contribute.
– HJKL key setup is amazing
– Very customizable
VIM CONS:
– Lack of extensions in a work environment
– Some extensions are not up to date
– Commonly you will have to spend time expanding your configuration to your liking
– Very rustic. Let’s face it, who likes to spend 3 hours in front of a .vim instead of in a menu / marcketplace, etc.

I encourage anyone who is interested in NVIM to give it a try because you may find in it what you are looking for, but I think for most lovers of Open Source and software development, VS Code is a better option.

I discovered some time ago that people take advantage of VIM for tasks like competitive programming, and I recently started refreshing myself in c ++ for my new job, so I wanted to do code challenges.
So I went into a long odyssey to see if I wanted to use NVIM, unfortunately (or at least not so much because now I know what nvim is) I started using it. I am going to leave the main reasons why I would use VS Code for competitive programming and any other IDE except VIM for a job on a medium / large project.

Competitive programming: one or two files, little code but complex, you don’t need many management extensions

As for shortcuts, both offer you the tools for super-fast editing (manual, snippets, jump-to function, etc). I don’t think anyone can prove that you can edit faster in this field with either one. Here everyone chooses an editor for pleasure rather than for any compelling reason.
Personally I would stick with VS Code in this field, for two reasons: with a single IDE I can work and program in my spare time, vs code really is very reliable (for now).

Programming in medium / large projects: a lot of code, a lot of files, boilerplate, management extensions (todoTree, prettier, thunder client, etc. I have +20 on my actual job)
Tried to adapt VIM to my VS Code Setup, but it’s frankly hell. It was here that I decided to stop using NVIM, despite having a fairly advanced configuration, and my goal was to improve the fluency with which I was already working in VS Code thanks to extensions, shortcuts, VS Code integrations, etc. However I have not found alternatives for many of these things in NVIM.

In VS Code when there is no extension or answer in stackOverflow that meets your need, you can easily make one or make an extension, but I feel that with NVIM it is different.

Reply

Reply

It feels like the author never used neither vim nor emacs, but read about it and formed some biased / anecdotal opinion about it.
I’ve been using Vim exclusively for less than a year, after trying different IDEs for over a decade.

Like the other comments here, both Vim and Emacs excel in providing an efficient, frictionless editing model that reduces the distance between an idea (the thing you want to do) and its implementation (typing it in).

It feels to me that Vim is on the rise as I see more and more people adopt it or its forks (i.e neovim, in my case) and with the emerging support for LSPs – the actual IDE shell (UI/GUI) becomes less significant as you can pretty much get the same benefits everywhere.

Reply

Reply

Reply

I still use Emacs. It’s going on 40 years now. I’ve also used modern IDE’s. Each has its place.

I don’t use Emacs because of its excellence. It would be hard to find a software system less capable and poorer in design and less imaginative than Emacs. It doesn’t do anything well, but it does a wide variety of things well enough to be more or less usable. Under the hood, it has a very poor design, which helps to explain why it’s so limited in capability compared to powerful modern software systems. From what I’ve heard, the original developers of Emacs were not really programmers and were pretty incompetent. That certainly fits my experience. It’s pretty much amateur hour.

The Emacs ecosystem is built on an amateur attempt at a Lisp implementation called Emacs Lisp, or ELisp. If you like Lisp, great, so do I. But calling ELisp a kind of Lisp, is a bit charitable. The biggest mistake the Emacs developers made was not to bring in knowledgeable people, who are well versed in language design and implementation. They also need basic programming talent. Almost everyone who writes ELisp seems to be a kind of hobbyist who’s not very good at programming, churning out kooky stuff written in spaghetti code. At least, that’s my impression. It might be a little unfair, because they are working in ELisp, for a very poorly designed and limited text editor, with a back woods ecosystem that’s hardly moved past the software concepts of the 1960’s.

Another problem that plagues Emacs is a nearly total lack of imagination. This has been its big problem from the very start. Over the years, Emacs attempted to support coding in many, many languages. But even in the best case, it was very mediocre. And all the implementations were different, with many basically unusably bad. When VS Code introduced the Language Server Protocol, Emacs copied it. Emacs now has a haphazard, weak, confused, bumbling implementation of LSP. The question is, why did Emacs have to wait 50 years before getting the fairly obvious idea of LSP from Microsoft? I don’t know. But that’s how it is with everything in Emacs. They have some bumbling, awkward, unimaginative implementation that only gets more convoluted over the years, until some competent entity outside the Emacs community gives them a better idea. And 90% of the time, they ignore what the rest of the wold is doing, to their own detriment.

So why do I still use this technological piece of junk? The reason Emacs survives, and I still use it, is not that it’s good software, or that it stands up to modern software in power or elegance. It’s that it’s almost the only game in town for what it does, which is not to be an IDE. It’s just a very limited, primitive text editor that focuses on letting you do your work without having to lift your hands off the keys. I know it so well, that I feel like a squirrel jumping from branch to branch when I use Emacs. It’s not that Emacs is any good; it’s not. It’s absolute amateur hour, unimaginative trash. But what else should I use?

Reply

Reply

Reply

Reply

Reply

I use VS Code and PyCharm in a ‘professional’ capacity, which means there are a primary set of useful capabilities I employ all the time in the course of work. Because I’m pretty efficient in these editors, I wanted to know whether learning Vim was worth it, especially as I read that some VS Code users switch to Vim and ‘never looked back’.

I used Vim several times trying to learn it realising how much of an investment in time and effort it takes.

So I watched YT videos of Vim users praising what they thought of as useful features. After watching a slew of them, I still can’t seem to find any particular thing that clinches it for me. I watched text-editing operations that were deemed ‘complex’ in Vim, but weren’t particular hard to do in VS Code, and in fact, quite simple and fast to do for me. That said, proficiency of a system contributes more to speed than the design of the system itself, usually.

Re this comment: “frictionless editing model that reduces the distance between an idea (the thing you want to do) and its implementation (typing it in)”…

I would argue that Notepad.exe/gedit has much less friction than most applications because you don’t need to learn a very abbreviated (eccentric) language to use the application. However, it is true that once you learn the language it becomes second nature, and only then it is promoted to being “frictionless”. But it is by no means intrinsically “frictionless”.

In fact, Vim is full of friction to the skeptical newcomer, which is why it is important to know what clear advantages the newcomer can expect, especially if already coming from a ‘modern’ editors like VS Code.

(Written in Notepad2-mod) 😉

Reply

Reply

I find this article so out of touch with reality that it hurts to read, though I understand, I think, the sentiment that compelled the authors to write it.

The problems I see can be summarized as a mischaracterization of the things they are talking about. I can tell this by the use of ad-hominem fallacies when referring to the use base of pre-modern ide editors as some kind of dinosaurs fro ex. But what makes it more evident is the many contradictions which inevitably arise from an apparent abysmal misunderstanding of what vim and emacs actually are.

So I guess the writers of this blog genuinely have the impression that vim/emacs are text editors that lie somewhere in a linear evolution chain of text processors, something like:
pure ascii writers -> vi -> vim -> emacs -> ms visual studio -> eclipse -> Intellij/VSCode

this characterization explains quite well all the remarks from this article. And I reckon, if it were to be true, most of the arguments will fit together cohesively and I’ll tend to agree with the overall premise.

The problem is that, much like real life evolution, changes don’t happen within a linear chain but rather within an interconnected tree. I would even argue that in this case, editors/IDEs/etc, is is even more like a cyclic directional graph. I wish the authors were ware that vim/emacs are also “magic”. They are not old, they are current. And they can do pretty much what any IDE can do, and sometimes even more. Yes, you heard it right. All that “magic” from “modern” IDEs can be achieved in vim for example. I challenge the authors to check youtube channels like the Primagean, TJ Devries or chris@machine. I personally use vim from all my software engineering projects and I find myself very happy and productive every day. And I also sometimes use VSCode (with vim bindings) when I need to open a new project which was already created in VSCode.

But here is the gist of the issue: There are IDEs and there are PDEs (TJ Devries coined the term PDE). PDEs are Personal Development Environments. IT is like and IDE, but you make it yourself. Should you always use a PDE? Not really. But the reality of the software industry is that there are those who wont bother spending time setting up their environments, so they use an IDE. Good. But there are many, many of us, who actually enjoy setting up our environments. We enjoy it and it brings us happiness. For those not like us, we get it of course. But we are real, and we are a lot many. So we instead prefer a tool which allows us to setup our own PDE. Good.

In the end, as you can see, vim/emacs are not a step below the IDEs evolution ladder, but rather a different paradigm which has evolved alongside modern IDEs and whose main purpose is enabling a “Personalized Customization” experience.

If you are after a hassle free development setup where you DON’T care of how things are wired behind the scenes and just want to jump into coding, IDEs are the perfect choice and good for you. If you like tinkering and like to understand what’s cooking inside your lsp, parsers, syntax highlighting, etc, well then we have vim/emacs as the perfect tool that will enable you to do just that. Good for you too!

Both will provide, I can assure you, the same amount of magic for your actual programing experience.

Reply

Just stumbled across this post, I know it is a couple of years old now, but wow what a load of nonsense!!!

This entire blog sounds like a rant from a disgruntled worker who cannot understand why people like different things to them. VIm and Emacs are not going anywhere, not because of some old-hat developers refusing to accept change, but because many people want to get the job done and do not want a slow, bloated, mouse-driven clunky IDE.

I’m sorry that you get annoyed because somebody else is proficient in something you aren’t, and I apologise that others see value where you do not. What was the purpose of this rant? Did you hope to get a load of people validating your choices?

Reply

No, and no. The people writing this article seem to not know what vim is about. Once you learn how to navigate and edit text with vim, it is superior to any mouse/keybaord workflow. That’s just a fact, not debatable. So using vim modes in modern editors/IDEs is not “being unable to let go of the past” but actually choosing the most efficient option.

I started out using IDEs and VS Code and have migrated to Neovim for pure text editing. I don’t try to turn neovim into a fully fledged IDE, but I have added LSP support and other bells and whistles. This is to say I’m not attached to vim because it ‘s what I started with, or all that I know. I actually had to learn it after being used to these magic IDEs, because I saw it had the potential to improve my speed and comfort while editing code.

Reply

You don’t have a consistent thesis — you’re wishy washy and seem to half argue that VI/Emacs are “antiquated” while simultaneously saying “use it if it gets the job done” and the young-ins will prefer more modern tools.

You know what though? None of this matters. The choice of what editor/IDE to use is akin the choice of an artist of what paintbrush to use.

Vim and Emacs are both actively developed programs, they are not antiquated. Users with serious emacs configurations have features you would dream about in vscode.

BTW, they’re stable. Often you can’t say that for the newer tools.

Reply

so many angry nerds here priding themselves on not using a mouse….

hilarious.

Reply

Nice trolling, you have a lot of angry responses! To be fair your article is ludicrous…

Vim is unsurpassed in text editing speed, Emacs has Org Mode, which alone warrants it’s use.

Also they’re both still around (unlike Atom!) and whilst MS has done a stunning job with trying to make an electron app performance with Vs Code, it’s still a bloated Electron app.

As Devs we do use IDE’s such as Intellij for core development -for work – check your stack overflow Developer surveys for the real picture instead of making up straw-man arguments about stubbornness and resistance to a change in routine – attitudes like that get you left behind in the marketplace and cost you money in the long run! I ‘m 36 and use Intellij, Vim and Emacs nearly every day for work.

Stick to editing guys!

Reply