First, notice the preeminence of Emacs and Vim! Engineers who use these editors pass our interview at significantly higher rates than other engineers. And the effect size is not small. Emacs users pass our interview at a rate 50% higher than other engineers.
https://triplebyte.com/blog/editor-report-the-rise-of-visual-studio-code
Hmm Iām wondering about sample size here, particularly with the split between majority and minority languages and environments.
Additionally, I would prefer to see such a study spread across different companies to try to mitigate for interviewer bias. While they take pains to state that editor preference has no effect on hiring, I feel like emacs/vim coders are hipster-bro and purist/old-school programmers, which can certainly affect acceptance rates.
But Black Dynamite. I use vim in the community.
Iām definitely not a hipster, so I must fall under old-school then. Thing is, when you use vim for 15+ years, itās really hard to move away from it. For me, I just hate using the mouse that much when Iām working, pretty much only for copying larger sections of code to paste elsewhere. It is also forever amusing when someone else tries to use my IDE and they canāt figure out whatās going on.
Thatās because they are.
Eh, not true. Okay, Iām maybe not 15+ years, probably closer to 10+ years, at least as a primary editor. I still use it for quick and dirty things on Linux, in which case itās probably closer to 20+ years. Iāve moved on to better editors. Part of my rationale is that I never was of the opinion that whatever tool Iām using is inherently better than the alternatives, especially once new alternatives arise. Iām willing to try new things to see if they help my productivity in any way whatsoever.
One nice thing about modern editors is that they use CUA/HIG-compliant interfaces, so that migrating between them is relatively easy when compared to the random, unqiue, one-off, UIs of old editors like vim and emacs.
Fair point, but any modern editor will have decent keyboard shortcuts so that you can do the most common operations without using the mouse.
What languages do you code in and what size code bases? The fact that you need to jump through all sorts of hoops to set up things like code indexing and completion in vim whereas most modern editors and IDE pretty much offer it right out of the box is a big detriment to vim when working on large-enough code bases.
Iāve never needed these features. When I have developed in environments that had these features, they only got in the way and made life hell. Code bases large and small, no difference.
The thing people seem to forget about vim/emacs users is that we arenāt just using vim/emacs. If I had to do everything within vim, life would also be hell.
You see, right next to vim is this completely separate program called a terminal emulator. Itās got a very nice shell inside of it. It is thanks to that shell that I never need some GUI IDE. Vim just edits text. Thatās it. The shell is what really replaces the IDE features. Both emacs and vim users are using that same shell. The shell does everything the IDE can do, only harder, better, faster, and stronger.
Who needs code indexing when I have find and grep and I know how to use them?
Text editors just edit text. Itās really the shell that performs most of the features of an IDE, and thatās what we should really be comparing.
Most of my coding is in Java or Python, mostly building smaller tools or microservices. The biggest project I worked on in recent memory was a game engine with thousands of files, which was in C++.
I guess what I didnāt get across well is that when I say I use vim, I mean as a plugin for IDEs. Obviously I want to use IntelliJ or PyCharm to make life easier, and I do. I just install the vim plugin for each of those since I prefer it for in-document navigation/editing. I usually only use proper vim for editing config files or making small changes on servers.
Itās far from obvious. I donāt. Get that useless trash out of my face.
If you used Acme as your editor, Iād believe you (Acme lets you do some seriously insanely cool things with external tools like grep and friends). But you instead use vim. Meaning that you, as the human, need to do much of the work that the machine should be doing for you.
Iāll give you that find seems to run quicker than I imagined, so letās call it a wash there.
Now letās say Iām grepping through my entire code base for a function called āsendMessage()ā. Using my editorās index, it maybe took me 3 seconds. Letās see what grep does:
$ time grep -R 'sendMessage(' .
...
real 0m16.341s
--- ---
user 0m0.159s
sys 0m0.181s
So about 5 times longer.
Heck, even old-school vim users often use tools like cscope to perform indexes of code bases once they get beyond a certain size. At a previous job, we actually had cscope indexes regenerated as part of every nightly build to make things easier for our coders.
Oh, and Iāll need to manually call up the file in my editor if I use grep, whereas I can just go directly to it by hitting return using my IDEās index.
And letās not get into even more sophisticated searches that a proper code index, either built-in to the IDE or external, lets you do, like find every function that calls a particular function. Or how about searches that take a functionās argument types (admittedly not as useful if using a duck typing language like Python) into account? What if you want to rename a specific method of a specific class across your code base as part of doing some large-scale refactoring. Two mouse clicks or two keystrokes in my IDE and it searches the index, shows the list of changes that need to be made, and itās done if I approve of the changes. I suppose you would whip up something using awk and/or sed in the terminal to accomplish the same goal, but it wouldnāt give you a preview and would probably be a fair bit clunkier.
Getting outside the benefits of having some sort of index, how about running a static code checker, like clang-tidy, to inspect your code for syntax errors or potential security vulnerabilities and have the results appear inline with your source right in your editor? Stock vim canāt do that without a third party-plugin. My editor ships with support for clang-tidy (and even clang-tidy itself) right out of the box.
That isnāt to say I donāt also use the terminal where appropriate alongside my IDE. Different tools for different purposes and each with their own strengths. If I need to do a plain text search, Iāll often use grep because itās faster for searching for generic strings than an indexed code symbol.
Now, I get that some people think that IDEs are too heavyweight, and I respect that. You can still use a modern editor with a modern UI (like Visual Studio Code) alongside a terminal and get all the features you talk about with using find and grep without having a user interface designed for a 1970ās era dumb terminal over a 300 bps dialup modem link.
Your insistence that vim combined with the terminal as the end-all, be-all frankly looks to be a case of āif all you have is a hammerā mentality.
Puts on emacs wizard hat. 
Or just have the shells live in emacs. And thereās builtin commands for find and grep which make it easy to sift through the results. There are code indexing tools (ctags, etags, etc.), but Iāve never bothered to set them. Perhaps thereāll come a day.
The few times Iāve been forced to use an IDEāEclipse and IntelliJāwere a goddamn nightmare of getting my environment set up, having a build that works consistently, and managing the goddamn state of the IDE. Iām just amazed at how bad those experiences were. Xcode was ok.
Eclipse is a steaming pile. That goes without saying.
IntelliJās issues I think seems to be more related to Javaās issues than the IDEās itself. If you donāt have your classpaths set up right to the IDE it gets completely confused. I still like it better than any other Java IDE Iāve used once you get it to figure out your classpaths and other issues. which seem to be common to almost every Java IDE to one extent or another.
Interestingly enough, PyCharm and CLion, which use the same āengineā as IntelliJ, donāt seem to have the same problems, which is why I think IntelliJās setup issues are due to Javaās strangeness. PyCharm pretty much just needs to be pointed at the root folder of your Python project and seems to work just fine. CLion just needs a CMakeLists.txt file (and CMake is the closest thing there is to a standard, cross-platform C/C++ build tool right now) and if that file is set up right, it also just works. Even if you donāt use CMake, modifying the auto-generated CMakeLists.txt file it creates is pretty easy ā you basically just need to add your include paths to the beginning and it just works as well.
FWIW, it seems like any half-decent modern editor/IDE took a page out of Emacsā book and also has built-in shell windows. Oh, and ctags and friends, while not being quite as powerful as cscope, are pretty awesome and have certainly saved me time (and ctags also works with vim, btw, and actually doesnāt need any extra plugins, if I remember correctly).
Then again, I admit Iām a bit of weirdo in that I started on emacs, then switched to vim, then switched to a bunch of different other editors and IDEs over the years as I experimented to see which made me more productive.
Thatās your problem right there. You are doing grep -R ā¦ That is grepping every single file in your entire codebase, regardless of what kind of file it is.
My most common search is something like this:
find . -type f -name "*.file extension" | xargs grep "search query"
Even better if can narrow it down to just some subdirectory and not the entire codebase. I mean, I know the project Iām working on pretty well. I shouldnāt really need to search ALL of it that often. If you want an index, you can use locate instead of find, at least for the files themselves.
I also donāt understand the benefit of having the shell embedded in emacs or whatever other program. Whatās a window manager for then? Our computers can multitask. We donāt have Apple //. Why have one program with everything in it? This isnāt 1991 with Windows 3.0 with exactly one program maximized full screen.
Letās also discuss how every IDE has some kind of Git integration that is a steaming pile compared to just using CLI git as great satan intended. Any of those IDEs support interactive add, interactive rebase, bisect, or even just git stash? How do they work if you have multiple upstreams?
Here we go then:
$ time find . -type f -name '*.cpp' | xargs grep 'sendMessage('
...
real 0m18.739s
user 0m0.049s
sys 0m0.117s
Even slower this time!
Well, true, if you know the exact subdirectory, you can narrow it down, but again, youāre doing work that the computer should be doing for you. And what if you donāt know the exact subdirectory? What if youāre dealing with a massive codebase spread across multiple sub-projects and multiple teams? I can narrow things down pretty quickly if itās in my teamās sub-project, but not necessarily if itās in someone elseās.
Locate is better than find, true, if itās set up correctly, but it only indexes names, not symbols.
Shell in emacs dates to a time when people were running emacs on text-based terminals. Itās left in there because the emacs santas still like using it. To be fair, it does a lot of nice things that your stock xterm/gnome-terminal/terminator/konsole/etc. doesnāt do, so there are pros and cons with using it. Modern versions of emacs let you spawn the shell in a separate emacs window, so itās effectively the same as spawning a new xterm or whatever.
Oh, Iāve never use an IDEās built-in git client except for the simplest add/commit tasks. I always drop down to the command line (when I can use git ā we havenāt transitioned to it here yet for all but a few smaller stand-alone projects) to do anything more sophisticated than that. There are some stand-alone GUI git clients that are supposedly pretty decent, but I havenāt really pushed them either as, again, I havenāt used git on anything super big or serious as of yet.
git grep
Good lord how small are your code bases?!
I only use git grep if I have to grep files that arenāt actually present in the directory. Like if I want to grep upstream/something or HEAD^2 without checking it out.
Yeah, there definitely seems to be some kind of codebase measuring contest going on.
If your codebase is truly that enormous, you should probably be splitting that biz up. Iāve heard that Google puts the code of everything into one giant repo. Not sure if they still do that. Even if they did, you can still just stick to one directory. No reason to grep the code for Google Hangout when youāre working on Google Maps.
To be fair, Rymās employer is known throughout the C++ dev world for having a massive legacy C++ codebase, so itās hardly fair to compare it to anyone elseās shy of perhaps something like Googleās.
Itās still true, but no one copies the whole thing to their local machine or works with more than a tiny sliver of it on a day-to-day basis. The fact that itās logically a monolithic repo under the hood is mostly just incidental and is largely hidden by tooling.
Yep. Git apparently supports the idea of āsparse checkouts,ā so while you checkout the entire history, you only download whatever part of the tree you actually need to work on.