Modern IDEs are magic. Why are so many coders still using Vim and Emacs?
Developers are a finicky bunch. Like a dog refusing to walk on wet grass, there always seemed to be a bit of resistance to changing up a routine. We love what we grew up with, be it Star Trek jokes, Vim, or Emacs.
The origins of this war harken back to Usenet groups in the 1980s, a time when Vi and Emacs were the primary tools used for coding. Emacs, as we well know, is a “maze of twisty little passages, all different,” (an old programmer’s joke that came from the game Colossal Cave Adventure) while Vim (and Vi before it) offers an arrow-controlled universe of keyboard shortcuts. Both are used in coding, editing, and administering systems. And, though we hate to say it, both have reached a point where neither seems to really want to fade off into the sunset.
The endless war between Vim and Emacs users has continued ad nauseam over the years. It’s less a war at this point than a grumbling shuffle of ingrained habit and stubborn resistance to change. Vim and Emacs users, once at each other’s throats, seem to have implemented each other’s keybindings (a thing they actually do) to take on a common enemy — any modern IDE.
Vim: The high availability IDE
The consensus among many Vim/Emacs users creates a picture many tech users from a certain generation would be familiar with. As my father would attest, using his Microsoft Zune long after its support ran out, if it ain’t broke… While there are many IDEs on the market, there’s no reason to use one if you don’t have to use one. It’s the same reason I am still using Notepad to compose and not some fancy text editor or CMS tool. It just works.
“The reason I avoided IDEs to begin with was that back when I was getting into Vim, like a decade ago, it was an extra license to look into,” says Vim user John Carter (not of Mars). “Since then it’s become a question of ‘code speed.’ If I start with a new IDE or even switch to something like Emacs, I’ll slow down. On an emotional and professional level, I can’t really afford that. It takes energy to pivot to a new editor. I don’t have that energy. I got the job, a family, and side projects. It seems silly but that kind of pivot takes energy.”
Vim is always available. Any Linux machine has it. Vim has a small footprint, low latency, fast startup, allows for more screen space, customizable and most importantly, once the muscle-memory has been ingrained, it’s nearly impossible to switch to something else.
Continues Carter: “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.”
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. While a coder could sit down at any terminal and begin working in Vim, that isn’t true for any IDE. Further, IDEs are often too much tool for the job. Beginning programmers are much better served by simple text editors vs. massive programming behemoths.
As coders’ careers evolve less through their expertise than who is signing their paychecks, there is always a constant code editor available to them regardless of which IDE the company prefers. It could be seen as an act of willful defiance or just personal preference, but text editors are always there.
“Primarily it’s about ubiquity,” says BSD runner Tim Chase. “I can sit at any Unix-like terminal (Linux, BSD, Solaris, whatever), type ‘vi’ (or ‘ed’) and have a powerful editor that works even if my terminal isn’t configured quite right (e.g. sending certain keys or key combos) and without needing to install anything.”
Familiar and comfortable
It’s this type of comfort that has kept whatever perceived war between those still using Vim or Emacs and the prospect of using IDEs going for as long as it has. It’s mental mom’s spaghetti (or insert your comfort food here). Vim and Emacs are always there for you, cozy, calm and willing. While an IDE is some weird new food with all kinds of exotic ingredients that requires tenacious and irrational picking with the fork to get it just the way you want it. The disconnect is apparent and, at this point, understandable.
There is some shiver of recognition among developers though that perhaps switching to a full IDE is not as unbearable as it sounds. There is a resignation in finally realizing that in order to do the job, you use the tools available to do the job, no matter what those tools may be.
“I say, whatever helps you get your job done, use that,” says not that Tom Hanks. “Sometimes the more modern IDEs can get in the way, other times they are indispensable. Visual Studio, for example, has massive performance issues when there are too many files associated with a project file. The entire application becomes very sluggish. A few years ago when I used PyCharm for Python development, it would sometimes become ‘confused’ and give bad feedback on its syntax analysis. Basically, it was making you think you had made a mistake when in fact everything was ‘fine.’”
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.
Whatever war might be raging behind the screens of coders between Vim, Emacs, and IDEs really doesn’t matter. Vim and Emacs aren’t going anywhere anytime soon, no matter their antiquated status in modern development environments. 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. The best advice to anyone struggling with choosing a preferred program is to just use the tools available to get the job done. Or, as the popular 20th century poets TLC so deftly declared, “Don’t go chasing waterfalls, please stick to the Vims and Emacs that you’re used to.”Tags: emacs, ide, vim
There’s not really a war with Emacs / Vim anymore because they both offer the same advantages over modern more mouse driven IDEs. I think the core reason people don’t abandon Emacs or Vim is that today with plugins they can do 90% of what a modern IDE like intellij / VS Code can do but without having to have one hand off your keyboard and lose typing efficiency. I concede that the systems are outdated and less efficient by far to setup and somewhat conveluted to use in cases, but if the hours are put in up front they can level out. I use intellij, VS Code, Emacs, occasionally Vim, and a few others from time to time. Emacs is still the most efficient for me because of my own customizations and the lack of reliance on a mouse. I wish intellij had better thought out text navigation and wrangling (yes I know about Vim/Emacs plugins, but they aren’t complete and only offer the basic navigation).
Most Linux systems have vi, not vim.
And yes, there’s a difference.
You can install `vim` easily, so … who cares?
You can install easily anything as long as the administrator lets you do so, if you log to a server in AWS or any other provider under you control you can also install whatever you want, but why install vim when you can install emacs. In fact, you don’t even need to install emacs remotely to use it remotely because it has a mode that lets you sync the remote folder through ssh or ftp or other protocols, edit locally and then save it remotely.
sometime even admin don’t allow there still a way to get your favor tools present 🙂
Why install vim when you can install Emacs? To save people from RSI. Chording sucks. Modal editing is better.
I often work on systems where I can’t install new tools — embedded devices for example, and they usually already have VI.
No, they don’t. They *call* it vi, but it’s actually vim (or elvis, in Slackware’s case, a vi clone that predates vim). Have you tried actually running this alleged vi without arguments, or running `vi –version`? You’ll see it’s vim. The only open source system that ships *real* vi, inherited through the ages in its original, primordial form, is illumos. Why is that? Because illumos is a derivative of Solaris, which is itself a derivative of SunOS. SunOS is itself derived from Unix itself–not “Unix” the concept, but Unix the actual operating system and code.
Lots of folks ignorant of history in this article / comments.
True. If I am not mistaken, it is usually a symlink to the same binary. In linux, the original vi died a long time ago replaced by vim
One of my first tasks when handling a new solaris box then was to install vim. 😉
Nope. Most Linux has vim, aliased to vi.
most of the vi is just a symlink to vim
I think the writer of this blog is completely unaware of the projects of real world. Emacs and vim are still very useful, and almost irreplaceable in many projects. The company I was working last, the project code was around 8 GB in size, with so many branches. It is almost impossible to download that much code with many working branches frequently. People from 3 locations around the world work on the project.
vim/emacs is still relevant because,
1. Bringing large code base to laptop is time consuming.
2. Running modern IDEs with huge resource utilisation, on a shared system is not possible due to resource constraints.
3. Even the modern IDEs doesn’t resolve Makefile and Macro related dependencies in C/C++ code bases.
However for small scripting projects, and web applications, IDEs will work fine, but real world is too complex.
Is the time you spend typing really that significant?
I definitly spend several times more time thinking about the code I write then actually typing.
Let’s say using one of the old editors lets me type 30% more code in the same time.
My total efficiency would not increase all that much…
When I grew up I liked xCode, but later I realise VS Code offers so much more.
I tried vim and Emacs a few years ago but getting it to level of VS Code take A LOT of Setup (VS Code can also save your settings and you can instantly have them on a new pc).
There is another aspect to this: education
Of the 4 juniors that joined the company I work at recently only 1 ever compiled a program using commands. The other 3 had never seen this before. They all studied part-IT Curricula like Business Informatics and have basically no idea how networks or computer work.
This makes me pretty sad… they can write code but lack so much understanding what they do and why – it makes my heart ache. All they learned to do is using the latest/currently most hyped tools.
I think learning at first the most hyped tools (because companies need people who can use them) is the wrong way. Start at the bottom: a Texteditor with only line numbers. Learn that the compiler tells you useful things! Every step up in editor features will make you love coding even more.
I’d say its not about “time spent” typing but about “distraction by typing”.
Anything that gets in the way of the thought process can be an issue. What gets in the way in what manner is likely rather subjective though. I find e.g. that I have an easier time writing Python scripts in Emacs in VS Code, but in return Emacs’ interface pushed me towards oversized single files due to limited “intellisense”-like features for Python.
I really should learn projectile…
LSP (jedi) with company and elpy works beautifully for me. Projectile, however, remains a mystery to me. 😉
An LSP (I use Eglot to set them up) and Elpy at the same time … that makes no sense. How would that even work?
>over modern more mouse driven IDEs
> without having to have one hand off your keyboard and lose typing efficiency.
> and the lack of reliance on a mouse.
These hilariously “missing the point” memes needs to die a horrible death in a very eternal hot fire.
They make you look like a complete hispter fool.
The only reason… yes THE ONLY reason you die hard “LOLILLUSEAMOUSEWHENIMDEAD” types use vim over the others is memory usage.
The most disgusting thing I’ve experienced about the die hard vim users is their zealotry and absolute boneheadedness in being unwilling to help some one find solutions to replicating the windows vscode mouse using experience in neovim.
– got told i cant drag tabs, turns out you can
– got told you cant have vscode keyboard shortcuts in neovim. turns out you can.
If you’re happy with your anochrisms, thats fine. but if all your going to do is keep spouting how your lord and saviour the antimouse is here to save us all… please save us all the trouble and go join an opus dei community instead.
The only reasons we use neovim or emacs is because they’re faster than the others editors.
no one cares about your keyboard purtism fantasies.
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.
I complete agree: a very uninteresting, badly informed, extremely biased, picking-a-fight kind of article.
For those readers who want something better, consider this.
I have used many of IDEs over my forty-year (so far) career. I prefer (Neo)Vim. The author seems completely oblivious to the fact that most of us pick text-based editors over IDEs with very specific and conscious INTENT. We are making an architectural design decision, a cost/benefit judgment, a technical evaluation and selection.
IDEs have a LOT of downsides.
For example, Visual Studio was infamous for crashing due to memory leaks and performance problems. It is quite difficult to get some code written when your IDE crashes a lot. Many modern IDEs are immensely complex, and overwhelmingly BUSY, and SLOW.
Perhaps the simplest and truest explanation for avoiding the use of IDEs is that they are GUI (gooey, as in sticky and yucky). 🙂 Using a GUI is slower. Using a mouse is slower. Both are error-prone. So advanced users tend to not use GUIs. They likewise tend to prefer *nix over Windows, and they tend to prefer a shell over endless clicking to configure their machine. They want to focus on function over form, substance over superficial appearance.
It seems that the author has no idea that every good IDE feature is available for nearly every text-based editor (particular Vim and Emacs). Auto-completion is available, works better, is easier to configure, and performs better–in a text-based editor (IMHO).
I read between the lines that the article’s author is NOT an advanced user, and so they have NO idea what true productivity is available when using powerful tools like Vim or Emacs (or the shell).
An IDE tends to lead to laziness, or perhaps it is a sign of pre-existing laziness. Do you know what the IDE is doing behind the scenes when you click that button or select that menu item? A good technician should know their tools, and should communicate them to other team members and to those who will follow. An IDE leaves little trace of how you built your code, how you packaged it, or how you deployed it. An IDE cannot be incorporated into a Continuous Delivery pipeline.
An IDE is almost impossible to configure consistently across all the members of a team sharing a code base, and it SHOULD NOT HAVE TO BE. Each person should be free to use whatever editing tools they wish, as long as an acceptable result gets committed to the source code repository.
This article reads like it was written by a petulant child. Go do your homework, little boys. Leave the real work to us adults, please.
Wow so many replies! I just have to add two bits of wisdom. One is to quote from The Pragmatic Programmer by Dave Thomas and Andy Hunt. The other is to confess that I’ve been doing it wrong.
The Pragmatic Programmer explains that, like any craftsman, a programmer needs “sharp tools” that feel like an extension of their own hand. You want to pick a text editor that is powerful and that you’ll be able to use for most everything, and take time building proficiency with it.
I haven’t really followed that advice, and that has hurt me. I had used any number of editors for many years until the early 90’s, when I really had to choose to get good at either emacs or vi. I picked emacs. That wasn’t a bad choice, and it has served me well. But other, newer editors are just *so nice!* So for a few years recently I mostly used Atom (with an emacs mode) and for a couple reasons I switched to VS Code several months ago. I do love many of the IDE-like features of these two, like automatically running unit tests on save, and highlighting lines of code that aren’t covered yet. Not to mention all the good linter feedback. But my rate of typing mistakes has gone up dramatically, and my hands hardly know what to do anymore. My editor is no longer a sharp tool or an extension of my own hands. I feel awkward, and I really miss being able to just think the code and have it appear. I sometimes go back to emacs, but I’ve lost proficiency there too. Yes I’ve been using emacs-ish keybindings all along, but those are a far, far cry from the real emacs. It’s not even close to the same experience.
So if it’s possible, I recommend picking one stable editor that works everywhere and for all languages, and meets your essential needs. It’s possible that vi key-bindings are more complete than most emacs ones, and if so then maybe that’s the best way to go. Get good enough that you rarely need to reach for the mouse, or use any of those keys like home/end that live in different places on different laptop keyboards. And don’t be too fickle. Live with your choice.
Honestly a better advise is that you select at least 3 tools:
A good terminal text editor; (Vim or similar is almost mandatory)
A good hybrid GUI editor,;
And a good IDE;
There is nothing like a panacea tool. I see a lot of people talking about Vim as the only needed tool but clearly this is not universal among developers needs, many times you will just need deeper deployment, analysis, debugging, etc. This apply for OSes too, nowadays not all developers can afford only focusing their knowledge on a single platform or technology.
I completely agree with you. While I am still learning and have nowhere near the experience you do, I recently tried out a minimal Arch Linux setup with a basic window manager and enjoyed myself immensely. Currently still use Windows as my primary OS cause familiarity, but after trying out vim in Linux, there was no going back lol.
I recently started learning C and trying out neovim as my primary editor. With plugins such as Telescope, CMP and Lspconfig providing search, syntax highlighting, autocompletion and much more, my neovim setup is basically an IDE, but everything is ultra-fast and it does not require the mouse, all while giving me full control. Win win win.
It’s disappointing to see that level of arrogance from, presumably, a software engineer who, it seems, has little experience of using modern IDEs. Sadly it seems quite prevalent these days.
“Advanced users” use the tools they are comfortable and efficient with, irrespective of whether they are GUI based or not. I find emacs indispensable for some editing tasks, some comparisons and merges, and I regularly write and use elisp macros when I want to do repetitive or analytical tasks on files (sources, logs, etc).
However I also use Eclipse as my primary development environment, on both Linux and Windows. Consistent configuration is irrelevant from a usage perspective, as long as the projects are configured properly and the code formatter is set up to follow the local style (easily done; you export an XML file as the ‘standard’ and everyone else imports it.
In addition, we use Eclipse from Jenkins to do our builds, using the headless feature, and the complete build output (including ALL the compiler/linker commands it used to get to the endpoint are there in the console log.
IDEs have many advantages over vim/emacs in certain aspects, especially where vendors have put effort into plug-ins that support their products, e.g. those in MCUXPresso, STM32CubeIDE, and the other 3rd party stuff from Parasoft and the like that reduce the manual burden of creating and running unit tests. However they do have a long way to go to match the flexibility and power of emacs, so any argument that says “IDEs are bad, use X instead”, or “X is bad, use an IDE instead” is, IMO, a sign of ignorance.
Agreed! These are some bad arguments! jeez
I only recently switched to vim, like 3 years ago, after using several IDEs for 15 years. I was always trying to customize these IDEs but always felt they were lacking in many ways, in those 15 years those IDEs sometimes changed a lot, making exporting/importing settings not very useful always. Need to relearn a bunch of things, some things sometimes just don’t work anymore or become way less convenient with no way to change that behavior.
I was already using vim ‘keybinding’ plugin’s in all my IDEs (I now know they don’t even give you the top of the iceberg, and they usually have differing behavior that is not as good (note: there is a neovim plugin for vscode that uses the real neovim as the backend and it can use a lot of existing vim plugins, this is the only vim plugin I know of in another editor worth the name). I had been wanting to really use vim for some time, and at some point a new colleague came in who was using vim full time, and I felt confident to make the switch.
Very quickly I came to realize that I will never, ever go back to using IDE’s. I finally felt at home, yes in the beginning it is hard, which forces you to dig in and read about it, you need to learn some things to do basic stuff, but those things later enable you to do way more advanced stuff, there is no ceiling to customizing it and improving your workflow. Vim, in good unix style, gives you all the tools to do any change/customization, right on the surface, no hand-holding, just as efficient as possible, and if there is some tiny detail you don’t like, you know you can change it any way you’d like.
Working in vim feels like playing an editing game all day, I can have fun editing some hard to edit text by figuring out the perfect macro or substitution/global command that does what I want with minimal effort.
It provides many advanced ways to automate some things that you usually need only once, for which you’d otherwise would need to write some script for and don’t do, because you only need it the one time for those 30 or so lines of text.
I’ve written several small vim plug-ins , it is so very straighforward to do because you have to know a lot of these things to just move around the code anyway, and super easy to distribute: just put it on github, and you’re done. Many vim plug-in managers just take part of a github link and install it for you and keep it updated, you know the local git repo of any plugin you have, so again, is there some behavior you don’t like, the plugin code is right there for you to edit (maybe make a fork and pull-request). I have written small plugins e.g. that take advantage of how we organize our files to quickly jump between related files in other subtrees, generate boilerplate code when I create a new file, create code snippets that are context aware, custom highlighting/indentation for a custom DSL and custom text format file we use, …
These things are usually possible in some IDE’s but vim invites you to do these things, it is meant to be customized and honed to your liking. And you know that once you make and learn these things, they will serve you for the rest of your career on any programming language/OS/platform that might come out in the future.
And many other reasons, but not the ones in this article!
Yes, atom/vscode and probably some others are in the same vain as vim in some ways, but not as extensive (macros/global commands/DSL for scripting editing tasks? none of that, or not as easy), also the vanilla modal editing in vim is just extremely good already, and they don’t give you that out of the box, even with the default vim plugins it only adds just a tiny bit of it (thus with the exception of the vscode neovim plugin)
Then I read something like
“This has led users to literally turn Atom into Vim, unable to let go of the past, unwilling to fully embrace the future of code editing.”
No, just no, that shows you have absolutely no idea what you are talking about, smh. What future of coding editing? It is about adding missing! features that greatly improve the editing experience, do more edit with less typing.
Vim/nvim are in active development, many great new plug-ins have come out in recent years, it is fully part of that future, partly driving it.
I think atom/vscode are great, but vim is for me the objectively better choice.
To me the best thing about vscode is that it led to the development of the open standard “Language Server Protocol” for which many clients exist for many editors/IDEs and has greatly improved the ease of having semantic code completion/goto/fixit/.. for many languages, also in vim, before it was a lot more effort to get these features. (on a sidenote: Microsoft really changed for the better since Nadella)
facts, I agree with you, OPs are giving terrible arguments that come from ignorance and missunderstanding the tools at hand falling pray of the time fallacy. They have no idea how superior vim and emacs are to IDEs even to things like atom and vscode.
John Biggs and Ryan Donovan you are pathetic, you make a whole article on why people still use vim or emacs and you don’t make your research, lol.
The main point is that these IDEs are made by the same kind of people that John Biggs and Ryan Donovan are, people who believe in certain fallacies “new is always better” and who think having a tree in the side and opening a terminal in the same window compensate for the actual fact of text editing that is at best equal to notepad.
I used vim for 14 years, then started using Emacs and I have been using both for another 10 years, sometimes I use Intellij IDEs but still my daily driver is Spacemacs, macvim is my side editor.
The best thing is to be in complete control of your tools. Vim still offers that vision of “this is what editing is supposed to be” but lets you change everything easily. Emacs from the get go, lets you do whatever you want because is more like a shell than an editor, a shell with a couple of steps further in evolution to a bash or zsh or fish, because it isn’t using the teletype interface anymore.
Atom, VSCode, Sublime, mate, etc are all imitating intellilj and visual studio and these two are imitating Visual Age line of IDEs from IBM who was an imitation of smalltalk in the 80s. But still none of them are as good as Smalltalk, and Smalltalk still has the problem that it’s text editor sucks, Vim and emacs offer better editing experience.
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.
About 18 years ago as a novice programmer I became a Visual Studio addicted guy (all .net books were written based on availability of VS). many years later, when I had to write my thesis in C/VHDL I switched to Sublime. It was amazing for me that the burden of handling so many unnecessary feature faded away in a simple capable text editor. Sublime had syntax highlighting for so many languages (even HSPICE) and it let me focus on my code much better than Visual Studio.
Nowadays I sometimes switch to VScode for writing C programs but switch back to sublime immediately since VScode makes me sick with its messy windows and slow environment.
And Vim seems very promising for me and I finished the starting vimtutor, I thing it will be my next coding environment for C and C++ and maybe Python all because VIM is distraction free.
Modern IDE’s by default present numerous visual distractions, and try to improve your productivity by guessing what you’re about to do next. I’ve been coding for a long time, and I find these suggestions annoying since well written code doesn’t have a lot of predictable boilerplate content anyway.
s/by guessing/by incorrectly guessing/
there, fixed it for ya.
You can turn this off, it takes 2 seconds.
Also imagine thinking “good code” doesn’t include any boilerplate.
Yeah, turn it off, now what? Your IDE is now just a bad text editor. So what’s the point again?
Also, “use an ide loser”, why get emotional over someone’s choice in software?
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…
Who has once mentioned cultural roots? And we’re supposed to just get your obscure climbing reference – which in itself is dubious. When I used to fly a hang glider, an important rule was: “only do one new thing at once”. I would presume this to be equally true of climbing, which is probably even more perilous. I’d say it’s perfectly OK to stick with ATC’s (whatever they are) if you are comfortable and safe with them. All in all, a poor analogy, and a poor – and gratuitously rude – post.
That’s great, i use many IDEs at any given day when i want to compile code, but i still need to use vim or emac or nano when i am on the shell, say ssh into a server or docker instance and want to write some scripts or change configs etc.
Um, what about “runs in terminal mode locally and over SSH”?
I love vscode and jetbrains but they don’t do that. And emacs is an IDE.
“Um, what about ‘runs in terminal mode locally and over SSH’?”
VS Code has a snazzy SSH plugin that allows one to edit remote files, without installing anything on the remote. IIRC, it only works with Ubuntu, Debian, RHEL/CentOS machines, presently. And VS Code has integrated terminal one can split into multiple panes.
If one *really* wants to, one can live in VSCode pretty well.
The reason it “only works with Ubuntu, Debian, RHEL/CentOS machines, presently” is because VSCode does run a binary on the remote machine. Its not magic. It doesn’t “install” anything (if your definition of installing is using a package manager or something like that), but try opening a project from another computer on your local network over SSH; if the remote PC doesn’t have access to the internet VSCode will simply fail to download its remote host binary and fail.
Incredibly, I miss Windows EDIT very much.
Is there an IDE that can run Eliza? Towers of Hanoi? Disassociated Press?
Comes with a copy of the $250 cookie recipe?
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.
there’s no benefit at all in “learning a new IDE”. vim (and emacs) is here to stay, it has proven to survive many versions of many IDEs, who uses Borland, CodeWarrior today? they were “modern IDEs” back in the day.
vscode is nice, but it’s not “more modern” and it will never ever succeed vim. it’s also not trying to. the whole article makes wrong assumptions. bunch of noob coders i guess…
Saying there’s no benefit in learning a new IDE is as short-sighted as saying vim is ‘old’ and refuses to go away. Just use both in the circumstances where they make you the most productive, no?
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.
Spacemacs, the best of both worlds.
Vim and emacs are equally obtuse, but emacs is a full blown lisp machine. It will do absolutely anything you want to unreasonable levels. People learn vim because its always there. People move to other editors because vim isnt easily extensible. But they already learned modal vim so they make the new editor like the old.
Emacs is timeless. No replacement necessary.
Vim is indeed very extensible. Apparently another uninformed opinion. But otherwise agree.
I guess it depends on how you define easily. Having written a plugin for IntelliJ, I did not find it easily extensible at all.
Oh, and I’ll add I’m a huge fan of both Vim and IntelliJ-based IDEs.
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 😀
Just a note, you can have your cake and eat it too. I use Vim inside Visual Studio. 😉
> 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.
I use Git from Vim as `!git …` and deploy through `!./deploy.sh`
I don’t know emacs so cannot say… but for me
Vim: good for editing text formatted like code
Ide: good for editing actual code
Ide + vim plugin: win-win
Stuff like continous data flow analysis, static checking, inspections, quick fixes, unit tests, module cross dependency analysis, navigation (goto implementation/usages/declaration, show class diagram etc.). We use a lot of libraries nowadays so it would be a PITA to code without inline documentation. Vim doesn’t understand code, it’s just a text editor. If I press goto declararion of a library method, IDE will decompile it on the fly, navigate to precise location in the decompiled code and show fotmatted documentation in-code. Can vim or emacs do it?
By the way, I don’t use mouse in IDE, it’s a myth that you need it. You CAN use it, which is good. But it’s just an option. I usually bind some IDE command to vim, like, run specific gradle task or run/debug.
Btw I’ve seen code completion in VIM and Emacs.
It is funny to even compare them in terms of features. Coming from Intellij Idea world, AI driven code suggestions is just a tip of an iceberg… similar with other plugins… I’m not underinformed in that matter.
The author has never taken a deep dive into VIM or EMACS. Both have all of the features of a so-called “Modern IDE”. It just take a little configuring.
Huh? Emacs also has “code completion, Git control, and and even automatic deployment systems”.
“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.
I find myself incredibly irritated by the attitude of the article, which is that vim/emacs are antiquated tools with no future in modern programming, but that some people can’t get give up on these old-fashioned tools. I admit, I love vi, but I’ve tried various IDEs. Some are OK, some are great. None have anything I need to be more productive. Of course I should give up the productivity I get with vi/gvim because some opinionated person thinks that I am “unable to let go of the past, unwilling to fully embrace the future of code editing.” What hubris.
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.
“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.
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.
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,
I’d be curious to know which distros are still shipping vi and not vim.
I love using a good IDE, I use VSCode which is the only worthwhile thing to ever come from Microsoft. However, a few years ago I was with a contracting outfit doing a lot of Linux work. VIM was always there and if you could use it you could program in any Linux shop.
Emacs and VIM are much more than an IDE. I use Emacs to write my website, journal articles, books and manage my projects.
Are the authors being obtuse to raise controversy on purpose, or have they really never themselves used vim and emacs? I switched from vscode to emacs because *emacs* was more feature-complete. Vscode is great but it’s significantly less extensible than emacs by design and when I finally got fed up with the consequences of those limitations and switched to (spac)emacs, I found the latter did everything I liked from the former better.
I came to say the same. And if that’s the strategy, it worked; just look at how many comments there are.
I have used several IDEs for several years professionally when required. I put IDEs in the same category as Microsoft PowerPoint. Cluttered interface, occasionally useful, but never enjoyable. I eventually found a job where I can use only vim.
There are advantages to IDEs, specifically, they have static checking which catches some typos before ever running the code, and it’s extremely easy to follow code references through different files in a project. This is useful for a large, non-modular codebase.
IDE vs vim (or emacs) is sort of like automatic vs manual transmission, or walking on the moving walkway at the airport vs walking off the trail through the woods, or a coloring book vs blank paper. Do you want an experience that is created and managed by a commercial IDE software company, or do you want to create your own experience?
I don’t have a strong opinion about vim vs emacs. I used to use emacs, but also learned vi for ops, then switched to vim because of the smaller minimum size, faster startup, and charmingly idiosyncratic keystroke philosophy. If vim suddenly ceased to exist, I would be happy with emacs. If both ceased to exist, I would be sad. If IDEs ceased to exist, I wouldn’t notice, though I guess that 95% of the badly written code and/or extremely boring code that clutters up github would disappear.
There are many programmers who are extremely specialized web development factory robots, while knowing very little outside of their specialization. Using IDEs tends to increase this specialization. I can’t out code someone like this in their area of specialization. But using vim (or emacs) and Linux/UNIX shell tools tends to broaden one’s perspective on computers and software, so I can usually out-think one of these robots to find a better solution that requires many fewer new lines of code.
Here is an amusing research finding on the topic:
“We show that Vim users were slower than Emacs users, wrote less text in the same amount of time, and produced more typesetting, orthographical, grammatical, and formatting errors. On most measures, expert Vim users performed even worse than novice Emacs users. Vim users, however, more often report enjoying using their respective software.” https://mjambon.github.io/vim-vs-emacs/
I would suggest google searches on “vim syntax highlighting” “emacs syntax highlighting” “vim code completion” “emacs code completion” “vim lint” “emacs lint” “vim git integration” “emacs git integration”
So at some companies I’ve worked at, sys admins wouldn’t install emacs on Unix servers (AIX). So it was vi or nothing. So i learned vi. Now i’m ruined. 🙂
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.
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.
Yes, I also like that Vim is so light on CPU/battery.
“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.
Aye, these are very good points. I don’t use an IDE these days, but when I started programming (Java, using JBuilder) the IDE provided a nice leg-up. At that stage, the important thing was learning how to write a program. Mucking about with environment settings, makefiles, of task runners distracts from that, and can be learned soon after.
On the other hand, I had learned HTML a few years earlier using… just Notepad.
I do think there’s a role for IDEs aimed at education. A great example would be the Arduino IDE. Setting it up involves picking your board from a menu, and there’s a nice dialog for importing libraries too. The whole compile-and-deploy thing is done with one button. The entire IDE is quite minimalist, and doesn’t come close to the complexity of Vim or NetBeans because it doesn’t need to. The Python and Scratch tools bundled with Raspbian are in this area too; the Python tool include a simulator for the Sense Hat add-on board, so schools don’t even need the actual hardware for every pupil.
I just went looking for a “tip of the day” plugin for Vim, and found at least half a dozen of them 🙂
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:
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.
Err… Emacs has code completion, git control, and automatic deployment systems.
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?
I am a 24 year old developer. I’ve been working professionally for about 6 months now. I use vim, any IDE is incomplete to me without either vim emulation or an nvim connection. Modern IDES have the main advantage of being mostly ready to go out of the box whereas vim requires a mountain of config to reach a similar level of functionality. However the main advantage of vim is the speedup in thought-to-code translation time. With marcos, registers, and the modal nature of vim you can format, modify, create code significantly faster than if constrained by mouse movements and precise clicks. Once you get used to vim, not using vim feels lackluster and slow. I encourage all young developers to give vim a shot!
> 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.
I switched from modern IDEs to Vim. Steep learning curve, but so worth it.
referring an IDE rank list of 2017? what day is today?
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.
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.
It’s been 2years now on (neo)Vim. It’s been splendid.
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.
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.
I’m an old unix wizard and now rather out-of-touch with modern unix (aka Linux) – I learned vi long before I used Windows. Yes, I was always frustrated by notepad (and edlin!!) and the fact that no one in the Windows world had even heard of a regular expression. However, it’s really not true now that modern IDEs are ONLY pointy-clicky – they have decent regex support, very good column editing facilities and you can configure them to be basically how you want them to be. I feel no temptation to use vim, but I am much happier using bash now than Windows explorer.
If I were to choose my editor, it would be one compatible with Brief – I have never seen anything better for quickly getting 2,3,4…N separate panes on the same file. The only thing that is currently brief compatible is very expensive.
Oh, please. I was an EMACS wizard in 1989, when that was the only thing available to me. I was the guy who customized EMACS to make programming easy for all my colleagues. I’ve long since dumped it in favour of modern IDEs that _I_ don’t have to customize.
I wish that electronic medical record systems had a vim mode. I tried to get access to the data elements used by Epic and was repeatedly told that was off limits. We have to be button clickers. The frustration (especially when overlaid on sleep deprivation) drives me bonkers. -a physician/scientist also trained in programming, age <40.
OK Boomer! you are being a bit condescending toward the modern IDE’s and today’s developers, you ‘re pontificating from your comfort zone worn out like an old shoe.
Doesn’t have time to learn a new editor that could potentially make his life a lot easier. Seems a bit absurd to me. I love Vim, but it doesn’t compare in any real way to full-fledged IDEs.
I have used vi since my university days in the early 90s, I have a nice set of vimrc & extensions all custom configured that i like to use.
I rarely use it any more, though. Vscode is my text editor, my debugger, my file explorer, my terminal emulator, my ssh client, my build system and error parser, my embedded executable uploader, etc…
Just turn vim into an ide. You can have pretty much everything with plugins.
I’ve learned a lot of IDEs over my career so far but vim is so far the most full-fledged. This article makes the mistaken assumption that you wouldn’t have code-completion and static analysis running in the background with vim. It certainly takes time to get these things configured, but not as much as it did ten years ago; with the introduction of package managers, installing ALE and LanguageClient has become a piece of cake. You just have to know that these things exist in Vim, and ignore the many who have a very limited view of what it can do.
100%. You will never get the free pears unless you take time to plant that pear tree… I agree it’s a false economy not to adapt, especially in the tech industry. Do yourself, and your employers a favour, and always make time to modernise…
World renowned programmers like Donald Knuth or Linus Torvalds tend to use Emacs or Vim.
Mid-range programmers sometimes use Emacs/Vim, sometimes IDEs.
Beginners, teenagers learning to code tend to use IDEs.
I use an IDE. Last year, I didn’t know what a pointer was.
So what? Well, maybe there is a reason for this. Other than “those top programmers really should learn how to be as efficient as newbies”.
I don’t think it’s fair to say any particular skill level or experience level points someone to a class of editor/IDE. World class programmers also use IDEs, and novices also use vim. It really just a matter of building the toolchain you feel most productive in. I use both every day, personally.
Don’t believe assumptions made in this post: I use Emacs because it is the *best* tool for the job. I’ve moved from so called “modern IDEs” to Emacs not because “I used to” Emacs *I didn’t know Emacs at the time* but because it did what I needed it to do. So the “you’re used to” point in the post is wrong. The second point about vim vs. emacs war is also presumptuous (is it April’s Fool already?). No need to paint all vim/emacs users with the same brush. I full time Emacs user but I like vim. Vimium is how I survive a web browser.
If you like a classic IDEs experience, look at Doom Emacs https://github.com/hlissner/doom-emacs or if you are familiar with vim then https://www.spacemacs.org/ Personally, I use vanilla Emacs (it has all IDE features that I use and more).
For me Emacs is the application platform, unified environment: each key press is a programmable customizable command. My favorite applications are magit (the best git UI ever created) and Org-mode (especially Org babel + jupyter-emacs — Jupyter notebooks-like environment) — all my life in a plain text. Naturally, there are lots of programming modes.
As someone who transitioned from VS Code to Vim this article really comes across as very anti Vim. Why is it you feel it’s just the older coders who are stuck using Vim because it’s comfortable? That’s not true for me and I’m sure many others. Moving to Vim for me was a choice, and I feel way more productive for doing so. I started out using Brackets then Atom then VS Code now Neovim which is far from outdated.
The article really reads to me as derogatory to those who choose anything but VS Code and the kin.
Totally agree. I started out with IDEs, and since switching to vim have tried to switch to IDEs and graphical editors like Intellij, sublime text, and visual studio code, I’ve even tried emacs (which it turns out I like better than the IDEs) but I always come back to vim (or now neovim). While most ides now have vim mode plugins, in my experience, they are incomplete, and often buggy, and sometimes they just can’t replicate some of vims features. And then there is performance. IDEs have terrible start up time, are hungry for RAM, and can slow to a crawl with large files.
This also completely ignores that modern vim and neovim, as well as emacs can have many IDE-like features by installing a few plugins.
Was this article intended to be written from an objective perspective? It stinks of bias and everything mentioned as a “feature” of IDEs has been in vim and emacs for years.
Just use whatever works for you. If you’re curious then then try vim/emacs otherwise stick with an IDE. Just know that similar to vim & emacs: Atom, VS Code, Sublime are all text editors that gain IDE powers through plugins
The article is just entirely spouting off their ignorance of Vim and Emacs. They show in practically every sentence they don’t even know what it’s like to use them. They could start by listing some IDE features that V&E don’t have? Anything?… They mention code completion etc., as if that’s an example. Clueless. Do they even realize that VSCode uses LSP to provide its rich code navigation features, and Emacs uses the *exact same LSP servers* to give the same features?
I’ve lost count of how many times both Vim and popular, new, IDE users have proudly shown me features they think are awesome super special modern abilities, only for me to realize they’re excited about something I’ve been doing since the 90s in Emacs. And Emacs has not stood still in any sense, it’s *way* more powerful than it was.
You know, I’ve actually seen a trend of newer devs switching from modern IDEs into VIM.
So it’s not just old timers hanging on. It’s perceived as more efficient and professional.
I’ve never used either of the old breed IDEs for more than a few minutes at a time in Linux but I know they won’t be going anywhere.
Couldn’t agree more. Most Vim users nowadays are actually those transitioning from the “so-called” modern IDE such visual studio and so on. The author seems to miss that significant fact all together but rather describe those users as “stubborn”!
This. I started programming on Linux about two years ago, after a couple painful months of editor-hopping I had settled on Vim because it was faster and more reliable compared to numerous modern IDEs I’d tried out. This article sounds as if Vim is just a bad habit Unix dinosaurs can’t let go, while the truth is that one who looks for a stable code editor that *just works* will eventually discover Vim and most probably stick to it for life.
Will – I’m curious… Why did you decide to ditch VS Code and revert to a more primitive text-based environment? (Genuine question!) As stated below, I have recently gone the other way. I know there is something about raw text editors – like driving a manual car with the top down on a country road – but what was it in particular that turned you away from VS Code in the end?
Suppose you are asked to do a simple calculation. Say, you have to confirm that 355/113 is a good approximation for pi.
Would you refuse to work until you got Excel installed in your machine? Of course not — you could use the calculator that comes with your OS.
Vim is like the calculator that comes pre-installed in your computer and most servers you’ll have to interact with.
Sometimes you just need to edit a file. And Vim excels at that!
The fact your calling it a more “primitive” text editor tells me you have never delved that deep into vim. Vim is actually more powerful IMO then most modern IDEs out there due to its approach to text and actions. Vim has its own language, with verbs, modifiers and nouns and that simple concept translates into incredibly complex actions with very few keystrokes.
The only issue is the learning curve. I have yet to find any other IDE capable of the power of vim. Granted I’m including plugins when I discuss vim, like spf13. But the concepts at the core of vim are powerful and I wish modern IDE followed suite.
I wouldn’t necessarily call VS Code a “modern IDE”. Unfortunately, I think it suffers from being written as an Electron app in the performance department for some things, and I do end up preferring VIM over VS Code as well. However, with PyCharm or Visual Studio (the full Windows app) for me it was a whole different ball game. Although, I do use VIM keybindings in PyCharm.
Transitioned from BBEdit to vim a couple years ago. Living in the terminal is an upgrade in itself, especially with tmux in the mix.
I really enjoy not being tied to any company’s editor. A company, in the end, is always self-serving.
I’m a young developer, but I still use emacs with evil mode, I’ve used visual studio, atom, pycharm and visual studio code, even tried vim emacs extension for visual studio code, but it had a lot of bugs, now after a month or so of having low productivity with doom emacs, I can write, run and edit code a lot faster than before and I don’t regret one bit of learning those keybindings.
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.
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.
“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.
Because we want control over where our files go!!!
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…
Exactly, VIM IS NOT AN IDE. It’s a text editor / text editing framework. You can use it in any IDE. It seems like people aren’t understanding this.
Think about it from this perspective – you cannot use an IDE in an IDE, therefore VIM is not an IDE. It can be an IDE with tons of plugins, but that’s also different.
Hmm then who where all these other IDE’s created for? Business Analysts, Project managers?
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.
And I’m sitting here, using nano…
I hate vim’s (shift + i) for initiating edits to a textfile. However, I really love vim’s feature for pointing directly to specific line number on opening text files.
I use nano for configuration (as well as any small) edits and use vim for debugging.
As for hardcore programming, everybody needs some kind of “intellisense” which are absent on bare text editors.
Yes, when it’s a matter of using an editor just because it’s always installed on all of my servers… it’s nano.
I think OP just doesn’t know that TUI does not mean “old” or “bad.” I currently use VScode as I’m unfamiliar with certain parts of vim but having a text editor within my terminal would be great and I’m currently trying to vim full-time.
Like a friend of mine, you are not alone.
Hate using an editor that requires a mouse. Slows down my input, thinking etc but then I discovered vi in 1982 and used it every day since. I even set visual studio up to use it despite the limitations it then has..
I tried to use pycharm, php storm, vscode, but all of them seems too heavy to me, with vim my feeling is that the editor is really light.
My vim has linting, autocomplete, debugging (way easier to configure comparing with phpstorm), test running, etc, so the reason that I don’t change the editor is because of performance and resources usage.
This is a stupid post and reeks of ignorance.
Have you not read one of the most popular answers in stack overflow – your problem with vim is you don’t grok vi? https://stackoverflow.com/a/1220118
Vim can do anything any modern IDE can do if you want it to but.. why would you? The operating system is the ide. Vim is the editor. Use screen, tmux, or multiple terminal windows for git, test runner, application runner, project/file browser, whatever. Vim can do code completion,
colored highlighting, auto-indent, inline doc, jump-to, search and replace, run a terminal, execute terminal commands and insert results into file, multiple buffers, multiple panels with resizing and rearranging.
All your IDE features were in vim first. You better go look at tpope’s repo and learn something .
How many times do you lift your hand from the keyboard and reach for the mouse in a coding session? If your answer is more than 0 you’re doing it wrong and you need to learn a bit before stating an uninformed opinion
And a big advantage of vim debugging using e.g. VeBugger, is that the exact same keybindings will work with different debuggers. That means transitioning to a new language does not mean a muscle-memory overhaul.
The same goes for autocompletion, finding references etc. – I have often tried to configure new IDE’s to work like the previous one I used, only to find certain keys didn’t work the same way. For instance, it was impossible to use the multi-control-key bindings that Visual Studio offers in GNAT Studio, when transitioning from C# to Ada.
Now, I use vim for both of these languages and the transition is seamless. The fact that mcs is used when I am debugging C# while gdb is used for Ada is nicely abstracted away inside the plugin’s code.
> 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.
Exactly, this article is bogus. VIM IS NOT AN IDE. It’s a text editing framework.
This ^^ right here!
Vims language is one of the most powerful concepts I’ve seen in an editor and none of the modern IDEs have picked this up.
Dude, notepad has 1 undo level.
It should be noted that most people who ended up using with vim have used IDEs before but finally moving to vim. I have personally used many IDEs in the past, and also liked them, no question. It’s just that vim simply works best for me. In regular intervals I check new IDEs and then end up continuing to use vim 🙂 .. Probably that’s also because vim is always where I need it (or installed in seconds). like on a server, in a docker container, on my desktop, on my phone. vim is where the code is, always.
I think there’s more to it than “never touch a running system”. I started out with IDEs; first eclipse then later intellij family of IDEs. I nevertheless switched to Vim bindings at some point because that was faster for certain things. Eventually I moved all my coding to Vim (to be fair: I use IDEs for big projects because of their refactoring support). To me the big selling point of vim is that I get to use my muscle memory for *everything*: writing email, writing markdown, writing config files, pyhton, Cxx, java, go…. Simply everything I do on a computer that isn’t browsing. I even have my zsh configured to use vim bindings. You might say I have vim in the terminal stages (pun intended).
I am much too young to do this because it’s always been like that.
> 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).
Did you know SO runs in Windows? I mean do you expect to learn how to be a power programmer from Windows people? I hate Google for suggesting this garbage article.
All hail magit – it is truly a thing of beauty. These authors obviously have no idea what Emacs and even modern Vim are like to use. It’s amazing they wrote this article without even slightly researching the topic, just making stuff up off the cuff about what they *imagine* Emacs and Vim might be like.
😂😂 +9999999 for Magit.
Agreed Atila. I think the big difference between most IDEs on the one hand, and vim and emacs on the other, is that IDEs typically target only one or two programming languages. That forces developers to learn how to configure and use multiple IDEs in order to be efficient.
I agree about Magit; in Vim there is a port called vimagit, which is also top-notch. Visual Studio and various other IDEs are doing half-assed attempts to match this. It is disappointing to see that Visual Studio thinks that svn names map to git actions, making their version very confusing to use.
Wow, what an acerbic gauntlet thrown to the users of Vim and Emacs – shots fired. I do wonder: are the authors sad that the Vim-vs-Emacs wars are cooling down, and want to stir up a new war?
I started programming no more than 5 years ago. I started to use VSCode and whatever that looks pretty. I was hearing a lot about Vim but never tried it (until I did). It was an eye-opener to the speed I could reach while editing code. Its such a huge inconvenience to go back and forth from the mouse. Vim allowed me to shred my code while keeping my fingers at the home row. Just because it’s old, doesn’t mean it’s outdated. Rather, I think, modern editors should have gone further on the idea of modal editing; just because it’s so damn convenient!
Yes. Yes, they are. 🙂
Sorry vim is not arrow keys but hjkl for single character movement. If hjkl are arrow on your keyboard thank vim
Vim popularized that, but it used HJKL because it was created on a Lear Siegler ADM-3A terminal, which had the arrow keys printed on those keys.
…ugh. I wish there was a 5-minute edit window here for when I post while half-asleep. Vim uses HJKL because it’s “Vi IMproved” and vi was created on the Lear Siegler ADM-3A.
Not really. I don’t want or need all the clutter that surrounds the actual edit pane in most IDEs. Magic they may be, but they’re grotesque overkill for my work, and they take up screen real estate that is better occupied showing me more of the current document.
How many people expected to learn something then realized 5min was wasted from their lives reading this?
Vim won’t ever go away, as you need something to work on all machines including production services.
An similar article could make the exact same kinds of arguments, and be just as woefully misguided:
“Modern operating systems are magic. Why are so many IT professionals using Ubuntu and Fedora?”
“Modern cars are magic. Why do F1 racecar drivers use custom racecars carefully optimized to their driving habits?”
Or, more succinctly:
“Modern tools work great for most people. Why do more advanced users invest time and energy to become more efficient than most people?”
It’s fine to like the interface you like. But for those of us who want and need to be more precise than our mouse can be on screen, vim and emacs are the most widely available options.
Past? Future? Honestly, the people I see using IDEs are mostly working on legacy systems, and people using vim or other text editors are working on vanguard technologies.
There’s no reason why things need to be “integrated” in a single monolithic app. There’s no advantage to doing source control on your editor over doing git on the command line. To a large extent, IDEs are training wheels. They lessen the cognitive load, facilitate adoption of unfamiliar technologies. But, like training wheels, they also limit you.
That’s not to say there aren’t things they are superior at, but the main reason vim and emacs are still in widespread use is that, when is comes to text editing, they are the masters.
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.
Also no mention of ultra edit. That was my go-to for a while in the early 90s on windows systems. Notepad is trash.
all IDEs are really week editors. All of them are “uni-directional”. OK for straightforward coding. I recall about five years back some one in the crew (a really good developer) announced that intelliJ had ‘rectangles’. Something I first encountered in the previous century.
Code is just text. And vi and emacs are all about text. Personally I cannot imaging working in a world without a shell in an emacs buffer.
Code isn’t the only text I edit.
IDEs are also dangerous, adding who knows what to the env. If you can’t build from the command line, do really know what you’re doing? Hint: two letter answer.
I live in emacs, but I’ve used most popular IDEs and pay for IntelliJ. It’s a better debugger than is emacs (currently).
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
Yes, it has been lacking in recent distros. An opinionated vi user was given the keys I suspect. Of course they all have it solidly in their available packages
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”.
I read this with an open mind looking for the ‘magic’ of IDEs. Apart from ‘code completion’ and ‘Git control’, which Emacs does rather well IMO, I don’t think the article mentioned anything. Did I miss something?
For me, once I realized how efficient I could be with using the keyboard only, I couldn’t let go. That is what Vim gave me, a way of thinking. Combining this with powerful IDE’s like Rider or Visual Studio, I became an absolute powerhouse. I’d recommend anyone to try out the Vim-way before judging it too harshly.
Honestly what I want is the Vim-way of editing mixed with the modern way of organizing my editor. There is an interesting project trying to do this called Oni2, and I can’t wait. For now Visual Studio Code with vim mode is a quite pleasurable experience in my opinion.
“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.
I have a unique take as someone that is just starting out in their coding journey. I have tried IDE’s and I dont like them. Vim has caught my attention because I can customize it to be MINE. I dont really care what others find easier. Its what I find easier and more comfortable. Not sure criticizing people for wanting to stick with whats fastest and easiest for them to use makes any sense.
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.
And how exactly Emacs with rtags + cmake-ide is any less functional than something like Visual Studio? Emacs *is* and IDE, in many ways more powerful than the lesser modern toys.
“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.
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.
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
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.
Try buiding a phone app with vim. Don’t getme wrong i love vim but i’m not building a cross platform phone app with vim.
I pretty rarely comment on these, but the reason I got into vim was purely because I live in terminals, headless virtual machines, servers, and containers, which don’t lend themselves to running an IDE. With vim I can have a consistent editing environment between all of those, including my own computer. I do use IDE’s for some tasks, because they can save me time sometimes when sifting through merge conflicts and when collaborating with other programmers who are more familiar with that interface. However, to just say that vim, emacs, nano, etc are outdated points to a somewhat narrow perspective on the issue. For new programmers, vim and the like can certainly be a bit awkward to start with when compared to Atom and other IDEs. But, when put in the scenario where you have to edit files on a machine with no UI, the utility of those “outdated” systems will become much more apparent. That’s not even scratching the surface of what these editors are for, but IMO it’s one of the more obvious ones when scp-ing files is overkill or not an option
Atom is no longer under development – vscode + ms buying GH killed it.
The authors are talking about emacs and vim like they stopped being developed in the 70s. I have yet to not find support for a language or an environment while working with vim. I moved to vim six months ago as visual studio is absolutely dire for Linux cross compile, and now I’m inside shells in server farms all day and happy as Larry. There’s little sign of ides getting any lighter – embedding it in electron for cross platform compatability is pure laziness, and has a resource cost that beggars belief – so I’ll stay here on vim.
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.
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.
All “Modern IDEs ” support VIM mode.
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.
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.
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.
I am a teenager, and I started programming with Notepad, then Sublime Text, then VS Code and now finally I have started using VIM. Earlier, VIM used to scare me, but now that I’ve started to use it, I no longer think slow, bloated, transient editors like VS Code are the future of code editing.
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.
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.
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.
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.
This article seems to imply IDEs have features that emacs and vim don’t have, then lists features emacs and vim have?
Why? Same reason some people will press ‘x’ until all the characters on the line are gone, and then ‘dd’
Uhm, screen latency? You know, it’s a real thing, which some people are less content with than others. Even Vim users break out an IDE from time to time. But all the featuritis does indeed come with an usability price. Not everyone can put up with it all day long, whether they realize it or not.
> 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`…
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 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.
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.
– 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.
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.
Muscle memory works both for you and against you – some people have no idea how irritating it is when programs like Gimp will not open a file when you press ALT F O but fail to take your finger off the ALT key before pressing the O.
I was greatly impressed to learn that in my 70s-era software, Ctrl plus O or o, followed by O or o or ^o, all did the same thing. “Whoever designed this CARES about how dumbos like me use the keyboard,” I thought.
Subsequently, Ctrl plus ANY character key did NOTHING. Forget about follow-ups — the lead-in HAD to be something vendor-specific and outside the typing zone.
> 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.
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).
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.
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.
What a ridiculous article. From the outset, it’s clear this person doesn’t like Vim/Emacs or their users. Big IDEs and Vim/Emacs are simply different text editors. It would’ve been nice to have an intelligent look at both, but here we are.
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?
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.
It’s not really vim or IDE. I use IDE and vim. The Jetbrains products (PyCharm, et. al.) all have the VIM plugin available and it’s 90-something % compatible with the real thing.) I use vim in a terminal for quick and dirty edits, or working through an ssh session. I use PyCharm for more complex tasks or debugging.
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.
I’m living in Emacs Exwm. Exwm is window manager for GNU/Linux only. He is Emacs Window Manager. I’m using all other programs inside my Emacs, etc all other programs are like buffers. I’m sending fake keys to other programs, I got VI everywhere, no need for plugins in other programs, I just send fake keys to them, I made configuration of this.. The power is unlimited, trust me. I can’t tell you how I’m happy with this.
here is link for sending fake keys:
Twenty years ago, I could have spent time learning Borland’s Turbo C IDE or time learning vim. Which one is still useful?
Sure I will switch to an IDE once they stop lagging during autocomplete and consuming like 98% of the RAM of the system.
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.
Text editing is insanely efficient in vim once you have the right plugins in place. For git integration, vim-fugitive is excellent so much so that when I do have to use IDEs I still switch to vim for staging hunks of code and resolving merge conflicts.
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.
I use Vim for the last 5 years, with some plugins, and I love Vim. I have linters, git integration, colors preview in CSS. I have experience with IntelliJ products, Atom, VSCode, but I love that Vim is easy on system resources (also saves the battery), can be found everywhere, effective. I can open archives in Vim (integrated file manager), I can use Vim without GUI (in tty, ssh). And Vim is free, open source.
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.
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.
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.
I find it interesting how SpaceVim has made this attempt to get the best of both worlds. After years of vimming I still find that controls which I don’t use very often are forgotten, and I have to search through my vimrc files to find it.
SpaceVim says; here’s a visual menu that only appears when you activate it (by pressing Space), and then has one key for each choice and an arbitrary number of submenus. That is a huge improvement over the current mouse-navigated ‘File / Edit / Windows’ dropdowns idiom, but still solves the ‘forgot the command I use once a month’ problem.
I only wish I could integrate that one idea from SpaceVim without also taking in all the rest of their config.
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.
You seem to have missed the part where Emacs can be integrated with absolutely anything. If IDEs are magic then Emacs must be the Eldrirch truth.
“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…
‘… 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.’
This resonates with me, although it comes from the other side. The users of JetBrains need a ‘.idea’ directory gitignored, while the users of VisualStudio need the ‘.vs’ directory gitignored. Git pros, of course, put that in their own global gitignore and don’t tell the team which editor they are using, since they shouldn’t ever need to know. It is a shame when, in one way or another, the project structure is affected by the personal choices of development tools. Developer should choose whatever tool they want, and configure the tool to do the job, rather than configure the job to suit the tool.
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.
you sound disgruntled. maybe just try an IDE from this century – you might lighten up a bit!
Ok, how do I use them over a rs232 link?
If you had read my comment you would have seen that I’m not opposed to using GUI’s. It’s just that I notice that people get hooked on them and become unproductive if they can’t use their favorite special pimped setup. And I don’t want to fall into that trap, because need I work in environments where I can’t use bling:ed up IDE’s.
Also; it’s not that I haven’t used modern IDE’s. Funnily enough, I have needed to set up already-working build systems in IDE’s for GUI-bound people. Which kind of proves my point. :/
.. and then there’s the time when a colleague spent a day trying to figure out how to get cmake to generate a Visual Studio project which looked they way he wanted it. It built a project that worked, but it didn’t look like he was used to .. so he spent time needlessly pimping up an already-working Visual Studio project. Again, proving my point.
If you can use an IDE without wasting time on the IDE itself — then good for you. But my experience is that people waste too much time on them. And when a plugin stops working, they can’t get any real work done and can spend a considerable amount of time learning the inner workings of their IDE, just to get their useless bling back.
You and your friends have never tried Docker? https://medium.com/@SaravSun/running-gui-applications-inside-docker-containers-83d65c0db110
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.
This +1000000. Editors like Vim and Emacs don’t exist in isolation. If you’re working in a *nix environment, you’re working against its basic assumptions on some level if you want to use a giant monolothic program that does everything under the sun at once. The traditional tools available there (editors included) are fast, lean, stable, and have decades of work done to refine and perfect them, and they can easily be composed together to do anything you would want out of an IDE and more. I use VS if I’m developing Windows desktop software in Windows because it’s obviously well-suited to that, but I’m much happier whenever it’s practical to do things the *nix way.
“…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.
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.
> Well, why not just an IDE then?
Some of my reasons:
1) An IDE isn’t just an *integrated* set of tools; it’s an *opinionated* choice of tools. It’s the vendor’s idea of how various things should work; auto-completion, search-and-replace, project-aware code navigation, folding, viewing multiple files, bookmarking, and what-not. By starting with Vim and adding plugins as I go along, I can try out alternatives and make my own choice. The result feels more like home, and reflects my manner of thinking. From time to time I change plugins, or throw some away.
2) An IDE often integrates *too many* tools. My OS already has a terminal, file manager, and search tool; yet the IDE crams in their own versions of these. There are also plenty of tools in an IDE which I just don’t need at all. Even with 40 plugins, my Vim is still far lighter than NetBeans or PHPStorm.
3) The tools inside an IDE are competing for screen space, in various panes. The terminal, filesystem tree, and console are all cramped. These panes can be collapsed but I have to use the IDE’s own controls to manage them. When I use a separate applications the OS is aware of them, so I can manage them using my window manager, task manager, and fuzzy-finder thing. Of all my reasons for avoiding an IDE, this is the most important one.
4) Vim isn’t really about keyboard *shortcuts*; it’s a text editor with a command line. I don’t have to learn a gazillion keyboard shortcuts, because the command mode provides suggestions. I use many of the keyboard shortcuts from bare Vim, and have a few leader-key mappings for some commands I use a lot.
There have been a few features where I preferred an IDE for a while:
A) I used to fire up NetBeans just for step debugging. You can get command-line step debuggers, but it’s an activity which really benefits from the multi-pane approach. Nowadays I use the Vim VDebug plugin.
B) Project-aware code navigation, and auto-suggestion. I tried various IDEs for this, but it wasn’t an important enough feature for me to switch full-time. For a while I used ECLIM, which lets Vim talk to a headless Eclipse(!) to get these features, but that’s quite resource-hungry. Nowadays Vim has LSP client plugins, and I’ve become confident using Vim’s CTags features.
“Well, why not just an IDE then?” this question comes from someone who like the authors has no complete knowledge on the topic, in other words you might know what using and IDE is but you have no idea what using emacs or vim is like.
second, with vim and emacs you are in total control with IDEs you aren’t, because the developers of the IDEs are always changing the structure of the design, I have been programming for 24 years and in this years I have used everything out there, and IDEs kept changing and slowing down my machines, no matter how much hardware do I have the IDEs ALWAYS slow it down. Vim and Emacs remain the same *under my control*, new features are added to them but the don’t disturbe the experience, they only improve it, they are better thought. And the main reason they are not disturbing is because the experience is custom to begin with, most IDEs come with a stupid philosophy on how to write code.
modern pseudo-IDEs like atom and vscode follow modern developer practices and that is code and optimize later, while older coding practices like in the 1990s was to always optimize code, they are damn slow.
there is nothing special about modern IDEs they are a pathetic imitation of IDEs from the 90s and those were a pathetic imitation of IDEs from the 80s in particular the Visual Age IDEs from IBM which were based on Visual Age Smalltalk that was an imitation of the original Smalltalk from Xerox. They haven’t evolved a single thing, they all follow the same structure.
So no, IDEs are garbage.
“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”).
Interesting article. I come from an Emacs background but have recently switched to VS Code. There’s no going back for me now. I love Emacs and have done for two decades – the key bindings and customisability has meant I invested deeply in it. Plus, as a pianist (amateur), I still type much faster than I “mouse”. You can really feel like you’re flying when coding and that’s why I stuck with Emacs until recently. I will continue to use Emacs for text files. However, VS Code’s integration with the modern languages I write in today (and tomorrow), as well as superior intellisense and autocompletion (yeah I know Emacs _can_ but…) means adopting a modern IDE is a no-brainer, even for an old hand like me.
There’s no scarcity when it comes to development tools, especially when outstanding free open-source software (FOSS) options are included.
It is not necessary to think in terms of “either/or” or “all or nothing.” Embrace the freedom and power of “both/and” thinking.
My 33-blade Swiss Army Knife is in my toolbox — somewhere. It’s heavy and close to 2″ thick. My 2-blade pocket knife is maybe 1/8″ and it’s always with me.
I committed myself to mastering Vim during lockdown. Can anyone master Vim fully? I’ll never call myself a Vim master, but I can say that VS Code and Sublime are now the sidekicks and Vim is wearing the cape.
Superheroes need sidekicks and teams, so let’s cut out the binary thinking because there’s room for the superpowers of all tools in the fight against crappy insecure code.
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.
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.
I’ve used vim to edit config files, take notes, read documents, and other non-programing tasks for years. When I began to study programming, using vim for that as well came naturally, but I have been open to alternatives. I clicked this article expecting to learn some of what makes IDEs so useful, or maybe some advice for when to use an IDE over a text editor.
Instead I learned nothing. This article reads more like notes the authors took about the available options for code editing. When I reached the end I was surprised — I must have missed the part where the software was discussed, as all I read was a typecasting of vim/emacs users. The author clearly favors feature-rich IDEs, but after reading this article, I couldn’t tell you why.
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
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.
Ok, there are a few Vimmers here who can’t seem to take a little tease 🙂
I love the shit 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.
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.
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.
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.
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.
I learnt programming in fancy editors and IDEs. Eventually I was forced to work in a plain tty for some weeks and I knew about the existence of Emacs and Vim, but never got serious about them. I quickly read the differences between them and decided to go with Vim. I was amazed by how much stuffs I was able to do in a terminal. I thought I’d be slower because moving around a file, or multiple files, without being able to use the mouse sounded like it’ll be very painful and difficult. Vim made it easy and provided me with an abundance of ways to browse and edit my code. I was shocked and seduced, so I forced myself to use it even when I didn’t have to, so I could learn more about it and get used to it. I don’t think I’ll ever go back. I know about all those fancy editors. But the vi way of editing code is amazingly efficient and fun to use.
I don’t feel like Vim and Emacs are legacies of the past, and that no new comer will adopt them. I’m the living proof new comers can still try and love those editors. They are just great. And the IDEs available don’t provide me with better tools.
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.
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?
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.
I’d say some people still use vim and emacs because modern IDEs are a half-way house. An often useful one — above all in the Java/C# of the world where setting up something else than an IDE is far too annoying so better use one — but a half-way house still. What I mean by that if someone’s style is “one good tool for the task, I’ll swap as needed”, in most cases there’s too much in a full-fledged IDE: a command-line is enough for orchestration, the vim/atom of the world for writing, the language toolchain to package… But if it’s “let’s get everything in one program and never have to get out”, well Emacs is better at that than pretty much anything else under the sun.
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.
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!
Ive been a dev for nearly a decade and ive literally never seen anyone use vim as an ide.
I used to use it to create and edit bash scripts… Not too much else
After reading the article, I really wonder if any of the authors use some regular IDE, because arguments written in the article are wrong or at least biased. For example – modern IDEs don’t force you to use mouse. You CAN use mouse if you’re still in the middle of memorizing couple hundreds of shortcuts, but at least in JetBrains tools I use, there is always keyboard only way to do the job. There is also default configuration that can be changed and exported if needed. Really – installation and configuration of IDE in comparison to configuration of development environment built around command line and text editor is extremely fast and easy. Availability and quality of tools like code completion, refactoring, code formatting, debuggers, profilers etc. that are packed into friendly UI not forcing you to google for manuals every time you want to perform some action is great improvement over a command/script driven DIY environment. It’s possible to use both – IDEs and vintage editors for programming, but definitely the choice is not so obvious as shown in the article.
I’m pretty sure the authors of this article have never used emacs. You have git control with magit, code completion and syntax highlighting with lsp, file tree with treemacs, project wide fuzzy search with projectile, if you want tabs there’s centaur tabs, debuggers for pretty much any language. How are they defining IDE?
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.
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.
This is the strangest article I’ve ever met on this blog. Unfortunately, such disinformation brings a lot of harm to other programmers.
Other comments already provide enough details, so I’m just adding one more vote against this article.
I’ve been using IDEs for 12 years, and only a year ago I felt brave enough to try fully switch to Emacs and vim. Well, I lost 12 years of effectiveness because of such articles.
The fact that it took two people to write this article is proof that IDEs dumb you down.
I love how the over-zealous comment section basically proves the point of the article LMAO
Besides ubiquity and comfort, there’s also performance, size, and hackability. XCode is something like 40 gigs now, Vim is probably a couple megabytes, including a scripting language interpreter for customizability. And none of the vim plugins for the major IDEs actually give you full vim functionality (recursive macros are especially rare). If you’re doing everything in one IDE, you’re ignoring all the power of your operating system and other tools. Editors like vim are meant to be used as a part of a full-featured OS (see `:h :!` for example), not build everything anyone would possibly need into a gargantuan editor that runs in a web browser runtime and uses a gig of RAM just opening a blank file. But the most important mistake, I think, is assuming that old (but still actively developed) software is bad and anything new is good. Vim (and Emacs too, I assume, but I’m a vimmer personally) work great, are infinitely hackable, are stable, and are still getting new features, so why _would_ anyone who already uses them give them up? Most IDEs don’t offer anything we don’t already know how to do, except in technology-specific cases (like, if you’re a .NET Framework developer, you use Visual Studio or maybe Rider). Anyway, claiming that battle-tested tools with regular releases are “antiquated” and painting anyone who uses them as old fuddy-duddies isn’t just in poor taste, it’s incorrect. People use the tools they like to use, and some of those tools (like vim, Emacs, make, and the Unix operating system family) are doing just fine 🙂
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.
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.
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.
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.
I’m just more productive using my BRIEF keyboard mapping. My hands never leaves the keyboard and the code just flows onto the screen.
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.
Modern IDEs don’t provide the key feature of EMACS: on-the-fly customization. In EMACS I can write a new function in Emacs Lisp and bind it to a key in a couple of minutes. Or even simpler I can record a key sequence as a macro. With any of the IDEs I’m familiar with, I would have to write a plugin in some low-level language like Java, compile it, then restart the IDE with the new code in the class path.
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.
There is only two reason why people use vim; because you ssh into a terminal or something or because you just want to tell folks you use vim in an attempt to sound superior. Updating large blocks of code or working on multiple files through VIM is just an annoying headache. Let me just switch over to this other file real quick… oh wait I can’t because I need to save my file first, then quit, load the other file. Ok start editing the other one… no wait I didn’t press fucking “i” to put myself in edit mode. Hmm, not sure if this is the right change to make, let me switch back over… no wait can’t do that without either losing what I just typed or overwriting with possibly something I don’t want yet. And while using git from a command line isn’t difficult, having git integrated into a modern IDE is infinitely easier. Atom makes this work pretty seamlessly. As does VS Code, which I’ve run projects without issue containing hundreds of files.
VIM has a place, but it’s only where modern options aren’t accessible.
The only takeaway from this comment is the stark evidence of your lack of Vim experience. I would vouch that every sentence in this comment is incorrect.
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).
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.
My preferred IDE is Codelobster – http://www.codelobster.com
Thought I didn’t read all replies, there is one other advantage to using a powerful editor (emacs/vim) as an IDE which I didn’t see enunciated: one interface / multiple projects. I use the same emacs environment (even the same session) to build code in different projects. build documents, run shell commands, grab files across the network (thanks to the magic of tramp), check-in modified files to any of git/svn/hg using the same simple keystrokes, etc.
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.
The Windows bias of the authors in this article is astoundingly overbearing. This article brings the editor wars into the modern era, and brings to light the essential character of all such holy wars: culture. This time, it’s not vim vs emacs, it’s Windows vs Unix, complete with snide remarks. I could just as easily make similar comments about the author: relying heavily on Notepad shows that he *clearly* doesn’t want to learn anything about the computer he’s using, that he clearly doesn’t care. He’s probably not even a programmer–I mean, have you ever heard of a programmer who uses Notepad? Talk about refusing to change, being stuck in the past, and all the things the authors of this article accuse vim and emacs users of. The hypocrisy is as bad as the bias.
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.
I use vi in *nix environments because it is reliably there and requires little or no configuration. You can just go to work. I normally use notepad++ on Windows, but even there will occasionally use vi. I am not particularly good at using vi, but I can get a job done. For those of us who do not always have the luxury of choosing our development environment, and who are being paid to produce, vi is the ‘sure thing’ that allows us to get on with work without making excuses because we are not competent in the environment we are given.
When you move around a lot, and you have to produce for pay, you need a sure thing, and vi is that sure thing when it comes to editing text files.
I’m 16 and started coding about 5 years ago, but I recently tried out and now prefer vim because of the keybindings and the simple get-the-job-done manner of it. I still use VS Code in places where vim support is lacking like with Dart/Flutter, but the vim extension for Go is miles ahead of the messed up vscode one.
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.
Oh, and “arrow controlled”? Wrong, again. Best piece of advice I ever received was to use the cursor keypad “hjkl” to move around in vi.
What a pair of ******s!
IDEs should help you but not dictate how to make things work. The trouble with IDEs like visual studio is that they create solutions for you then behind the scenes would add alot of scaffolding just to make things work. In time these scaffolding will be obsolete and may cause compatibility issues. Instead of worrying about the feature program we end up worrying about the scaffolding. The good thing about lower level IDEs or just plain editors is that nothing is hidden from you and you would clearly understand what is going on.
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.)
– Open Source, strongly invites you to contribute.
– HJKL key setup is amazing
– Very customizable
– 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.
both vim with vscode are equally valid today, it all depends on your preferences, I have left mine here, but until you have tried both technologies you cannot form your own on both.
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.
Two words: Emacs Org
The authors of the article demonstrate a truly bizarre view on the topic and a profound lack of understanding.
Lets just say, If you do not have any idea what you are talking about… maybe better read an article instead of trying to write one.
Better to remain silent and be thought a fool than to speak and to remove all doubt
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?
Some people confuse “new” or “modern” with “better.” That leads to commentary like this. IDEs are opinionated. You learn to code the way the IDE lets you code. Eventually, you come to think that that is the “right” way to code. People who use editors rather than IDEs are just people who want to tell the tool what to do, rather than the other way around. IDEs like PyCharm or Intellij IDEA take years to learn to use efficiently. I know. I’ve used them. Thus, they have nothing on Emacs or vim (or any other editor) with respect to the learning curve. Remember the old saying: “If every job looks like a nail, you need more than a hammer in your toolbox.”
I mean, how insecure do you have to be to rationalize your envy in such a horrible web of flawed logic? You can’t/don’t want to/won’t learn Vim or Emacs? Guess what, it’s OK, you don’t have to. We support diversity of ideas and paradigms, unlike you.
“This has led users to literally turn Atom into Vim, unable to let go of the past, unwilling to fully embrace the future of code editing.”
This aged really well now:
The main missing feature of modern IDEs is a meta-language allowing on-the-fly customization.
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) 😉
I think education-oriented IDEs play a role. A good example is the Arduino IDE. To set it up you have to select your board from the menu, and have a nifty import library dialog. All builds and deployments are done with one button. The overall IDE is pretty minimalistic and doesn’t come close to being as complex as Vim or NetBeans because it doesn’t have to be.
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.
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?
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.
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.
so many angry nerds here priding themselves on not using a mouse….
If you write code, you are a nerd. You don’t become a cool hip guy for using an IDE and a mouse.