-
Modern IDEs are magic. Why are so many coders still using Vim and Emacs? stackoverflow.blog
Why an IDE? matklad.github.io
authored by
matklad
2 years ago
Why I Still Use Vim buttondown.email
via
wesleyac
2 years ago
The authors seem to be describing Emacs.
Do people just not know what can be done in Emacs? Git control???
Emacs is amazing, but has a horrible issue with discoverability. “Distros” like Doom or Spacemacs have tried to address that, but, regardless of my personal feelings on them, they haven’t really broken into the mainstream enough to be noticed. (And as someone who used Emacs for years, I think the discoverability bit is very real.)
I have used Spacemacs for a while, but as someone who frequently opens and closes the editor completely - it just boots way too slow, even IntelliJ is faster.
emacsclient --alternate-editor=''Really, Emacs in daemon mode is faster than anything else. Even vim is slow to start in comparison. I don’t understand why Emacs is the only editor which does this. I guess, you need to be reeeealy slow for someone to actually implement this feature :-)
I’ve tried emacs daemon mode, I never found it very pleasing. There were a number of papercuts I was running into… I need to figure out again what that was.
Yeah, I actually have the same experience, getting useful setup of daemon mode took me several tries. Like, you need to pass an empty string as an argument to
--alternate-editorto have it auto-spawn the daemon if it isn’t running yet. That’s right next to sending SIGUSR1 to du in my chart of horrible CLI interfaces :)People who aren’t used to having a fully-featured editor boot, over SSH, in the blink of an eye don’t really know what they’re missing. One less interruption in the flow of thought.
Never really got used to emacs, but boot time is one reason i switched to vim.
Yes, this is the word I should have used. Good GUIs can really help with discoverability.
I do want to specifically point out that the parent comment emphasized the mention of “Git control”, when one of the aspects of the Emacs ecosystem a bystander is most likely to have heard praise for is magit (another being org-mode). So it’s not so much a matter of whether it’s possible to discover magit’s existence in a vacuum – it’s that having access to one of the best interfaces to Git, period, is something often evangelized to non-Emacs-users as a point in Emacs’ favor.
What do you mean by discoverability? Shoudln’t the help-system address that? C-h m to see what commands are bounds, C-h f to see what they do, M-x customize-group to see what you can change.
C-hand friends are great, but you kind of have to know what the options are to get the help you want. For example, you can do a lot of Git manipulation in dired, but you need to know that exists, or at least to think of maybe dired might have some stuff in that area, to even know what you should be asking for. Experienced users, sure, I think this is sufficiently discoverable, but new users (and I mean that fairly broadly), it’s trickier.1: I want to stay in the terminal
2: When I edit code, I don’t want anything on my screen except the code.
3: I don’t want to use a mouse.
4: I want to be able to fully customize everything.
5: The default Vim keybindings are already super awesome.
I like a system to be composed of parts that do one thing well. When it comes to editing text, Vim does this better than any other software I tried. For everything else, I have other command line tools that are at my fingertips.
Regarding keybindings: I don’t know, how most developers translate something like “Ok, I want to cut out this line and put it at the end of the file” into something their “IDE” understands. In Vim, you type ddGp and are done. It takes a blink of an eye. After a while, most text editing tasks just roll of your fingers without you thinking about it. It is a magic feeling of productivity I never had in any other editor.
Vim is my goto text editor, so this isn’t a hit job. But Vim is not good at composing third party tools to create an IDE like experience. Vim is painful to extend and script but a pleasure to drive.
That’s part of what keeps the default experience at least moderately sane.
Personally, I’ve always felt examples like “Ok, I want to cut out this line and put it at the end of the file” a bit contrived. I have never wanted to do that with my code. It would break my code. It sounds more like an easy vim golf exercise. Typically, at least for me who is at best a vim novice, navigating a project and global search and replace are things I’ve found vim to suffer on and among the main reasons I continue to use VS code.
In my experience, it applies to all text editing task. Not only to contrived examples.
Moving lines (or larger parts of a file) around happens pretty often. And its not just easy to reach the end of the file. Say you want to move the current line below the line with “hello” in it. Then it becomes dd/hello[enter]p which means:
And you quickly learn to use it like a language. Want to cut the current paragraph instead? “dap” = “cut the current paragraph”. Cut the current word? “daw”. Cut the current block? “daB”. etc etc. Want to copy instead of cut? Use “y” instead of “d”. Want to paste above instead below? Use “P” instead of “p”. With just a handful of these verbs, you start to communicate with the editor like you could have never imagined before.
Cut the line, find “hello”, escape, move down, paste line.
No particular example of Vim usage is a massive time saver. Sure, copying stuff to the end of the file can be done pretty fast without vim. Sure, you can change the code in parentheses pretty fast, too. And you can delete a couple of arguments from a function just fine in any editor. But with Vim, these actions are nearly instant:
The last two are examples of the actions that I personally commonly perform when editing code. The real benefits start appearing because you can do everything this fast. Most actions require only a couple of keystrokes. And the keystrokes are arranged in such a way that you can come up with actions appropriate to any situation. Because of this, you don’t even have to think about what you’re doing: you’re editing text at the speed of your own thought. There’s no “press the left button to expand selection until the comma”, there’s no “drag mouse to select line”. It’s just… done. And that’s what makes me reach for vim key bindings even in other editors.
Home, Shift + End, Ctrl + X, Backspace, Ctrl + End, Enter, Ctrl + V (or press right arrow after the Shift + End while holding Shift, then you can skip the Enter as well). Not as efficient as vim, but it’s easier to learn in my opinion (I’m a vim user myself).
You can remove Home, Shift + End and Backspace keys. Almost all editors default to copying/cutting the whole line if there’s no active selection.
Cut (or yank) the line, move to bottom of file, paste (or unyank).
Two things for me:
On top of that, there’s the fact that most of the other tooling runs in a terminal. If I use an IDE, I have to use the IDE’s terminal emulator for anything that’s not text editing. These are universally worse than a dedicated terminal emulator. If I use an IDE for a while, I typically find I pull up a decent terminal for a load of non-editing tasks and then I am tempted to just run vim in that terminal.
A lot of the magic is annoying. I’ve been using vscode for the past year, and while there are a lot of upsides, there are also plenty of downsides:
It’s cpu intensive and a memory hog, to the point that sometimes keystrokes take a while to appear
A lot of the autocompletion, auto-brackets and auto-import features are wrong and annoying, and difficult to disable.
There is a weird bug that sometimes messes up the cursor movement. I couldn’t find anyone else having it, but it happens even after a fresh reinstall.
Configuring vim correctly can be just as painful, if not more, but I definitely feel the appeal.
I’ve recently being doing coding competitions. The online editor has bracket/brace completion that can’t be turned off.
So I often end up with code like this:
Whoever came up with this functionality seems to believe these are universal truths:
VSCode is not representative of IDEs as a whole, though; to me it’s kind of “IDE lite.” You get some of the downsides of a more full-fledged IDE but you don’t get all the upsides.
For my day-to-day code editing I use a mix of vim and IntelliJ IDEA Ultimate with language plugins. Every once in a while I give VSCode an honest try and I always end up going back to IntelliJ because VSCode’s feature set is anemic by comparison. It’s especially noticeable when I want to make changes that have ripple effects across a project like refactoring a class hierarchy or extracting a helper function for code that’s repeated in a bunch of places. Code completion is also noticeably better in IntelliJ, e.g., when I’m editing Python code, it will auto-add
importstatements if I try to autocomplete a function that’s not imported yet. And as you noted, VSCode gets the autocompletion wrong pretty often. IntelliJ doesn’t get it right 100% of the time, but it gets much closer.I’m not trying to shill for JetBrains here; other full-fledged IDEs like the non-Code version of Visual Studio also have more robust feature sets that may make them a better tradeoff than VSCode.
Well that’s incredibly rude.
Edit: this article is poorly written. It sets up that emacs and vim are harder to learn and offer a lot less to newbies, but also says that people prefer them because IDEs have a lot of configuration and are harder for beginners.
Well, once you know vim you can apply it to any text file. If you switch programming language or environment for some reason, it can be tempting to use vim or emacs instead of learning to configure a new IDE (you can either use vim out of the box or download your dotfile – both are probably easier than learning and configuring a new IDE).
I get to use all the same synced settings and shortcuts in the JetBrains IDEs across languages and get updated tooling for free as well.
You’re putting more thought into this than the original authors did. They presented it as “learning Vim for the first time is easier than learning an IDE for the first time”.
Something tells me that neither of the authors has substnatial experience as software developers. But I think both of them have experience writing text, on macs perhaps? Perhaps even using Sublime Text, an editor that has a vim/emacs lookalike mode?
I’m an emacs user myself, FWIW, and my development screen has no animations in my field of vision, and no web browsers either. (The browser I’m using at this moment runs on a different host, outside my regular field of vision.) My big bottleneck is to melt into the code, and extra windows don’t help with that, magic or not. It helps when the code fills my field of vision, that way it’s easier enter the zone and have nothing except reliable computer input and feedback.
They don’t – both of them are career content marketers.
I suspect the stack overflow blog is also specifically designed to rile up a dev audience to increase engagement; make obviously absurd claims so armies of commenters on the internet spike up their numbers.
And here I am commenting on it too. Mission accomplished :(
Content marketing is a odd profession. People who do that for a living describe themselves using another term, such as “technical writer”, which makes it sound as if what they do is somehow dishonourable.
I wrote “have experience writing text” precisely in order to avoid the phrase they themselves chose not to use. Maybe that was dishonest of me. Or politel
It was a little ridiculous to see them try to sell
gitas an IDE feature when knowing its CLI is universally useful. I get the sense that they don’t really understand how things work in a UNIX workflow.In my organization mostly everything is Java these days. Everybody works with IntelliJ and they depend on it to do a lot of things. I can see my colleagues navigating their code, going to definitions and implementations very easily, clicking on small green “play” buttons to start tests and right clicking on files to “add to git” or something.
In the other hand, I’m an Emacs person and first, I’m not involved in the Java codebase (thankfully). I do most of my work in Go and Python. The support I have from my environment is what I need, code completion, navigation, documentation right there. Above all, a distraction free environment, where the important asset is the code. Your environment should allow you to see your code, to read it and to modify it.
With Emacs and a few key combinations I can run my unit tests, run integration tests, check everything on the CI environment, and of course all the git (magit) fancyness. With regards to this one, I think magit is superior to what IntelliJ people does.
I’m not trying to be arrogant here, I know my limitations as a developer, but I like seeing my Editor (and the rest of the tooling) as what a sharp knife is for a chef, or a good set of quality tools for a artisan, or a well tuned violin for a musician. For a craft that takes years to master, the only capable tool is one that allows you to focus on your craft, on what you are inventing and thinking about, it can’t take you away from that, from the context it gives you to be on top of the text that’s the body of your work. And the sensibility which you can use to produce your work, the fidelity of your thinking. This is text that your are producing, so you better have a calibrated tool to do it.
Of course, all this can be done by a full IDE, but that means that most of it is unnecessary.
What’s to miss about an IDE? A menu command to implement a missing method from a class? A way of renaming my function and all of their uses? Their definitely handy, but they are not used often, and they don’t work to make your code more readable, more maintenable, etc.
I’m also a musician, and I’m basing these lines on both experiences to conclude that mastery is achieved with the help of simple tools.
I personally find that powerful refactoring tools help tremendously with readability and maintainability by reducing the cost (and more importantly, the risk) of uncluttering the code when it gets messy over time. Even though I don’t use those tools much when I’m writing brand-new code, their availability has a more subtle effect on the code I write: knowing that I can painlessly and safely perform certain kinds of structural changes as needed means I can keep the initial implementation simple and focused rather than having to try to anticipate and design for future changes to save future me the pain of manually shuffling things around.
Yeah, agreed. Knowing that I can easily rename a function or a field means that I have to spend less time worrying about whether it’s really worth it to rename it; just hit my key combo for ‘rename this thing’, type in the new name, and I’m done. And you can get this in Emacs or vim just using whatever LSP integration you like.
I’m an Emacs person who used to work at a Java shop - I had to give in and use Intellij, I could never figure out how to configure Emacs to be as powerful as Intellij when dealing with a large codebase.
There was an article I saw recently that described Emacs as an “interface-agnostic editor” meaning you get about the same thing whether you run emacs over ssh, in a terminal, or as a GUI. That’s one reason.
Also, I can be confident that there’s an emacs package for anything, and I don’t think that’s true for any of the IDEs. I can even do my bookkeeping in Emacs, and everything has a consistent interface.
Plus the two classic killer features, org-mode and magit.
I wrote a response to the original article: Why I Still Use Vim.
Who is this article for? I see tons of new programmers who have transitioned to vim within the first few years of their development. It seems to misunderstand what vim actually is. It repeatedly slams on the normative claim that modern IDEs > vim, and that the only reason someone would use vim is because they are too old and burdened by non-coding activities like raising a family to learn a good way of writing code. Bad take after bad take. I want to print this out just to use it as toilet paper.
I use an IDE to browse and Evil-Mode Emacs to edit. Why? Because IDE’s are better at browsing code. But Vim or Evil Mode blow everything else out of the water when it comes to the plain and simple task of editing text which most code is.
Do you use code completion?
It seems like there are three main problems.
You know instead of having autocomplete build the perfect thing in advance, have autocorrect fix the buggy code or prompt for else block or missing match arms. I guess the third one is a service that offers patches against code you haven’t written and code that you have and then another system that applies those patches. God I hate code
Honestly, I really don’t use it. I find that I remember the details of the APIs I use better if I don’t. Doing a code review gets a lot easier if you remember the APIs.
This post raises some good points of a direct comparison of Vim over IDE-lites and IDEs. But in my mind that is not even the main reason to use Vim. For me, the fact that it is in the terminal is such a huge productivity win. Specifically Vim + Tmux lets you create an IDE experience on-the-fly, and it is incredibly flexible, fast and easy to use.
I think its something that is hard to explain, because on the surface it seems that IDEs provide all of the features of Tmux + Vim but already configured and without having to learn the names of various CLI tools or keybindings. But Tmux + Vim is simply a universal IDE experience where every component is easily exchanged for something better or faster, and plugins can be created on the fly; once you’re comfortable with this it is very hard to switch to something else.
That is why there is I in IDE.
I have a more direct answer to the title question: because few popular languages allow for truly powerful PostIntelliJ IDEs.
JavaScript, PHP, Python, Ruby are all fairly popular, and it is impossible to build a correct IDE for them. They are dynamically typed, so, while you can get pretty far with heuristics heroics, you can’t implement refactors which never fail.
C++ is sorta dynamically typed (because of templates) and is very complex overwise.
C I think is a fun exception – it can have a rather awesome IDE support, not sure why it didn’t happen before C++.
This leaves Java and C#, which indeed have great IDE support, and a much larger fraction of developers using and IDE.
There’s common wisdom that you can’t write these languages without an IDE, but I think this gets causation backwards – these are the rare languages for which you actually can write an IDE. As a case in point, IDE usage grows for Go (survey data). Go is an example of a language for which building IDE is possible (comprehensive static typing), and doesn’t take impossible amount of effort (the language is simple).
So yeah, it’s not like we need better IDEs, we need better languages. TypeScript is the perfect example for solving “frontend IDEs” problem.
It is time for the obligatory reminder that automated refactoring as you know it was invented in a dynamically-typed language.
And the simple fact is that the things that potentially would interfere with automated refactorings in, say, Python are things that also could interfere in, say, Java or C# – anything with runtime metaprogramming or metaprogrammy-type features (which includes things that can be accomplished via reflection, runtime code injection, etc.) has the same potential to screw things up.
Obligatory response: in the PostIntelliJ, Fowler claims that smalltalk IDEs were pretty limited in comparison to static-analysis based IDEs:
I haven’t used Smalltalk, so I don’t know, but place rather high degree of confidence on this claim. I trust Fowler, and this statement doesn’t contradict my understanding of how IDEs work.
That said, I would really enjoy reading a more thorough comparison of Smalltalk tooling with IntelliJ from someone who is deeply familiar with both.
The point with Smalltalk was that there wasn’t such a thing as “static analysis” – if you were editing static Smalltalk source code as text files, you were fundamentally doing it wrong, because Smalltalk was designed to be interacted with as a live, running image. That’s why heavy use of dynamic runtime features wasn’t so much of an obstacle to refactoring Smalltalk, because the runtime dynamism had already been accounted for in getting the image running in the first place.
Of software still somewhat commonly used here in 2020, Emacs isn’t a bad parallel for that: one generally does not statically edit Emacs’ configuration, because the system is designed to be interacted with and edited live, and the user is always only an
eval-bufferaway from potentially doing just about anything.But I think the larger point stands, which is that “dynamic typing” as some sort of bogeyman that prevents reliable refactoring doesn’t hold up. And, to reiterate, the same problems people think should prevent refactoring from being reliable in a language like Python are also present in a language like Java. Any language with runtime reflection and code injection is subject to edge cases where static computed-in-advance edits or refactorings may fail, and Java certainly is such a language! In fact, Java is a language where use of such features is openly encouraged as a consensus best practice, where in Python the runtime dynamism is generally there as a feature-of-last-resort, something that new programmers are advised to avoid in the strongest possible terms.
So the argument that the viability of IDEs and/or automated refactoring is somehow related to being dynamically versus statically typed is just a very strange idea to me, albeit one that many people seem to have accepted uncritically.
I disagree with this claim, with a rather high level of confidence. As demonstration that the claim does hold up, here’s the comparison of “Rename Method” refactor in hello world scale projects in Kotlin(IDE) and Python(PyCharm). The languages are chosen to roughly match the level of effort poured into an IDE.
Code sample:
For Kotlin, IDEA just does the rename. For Python, PyCharm forms a list of potential dynamic usages, and asks user conformation for them. For larger projects with dozens of usages, the difference between the two experiences is large.
The reason for the difference is dynamic typing. Specifically, the IDE can’t reliably infer type of function argument. The level of actual dynamism is irrelevant – both Kotlin and Python programs use utterly boring set of language&runtime facilities.
I do agree that, qualitatively, JVM languages are equivalent to Python in terms of refactorability, as JVM is roughly as dynamic as Python. I do think theres a significant quantitative difference between the two. Empirically, for me refactoring Kotlin always just works, refactoring Python often needs manual fixups.
Of course, now, that Python has type hints, the difference for projects which pervasively use it is much smaller. I don’t disagree that type-annotated Python is as easy to refactor as Kotlin.
I also tentatively disagree with the claim that dynamic, image-based tooling is not worser that static-analysis tooling. My strength of disagreement is much lower here, as, again, I haven’t used Smalltalk. I did use Emacs lisp and Clojure a bit, and wasn’t impressed by their refactoring tooling.
But, from general principles, it seems like static analysis does make implementing refactors simpler and more efficient? You certainly can to dynamic refactors by observing how the code behaves under tests and which actual methods are called then, and use that info to offer “precise” refactoring. But precision and speed of those refactors would be proportional to the coverage level and speed of the test suite.
EDIT: after re-reading this, I retract my claim that “is impossible to build a correct IDE for [dynamic languages]”. It is possible under the assumption that comprehensive test-suite exists. Thanks for pressing me on this!
I don’t doubt that it does this. I do doubt the necessity of it. Again, my point is that people seem to uncritically accept an idea that isn’t necessarily true. Any JVM language could be doing runtime dynamic stuff that the refactoring could miss, but it’s just assumed without justification that “oh, we’re statically typed, it’s safe”. And the Python likely isn’t doing runtime dynamic stuff the refactoring would miss, but it’s just assumed without justification that “oh, it’s dynamically typed, can’t possibly be safe”.
That’s the entire thing I’m getting at here. Pointing out that other people bought into the same assumptions doesn’t make them stop being assumptions and doesn’t make them correct assumptions.
I mean, the example doesn’t do any kind of runtime dynamic stuff, there’s no reflection, code injection, meta programming, etc. But still, automated refactor fails for Python and works for Kotlin.
The difference between the two example is not in the level of dynamism at runtime, the difference is in the static semantics.
There’s no reason for the example to fail, though. It’s likely that the failure is due to poor assumptions and thus poor effort on the part of the authors, not because correctly finding references is such an impossible task in Python that it literally can’t even be done at that basic a level.
Or, to put it more succinctly, I could easily write a terrible broken refactoring tool for a statically-typed language. Its brokenness would be a reflection of the work I did on it, not the language it was written for.
How would you fix this refactoring? How’d IDE know for sure that
spam.rename_merefers toSpam.rename_meand not so some other method with the same name somewhere else?I can see two ways to do this, both of which are non-trivial trade offs which huge caveats attached. I wouldn’t really characterize this as “poor effort on the part of the authors”: this is PyCharm, it’s developed by a team of brilliant engineers at JetBrains, the same folks who build IntelliJ IDEA. It also is (not 100% sure) the biggest source of revenue among IDEs after IntelliJ IDEA. There’s no lack of desire, expertise or funding for fixing this issue.
First approach I see is to run a test-suite and to infer types using runtime type information (then complexity of refactor becomes O(time to run test suite)).
Second approach I see is whole-program analysis (then complexity of refactor becomes O(size of the project), and I am not entirely sure that whole-program analysis is feasible at all).
The existing approach works in roughly O(number of usages of method).
First, it’s worth noting that you’ve moved from saying this is something that’s not possible in dynamically-typed languages to saying that the approaches you’re able to think of don’t have the performance characteristics you want.
Second: how would I fix this? If I were forced to go down the path that you (and presumably its authors) went down, I’d probably fall back to the hack of asking the user to confirm ambiguous potential references before acting on them. But I think that would be a product of the chosen assumptions about how refactoring in dynamically-typed languages works, not an unavoidable inherent aspect of dyanmically-typed languages.
Teams of engineers – even “brilliant engineers” – who have deep-seated assumptions build on those assumptions all the time. And when those assumptions are wrong, the things they’ll build are wrong, too.
Could you describe the proper fix here? Which is not bound by any incorrect assumptions and is not forced to go down any specific path?
So, the only way you end up with the approach they picked for Python is if you assume “it’s dynamically typed, anything might be anything, give up on making sense of it!” And that’s a terrible approach that produces software people won’t want to use.
Let’s step back and take a simpler example. Suppose you write a Python program that contains the following line:
Now, it’s entirely possible – seriously possible – that someone will do runtime monkeypatching which changes the value referred to by the integer literal 1. For example, someone might change it to actually refer to the value 2.
No, I’m not kidding. I know someone who worked out how to do this using only the standard library. Python really does expose enough of its own guts to its dynamic features to make this possible.
But does PyCharm throw up its hands and say “literal 1 might actually refer to who-knows-what, can’t do anything what that!” Or does it act like 1 will be 1?
Even better: what does Python itself do? Python assumes 1 will be 1. The bytecode compiler will even do statically-deduced constant folding on that expression before it ever gets to the runtime and optimize that expression to
result = 2. And that should be a big clue that maybe PyCharm is going a bit overboard. Because, ultimately, I suspect it’s developed by people who probably don’t really trust dynamically-typed languages and so build in excessive checks and guards and “well what if” support that nobody who’s actually comfortable in dynamically-typed languages would ever do.(there’s an aside here where people often assume that all dynamically-typed code comes with massive test suites full of
assert isinstancechecks to prove things a statically-typed language would take for granted; the fact that real-world dynamically-typed codebases don’t do that should also be a huge hint that those people have missed something important)So. Can you do absurd things in Python? Sure. But the whole attitude of Python is to say “you can do that, but it’s on you to deal with the consequences”. The right thing for PyCharm to do would be to assume that calling
Spam()creates an instance of theSpamclass whose definition it can easily find, and that renaming a member ofSpamshould rename that member on anything that traces back to aSpam. Which is what PyCharm is actually doing while pretending not to be able to! The only reason it shows you a more complicated interface is because someone on the PyCharm team decided “you know what, someone might monkeypatchSpam()at runtime to actually beos.unlink('/'), we better ask the user on every single instance just to be safe”. The programmer who actually does monkeypatch it to be something completely incompatible has already accepted the consequences; PyCharm, rather than trying to say “I won’t do anything that might hypothetically be unsound in some theoretically-possible universe”, should instead say “I will proceed on the assumption that you wrote code like a normal person, and that if you didn’t, you were willing to take on the consequences of that”.Which really is the entire difference between programmers who only are capable of working in statically-typed languages and programmers who are capable of working in dynamically-typed languages.
Thanks for putting time into elaborating this!
I mean, I don’t write much code any more, but even when I did I used Emacs. This might be a “blub” thing, or the fact that when I wrote software, a lot of it was in C, but I never really got the excitement around IDEs. Also, I’ve been using an Emacs of some description since like 1987, so the muscle memory is pretty well established at this point.
I might be wrong but I’ve heard that some IDEs like CLion and I think even Visual Studio have trouble with very large C++ codebases. Which IDE are Mozilla employees using with the Firefox code base?
If you learn how to use an UNIX shell well, you have way more power than any IDE will give you, and will be able to use this power in any machine you’re using.
And like, yeah you can get
git controland things like that on your vim if that’s your style, but you don’t really need that when you’re already in a shell window. You can just run git commands ¯_(ツ)_/¯ . That’s the thing with using a text editor that runs inside the terminal, you use command line tools for a lot of your tasks, and use the text editor just to edit text. And as a text editor, vim is actually pretty great.Besides, Vim configuration with modern plugin systems like Vundle/Vim-plug is not even hard anymore
Very similar topic
Yeah, this is an indirect response to that: I’ve been meaning to write this post for a couple of months already, and seeing that post pushed me to actually doing this.
I never felt comfortable in IDEs. It’s so easy to loose yourself, and because you stop thinking in terms of buffers, people stop programming that way, that in turn might even increase your dependence on IDEs. I’m not sure if that is what we want, at least as long as programming is actually still done with files, in byte-sequences, etc. It is imaginable, that there is a potential to make a step forwards, to leave behind some of the complexity that didn’t scale well. In my eyes, it reflects the general sad state of computing we have cought ourselves in.
My personal theory is that in the last few years, Go tooling has broken (such as go-code for autocompletion), making it more burdensome to maintain it seperatly. Of course, replacing it with gopls, a LSP implementation, that self-describes itself as alpha software isn’t that great either, so I get it if people who don’t want to bother with all these things choose IDEs, just to forget it.
What annoys me, is that for a long time, Go was one of the best languages to work without IDE support, probably also because of it’s Plan 9 heritage, and the interest to make it work in Acme.
This seems to imply that thinking in buffers is somehow different (or better?) than thinking in whatever displays the code in an IDE. And is a dependence on an IDE really much different than dependence on Emacs or Vim?
I think it is different, thinking in terms of buffers (or rather files) works with the IDE approach, but the other way around is harder, which is arguably a limitation of the more traditional file-based approach.
I use Vim because of the reality of most of my development (a lot of C on the weirdest POSIX platforms, not even VS Code remote editing will help there - there’s not even Emacs), but my happiest development experience was .NET with Visual Studio.
(I wish there was an IDE for Erlang/Elixir that would come close to VS…)
What are you missing (Vimist there). With ElixirLS/ErlangLS I have everything I need from the editor/“IDE”.
It’s kind of a holistic thing that’s hard to pin down specific things with - the editor being actually aware of code, but also structure and the tooling around your code. Emacs people using SLIME are probably even closer to this ideal ideal I was.
Most of the answers to the question asked are answered in the article, but there are always 2 things that come back to me.
There are a few good IDEs out there, but the decent ones cost money. The free ones look great, and have loads of features, but are prone to being slow, or crashing. Vim and Emacs are free, and, with some elbow grease, just as functional as IDEs are for most programming languages.
Most of what IDEs bring to the table is some kind of integrated shell, and file explorer. But with a tiling terminal emulator like Terminator (Yes, that was a cheap plug, but that’s how I use it) or a tiling window manager like i3wm, you can set up your own much more functional environment that can be easily integrated. Yes, you lose handy pull-down menus, but really, that’s about it, IMO.
Huh, that’s a surprising sentence to hear. IDEs actually got famous because of advanced code analysis that powers autocomplete, go to definition, find usages, automated fixes and refactorings, and tons of other similar features; integrated debuggers; integrated UI builders.
These days the analysis is available in an editor-agnostic way with LSP though. (The debug counterpart DAP is not really taking off, not yet at least.)
I tried to make this argument in the lobsters comment section on the original article, and got slapped down because according to my responder, IDEs are so much more than just an Integrated Development Environment https://lobste.rs/s/sfu4l3/modern_ides_are_magic_why_are_so_many#c_n1qyea
My IDE is vim in a terminator pane, with another couple of windows for git commands and debugging. It’s exactly what any free IDE such as Atom, or VSCode, or the new Nova IDE from Panic give me, but it’s all mine
I don’t think you were being slapped down. I think you’re just using different definitions of IDE.
I’ve used some of the more powerful features of what some might call ‘proper’ IDEs and they can be amazing. The assistance offered by ReSharper (it’s not just about refactoring) and OzCode in particular were huge productivity boosts for me, and I even wish for one of the killer features of the VB6 IDE: edit and continue (while debugging)
I don’t build large enough chunks of code these days to benefit from any of that, however, and am happy with just a bare text editor in a terminal. A bit of code completion feels like an unnecessary luxury, but if it’s there I’ll use it.
I use and greatly appreciate IDEs sometimes. For my use cases and preferences, however, vim/unix ecosystem does the job better 90% of the time because:
vim foofor convenience.All that said, I’ve found that IDEs can be great for learning about new problem spaces, for abstracting away system concerns, or for working on complex projects (provided the IDE tooling can help you manage the complexity). The only one I actively use is CLion, since it “just works” on Windows and MacOS and gives me autocompletions that were a pain to configure in coc.vim. It’s a beautiful and thoughtfully-designed program.
I learned on an IDE (VBA) and eventually moved to vim instead. Why? Because once I learned to code I found that all the popups and typing-guesses and etc were just visual noise at best and slowed down the brain-dump-code-into-computer process at worst. VBA was great for learning at the time because the web was slow and I was on Windows so there were no docs for anything. Having the IDE show me what methods exist and provide access into little bits of hidden docs was a lifesaver but now I have more docs than I will ever read (in most stacks) and I can read the code when I don’t (because I use FLOSS tools and stacks instead of VBA).
I have started playing with live coding environments, playgrounds, “advanced repls”, and even another IDE (emacs) recently because I have an interest in this idea that I could tinker something together in my REPL-alike and then just save it and be done instead of using that as a mental model for going to type out fully-formed code from scratch. I don’t think this process will produce maintainable code “in the large” but I’m fascinated by its application for enabling everyday tasks. Most IDEs on the other hand are very much designed around the “in the large” use case and I’m not sure I’ve found ways they still help there anymore.
I love IntelliJ but there are still a couple reasons I have Emacs open all the time:
The first item really underscores a truth about software engineering, which is that when you specialize your metaphor, you enable new and powerful functionalities, but you also reduce the places you can use your tool. A lot of files I want to edit are not “projects,” but much of IntelliJ’s special power comes from that project metaphor. For this reason, I feel safe saying that there will probably not be a world without editors whose primary metaphor is files rather than projects. This is similar to forums vs. Stack Overflow. SO gives us a question-answer metaphor that makes technical QnA much more straightforward and good, so a whole class of “technical forum” becomes unnecessary in light of SO. But the notion of “forum” is a lot more general than just technical QnA so while SO gutted quite a few of these sites, it didn’t utterly destroy the concept of forum (we are on one, essentially, right now).
The second item has to do with community support. It takes a tremendous amount of technical energy to create something like the IntelliJ Java or Python plugin. That energy doesn’t exist for most programming languages, only the most widely-used and perhaps profitable ones are going to get that treatment. So as soon as you move away from a top-10 or maybe top-20 language to something more niche, IntelliJ becomes just a massive and heavy text editor. I’m sure many programmers, especially new programmers, are not learning and dealing with weird stuff like Prolog, so to them, there is no compelling reason to fire up Emacs. But for me, for lots of languages the syntax highlighting is fine, probably the most I can reasonably hope for, and Emacs is an elegant tool in its own right for that situation. Ditto for Vim.
Aside from these, there are plenty of situations where I log into a remote machine and have to edit a config file there. Sure, I could use tramp for that (sometimes I do) but if I forget or whatever, emacs/nano/vi are already there and I can just use them.
I have never used an IDE that doesn’t cause my whole system to stall for 20+ seconds as I type while it tries to do autosuggest or calculate changes to syntax highlighting. VIM can do all of those things without ruining my productivity.
(I have no idea how it is that IDEs are so much less efficient. Smart people work for JetBrains, but a linear search of all the symbols in a large codebase wouldn’t be this resource-intensive.)
Vim lost me with its blue text on black default rendering it impossible to read. Nice default.
Also going to the line I was last in a file is annoying as hell, along with its inane idea that inserting a line after a comment should also be a comment.
It’s clearly tailored made to annoy me so much that I end up having to give up and just build a more sane BSD no stupid “feature” vi that just is vi.
Sounds like you have an awful distribution, upstream vim out of the box isn’t that bad at all (though terminal colors can be iffy regardless). But I actually do think this is a good counterpoint to the claim that it can always be used anywhere… I frequently ssh into computers and find godawful vim configurations that just frustrate me.
That auto-comment thing is one I commonly seen turned on that just drives me nuts.
I like my vim, other people’s vims tend to be broken trash. Frequently arrow keys randomly fail too, like come on, why would they set it up like that?
Is this vim’s fault, though?
set bg=darkwould fix this instantly.There is a disconnect between traditional terminal emulation world (vt100, terminal, etc) and the GUI world. There are no standard ways for a CLI application to figure out colors used by its GUI rendering. This causes quite a lot of user experience problems, indeed.
In my case, it’s because I’ve been using the same editor for 25 years (and its neither vim nor emacs) and I know how to use it (that, and Unix is my IDE). Also, the few times I have tried an actual IDE over the decades, they crashed. And I don’t mean I tried loading in a 10,000,000 line monstrosity of a project and it crashed, I mean, one file of maybe a few hundred lines and it crashed. The editor? The command line compiler? Never had problems with the code I wrote—only the IDEs I’ve tried.
Also, there’s the issue of editing text over a SSH connection. IDEs don’t exactly have a great story for that.