The thread formerly known as "Weekend Coding"


#101

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.


#102

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.


#103

image

But Black Dynamite. I use vim in the community.


#104

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.


#105

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.


#106

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.


#107

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.


#108

It’s far from obvious. I don’t. Get that useless trash out of my face.


#109

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.


#110

Puts on emacs wizard hat. :mage: 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.


#111

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.


#112

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?


#113

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.


#114

git grep


#115

Good lord how small are your code bases?!


#116

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.


#117

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.


#118

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.


#119

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.


#120

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.