0

Watching all those screencasts (and listening all those podcasts) with more-or-less famous hackers/programmers I hear that many of those use emacs/vi(m) for their daily work.

Now, I myself tried using both emacs and vim, and I honestly cannot understand why would anybody use these for any kind of serious development.

The most advertised feature is something along the lines of "you'll be able to work with text (meaning cutting, pasting, duplicating, moving, etc) up to ten times faster than with conventional IDEs", but I don't buy that. When has the success of a software project been defined by how fast a programmer can juggle lines in a text editor or by saving a couple of keystrokes here and there?

Plugins and extensions? I bet nothing comes close to R# or IDEA in terms of refactoring support ("Rename" refactoring implemented by means of "Search and Replace" is not a refactoring IMO); others are trivial.

Ubiquitous and available everywhere? So what? How often do you find yourself editing files over a 300 baud connection on an esoteric *nix installation without a VCS?

So here goes: do said editors have a justified place in a modern software development ecosystem?

Anton Gogolev
  • 1,447
  • 2
  • 15
  • 23
  • 1
    I can't speak for Emacs, but I find Vi(m) is a great editor - in terms of editing commands, navigation, search, *speed* of use, etc.... It might not have some of the more advanced capabilities of modern IDEs, but then there's projects like this: http://eclim.org/ I also did a quick search and found refactoring plugins for Vim: http://code.google.com/p/lh-vim/wiki/lhRefactor In my experience, this type of functionality is often provided by plug-ins rather than as out-of-the-box feature. Emacs probably has similar plugins. – FrustratedWithFormsDesigner Aug 27 '12 at 18:54
  • @FrustratedWithFormsDesigner : Oh dear ( http://vim.wikia.com/wiki/Vim_as_a_refactoring_tool_and_some_examples_in_C_sharp ): "Now I have time to think what parameters the method needs and what to return."... If _that's_ a refactoring, than I don't know what isn't – Anton Gogolev Aug 27 '12 at 18:56
  • 1
    You're free to write a better plugin, if you don't like what's out there! ;) – FrustratedWithFormsDesigner Aug 27 '12 at 18:58
  • I've personally never bought the "faster = more productive" line, because I find that the bottleneck with productivity isn't text manipulation speed. It always comes down to reasoning, testing, debugging, etc. Granted, it's nice to have the ability to be more expressive and flexible with your text manipulation, but the notion that it makes all the difference in the end always struck me as hollow. – KChaloux Aug 27 '12 at 19:20
  • vim/emacs have exceedingly steep learning curves. But once you push past that they become excellent development environments. It is not just the cut/paste speed. But the ability to move through the source and examine code none of the IDE's out there even come close in terms of navigation. From a dedicated vim user working in an office where most people use vim or emacs even given the choice of any IDE we want. – Martin York Aug 27 '12 at 20:33
  • 2
    What language are you writing for Anton? If you're writing Delphi then I don't think VIM is going to help you. If you're writing a C# app, maybe you're better off in Visual Studio. Java? Maybe stay in Eclipse. But for many languages, like C, Perl, Python, etc, people report they are more productive in a text-only editor (like VIM or EMACS). – Warren P Aug 27 '12 at 20:52

8 Answers8

18

The interesting thing about Vim and Emacs is not simply how quickly you can work. It's the simple fact that Vim and Emacs let you edit your text at nearly the speed with which you think about making your changes. Since you have no need to make selections, to switch to the mouse, or to hunt through menus, your mind is free to focus on what's important while you edit: Your code.

This is to say that when you're writing code, there is only one thing you want to think about: What your code must do and how it must do it. Whenever you stop to make changes to code you've written, it's an interruption; you're forced to think not about what your code is doing but how to make the changes that are necessary. So, instead of stepping back and make a visual selection and changing my mode of thought from code-writing to text-editing, Vim and Emacs allow me to perform the edit and be done with it, without having to expend more mental energy on the task of making the change.

And when you take your hand off the keyboard to grab the mouse, it's another kind of context switch: You're no longer thinking about the code, but about the text you can see on the screen and the visual elements that surround your editing area. Then, you must make the switch back to writing code, as your hand hunts for the home keys. With Vim or Emacs, this context switch never needs to be done, and your mind never needs to leave the task at hand: that of writing code.

A lot of people, myself included, use Vim or Emacs as their preferred tools because they're liberating in the sense that you spend less time thinking about editing and more about what changes you're making. Because, really, what is programming but juggling lines of text?

Plugins and extensions? I bet nothing comes close to R# or IDEA in terms of refactoring support [...]

These kinds of tools exist. Tips and methods abound. The only limit to Vim and Emacs is that their primary purpose is editing text. But that still doesn't stop anyone from making it the umbrella under which their entire IDE is built.

I think the source of your consternation is that you choose not to see value in Vim and Emacs. That's fine. I'm not going to try to convert you.

But I will say that having tried every text editor and IDE I've come across, I still go back to Vim. I'm comfortable with it, I'm happy with the tools it gives me, and my Linux desktop meets my every need as an IDE, all in the terminal window. It has made me dependent on Vim's peculiar command structure, but because Vim runs everywhere, that has never been a hindrance; only a boon.

greyfade
  • 11,103
  • 2
  • 40
  • 43
  • 2
    Again: do you really find the speed at which you're editing text a limiting factor? – Anton Gogolev Aug 27 '12 at 19:07
  • 9
    It's not about banging out 120wpm, it's about expending less mental energy switching between keyboard and mouse contexts to perform edits. – leo Aug 27 '12 at 19:22
  • 8
    @AntonGogolev it is not the speed of editting text that greyfade talks about, it's the decrease of interruptions to your train of thought. More disruptions lead to more errors. More disruptions lead to more strain in buffering ideas as your input catches up with your brain. More disruptions mean more mental cycles spent on clicking on the right box rather than using muscle memory to "find/replace X with Y on this line". I don't _agree_ with the argument (for me), but it's certainly understandable. – Telastyn Aug 27 '12 at 19:26
  • 12
    You never truly understand the hindrance of the mouse until you learn to work without it – Drake Clarris Aug 27 '12 at 19:27
  • 2
    @AntonGogolev As the others have said, no, that's not it at all. This is absolutely about how much mental energy you expend on editing. With Vim's editing shortcuts, I don't have to stop and decide how to edit/delete/move text, I can simply do it in about the amount of time it takes to make that decision. That frees me to think about my code and not worry about silly things like hunting through menus looking for something. Speed has nothing to do with it beyond the interruptions I can avoid. – greyfade Aug 27 '12 at 20:13
  • 3
    I wouldn't even call what people in VIM do "merely typing or editing", I'd say they execute "transforms" on their code. – Warren P Aug 27 '12 at 20:50
13

Two points. First, it's not the typing throughput that makes a difference, it's the latency. In other words, the elapsed time between when you've decided to make an edit and when you're done making the edit and back thinking about the problem. A couple of seconds can make the difference between losing your train of thought or not.

Take something simple like swapping two lines of code, for example. An experienced vim user can do that essentially from muscle memory with ddp. You use more mental capacity than is apparent when you have to precisely maneuver a mouse, make sure everything you want is selected, hit ctrlx, up arrow, ctrlv, and then make sure you included the line break and everything is still indented correctly. It's like texting and driving. You think you're paying better attention to the road than you really are. I prefer to keep my mind on the problem.

Second, nothing precludes a vim user from using an IDE when it suits him. There's a reason why almost every IDE has an option to specify a custom editor. I quite frequently use an IDE for navigating and debugging, and vim for editing.

Karl Bielefeldt
  • 146,727
  • 38
  • 279
  • 479
  • 1
    This is not a fair comparison. On any decent IDE, swapping lines in `alt+down`, and will take care of identation for you. Even in notepad it's `Shift-Home``Left``Ctrl-X`,`Down-right`,`Ctrl-V`. No need for the mouse. – Elazar Leibovich Aug 28 '12 at 06:35
8

The linux command line is the ultimate integrated development environment; vim and emacs seamlessly interpolate with the unix toolbox to create a streamlined development environment that really has no equal.

leo
  • 1,198
  • 1
  • 9
  • 14
6

I bet nothing comes close to R# or IDEA in terms of refactoring support ("Rename" refactoring implemented by means of "Search and Replace" is not a refactoring IMO); others are trivial.

Not all code is nicely statically typed or in a language that allows good tooling (refactor, find references, auto-complete, etc) support. These editors still have strong arguments for them when working with these languages.

They also work well with build scripts, config files, log files, and other shrapnel that needs to be built/analyzed/grep'd/coddled/tweaked on (often CLI only) *nix environments, which still make up a sizable portion of production code platforms.

Telastyn
  • 108,850
  • 29
  • 239
  • 365
  • 3
    This is an excellent point. Your IDE may be good at one, maybe even two things. I have yet to meet the IDE that is worth configuring for every type of file I edit. When I take a quick whack at a PHP file I am not going to waste time configuring an IDE for PHP. – Zan Lynx Aug 27 '12 at 19:32
4

Do said editors have a justified place in a modern software development ecosystem?

Yes.

1) If there is no good IDE for the programming language you work with (which is most of them, really).

2) If the IDE can't handle the size of your project.

3) For various tasks when you just want to change a text file quickly without waiting for an IDE to open and initialize.

Nemanja Trifunovic
  • 6,815
  • 1
  • 26
  • 34
  • Also, for some languages, the good IDE *is* Emacs. I've found this particularly true for the more functional languages like OCaml, Haskell, Scala and various Lisps. – Tikhon Jelvis Aug 28 '12 at 05:55
2

I find them useful for quickly editing a configuration file on some system (possibly production), that I only have terminal access to. I would never use it for actually developing software because of how sophisticated IDEs are today.

I never really understood why people even bother talking about optimizing typing speed, as if that's the bottleneck in development or something. It's not even close to the time I save from using an IDE.

Also, how does does switching from keyboard to mouse break your train of thought?

Once you set up your IDE you almost never have to worry about any configuration. It's not like you're constantly wasting time figuring out how to do something IDE-related.

Oleksi
  • 11,874
  • 2
  • 53
  • 54
  • 2
    The IDEs are SOOOOO sophisticated that you can get lost in trying to figure out why the indentation settings are different in the editor window for resolving SVN conflicts than the window for editing C++ code. After five minutes you could have spent coding you finally figure out there's no way to do it an then spend extra time replacing tabs with spaces manually. – Zan Lynx Aug 27 '12 at 19:36
  • vim pretty much does it all. *Most* IDEs are lacking when compared to vim/unix, but it's true that some IDEs targeting specific languages boast some unique features. – leo Aug 27 '12 at 19:49
  • 1
    @ZanLynx you figure it once. If I used vim, I'd spend those same five minutes figuring how to execute some obtuse keyboard shortcut. Once your IDE is configured, I find that you rarely need to look at it again – Oleksi Aug 27 '12 at 20:19
  • 2
    @Oleksi: If you invested the same time in learning vim you can use it to edit any text file. With the IDE you can edit, oooh, C++ or C#. Or maybe Java. If you want to edit Ruby, Python, Haskell, Ocaml or Apache config files you are out of luck. – Zan Lynx Aug 27 '12 at 20:34
2

Intellisense/refactoring support is really the only compelling features for IDEs today. I expect in the future pluggable libraries will be created to provide intellisense/refactoring for various languages, so one can have the same level of language support in Emacs/Vim as in IDEs. (For some languages such libraries exist already.) If it happens then Emacs/Vim will be the preferred development tool for a number of developers, because they provide a different experience than an IDE (leaner, quicker, simpler, etc.).

Tom
  • 131
  • 1
  • 1
    Vim can have an intellisense-like code completion facility. And, in fact, it does for some languages. It relies heavily on regular expressions or tools like `ctags` and `cscope`, but with the help of static analyzers like `clang` for C and C++, it can get the feature for more complex language grammars. (See [clang-complete](http://www.vim.org/scripts/script.php?script_id=3302).) – greyfade Aug 27 '12 at 20:38
  • I meant proper intellisense which actually understands the language, and does not rely on regular expressions. Clang is a good example for the libraries I was talking about. Hopefully we'll have something similar for Java and other languages too. For Java the best solution would be to separate the language parsing module in Eclipse, so it's not tied to the GUI and it can be used by other editors too. – Tom Aug 28 '12 at 05:13
2

I personally feel like that coding in vim has helped my coding ability, much the same way that learning to properly handle memory and pointers in C or learning functional languages like Haskell has helped me to grow as a programmer. It is much easier to understand and be able to effectively utilize something at the higher level when you understand how to handle it at a lower level.

Drake Clarris
  • 401
  • 3
  • 9