6 ms·

For quick little tasks, writing blog posts, or system administration, Emacs or VIM or Sublime all work fine. For most professional software engineers, reading

by codex 13y ago

For quick little tasks, writing blog posts, or system administration, Emacs or VIM or Sublime all work fine. For most professional software engineers, reading code and thinking take up 80% of the job; typing the changes takes up about five percent. For these professionals, I've found that a modern IDE with good code browsing features will save the most time, overall. Jetbrains' products, SlickEdit, or Eclipse come to mind.

tikhonj 13y ago
This seems to be the conventional wisdom, but as with most such things it's more conventional than wise. Once I thoroughly understood Emacs, I found it significantly better for navigation even through languages like Java. A combination of ido-mode and dired make it incredibly fast to go through the directory structure of any project. It's also really easy to open a shell wherever i am visiting at the moment--including remote directories!--which I've found incredibly useful. Once I'm in a file, there are a whole ton of movement commands in Emacs that make teleporting around natural. Just one example that seems hard to duplicate in an IDE is the mark: in the course of normal editing, you often set the mark to do things like highlight regions of code. Then, later on, you can cycle back through your old marks, which takes you back through the parts of the file that you were active in. It's like bookmarking a line in the file, except much more lightweight--it happens in the natural flow of working on a file. This is just one example of many very productive features. Another great example is rgrep. This command lets you search through files in a directory. However, the really cool thing is how it displays the results: you get the filename and the line where the match happened. You can go to the file directly or actually edit it in place in the rgrep results buffer! It's very nice for certain tasks. Really, Emacs is full of incredibly well thought-out productivity boosters for everything you will do while managing software. Moreover, it is not limited to language agnostic things. If your want Eclipse-like Java support, you can have it with eclim, which actually uses Eclipse as its backend. I also know of great IDE-like support not based on Eclipse for all sorts of languages from Python through OCaml. Now, Emacs does have a learning curve. It will take a bit of effort to get good with it. It will probably require changing your entire workflow to take advantage of all the awesomeness. But it's more than worth the time investment: getting comfortable with Emacs is an O(1) action where the benefits it confers are a significant O(n) (if not better!) bonus. The more you program, the more you'll gain. Learning Emacs gives you significant gains even if most of your job involves browsing around and editing existing code.
- mtdewcmu 13y ago
  The investment in learning any powerful editor would probably follow a power law, since you'd be continually learning new things. You could keep it to O(1) by choosing some subset and refusing to learn anything more. But the expectation is that time spent learning more than pays off over time.
  - mheathr 13y ago
    The analogy of Emacs learning curve being a fractal is quite appropriate I think if we take each fractal to represent an amount of time required to gain proficiency in modes that introduce significant amounts of features, with the smaller fractals representing modes that require less time to learn. That sounds like chaos, but it captures Emacs platform nature and diversity of functionality well and seems true thus far as Emacs replaces more and more tools.
- codex 13y ago
  Don't get too excited about these sophomoric features. All modern IDEs have copied the best features from various editors. You can get the kill ring and set mark in IntelliJ, for example, and various other things besides. These features are all simple hacks from twenty years ago. What's really difficult is putting in the elbow grease to polish the environment to a shine of high productivity, which is where buying a commercial IDE is a win. Code completion works better. Refactoring works better. Fuzzy completion works better. The keyboard shortcuts won't put you in the hospital. But mainly, code browsing in large, complex code bases works better. It's really hard for people to look around and realize that times have changed, and change with them. People learn one thing and then their ways are set. It's up to the next generation to move things forward.
  - mtdewcmu 13y ago
    A lot of programmers would like to keep it simple and fast. IDEs tend to be slow, and crash, and have extremely cluttered UIs. All the "polish" that went into designing the environment means that you can't change what you don't like about it.
  - 13y ago

by codex 13y ago

tikhonj 13y ago

This seems to be the conventional wisdom, but as with most such things it's more conventional than wise. Once I thoroughly understood Emacs, I found it significantly better for navigation even through languages like Java. A combination of ido-mode and dired make it incredibly fast to go through the directory structure of any project. It's also really easy to open a shell wherever i am visiting at the moment--including remote directories!--which I've found incredibly useful. Once I'm in a file, there are a whole ton of movement commands in Emacs that make teleporting around natural. Just one example that seems hard to duplicate in an IDE is the mark: in the course of normal editing, you often set the mark to do things like highlight regions of code. Then, later on, you can cycle back through your old marks, which takes you back through the parts of the file that you were active in. It's like bookmarking a line in the file, except much more lightweight--it happens in the natural flow of working on a file. This is just one example of many very productive features. Another great example is rgrep. This command lets you search through files in a directory. However, the really cool thing is how it displays the results: you get the filename and the line where the match happened. You can go to the file directly or actually edit it in place in the rgrep results buffer! It's very nice for certain tasks. Really, Emacs is full of incredibly well thought-out productivity boosters for everything you will do while managing software. Moreover, it is not limited to language agnostic things. If your want Eclipse-like Java support, you can have it with eclim, which actually uses Eclipse as its backend. I also know of great IDE-like support not based on Eclipse for all sorts of languages from Python through OCaml. Now, Emacs does have a learning curve. It will take a bit of effort to get good with it. It will probably require changing your entire workflow to take advantage of all the awesomeness. But it's more than worth the time investment: getting comfortable with Emacs is an O(1) action where the benefits it confers are a significant O(n) (if not better!) bonus. The more you program, the more you'll gain. Learning Emacs gives you significant gains even if most of your job involves browsing around and editing existing code.

mtdewcmu 13y ago
The investment in learning any powerful editor would probably follow a power law, since you'd be continually learning new things. You could keep it to O(1) by choosing some subset and refusing to learn anything more. But the expectation is that time spent learning more than pays off over time.
- mheathr 13y ago
  The analogy of Emacs learning curve being a fractal is quite appropriate I think if we take each fractal to represent an amount of time required to gain proficiency in modes that introduce significant amounts of features, with the smaller fractals representing modes that require less time to learn. That sounds like chaos, but it captures Emacs platform nature and diversity of functionality well and seems true thus far as Emacs replaces more and more tools.
codex 13y ago
Don't get too excited about these sophomoric features. All modern IDEs have copied the best features from various editors. You can get the kill ring and set mark in IntelliJ, for example, and various other things besides. These features are all simple hacks from twenty years ago. What's really difficult is putting in the elbow grease to polish the environment to a shine of high productivity, which is where buying a commercial IDE is a win. Code completion works better. Refactoring works better. Fuzzy completion works better. The keyboard shortcuts won't put you in the hospital. But mainly, code browsing in large, complex code bases works better. It's really hard for people to look around and realize that times have changed, and change with them. People learn one thing and then their ways are set. It's up to the next generation to move things forward.
- mtdewcmu 13y ago
  A lot of programmers would like to keep it simple and fast. IDEs tend to be slow, and crash, and have extremely cluttered UIs. All the "polish" that went into designing the environment means that you can't change what you don't like about it.
- 13y ago