WARNING!, I am about to start ranting:

(rant)

There was a time when I was always using an IDE: Turbo C++, Visual C++, Visual Studio, IntelliJ, Eclipse (horrible). They were good tools, and I made good apps and got paid to do it. Then there were challenges in which I was forced to think outside of the IDE, and one of the challenges was build automation. I would need a server that checks out code, runs the compiler, runs the tests, and uploads the build. Even though I was editing the build script inside an IDE, it didn't serve its full purpose, it was merely there as a text editor. Not to mention I had to FTP the script back to the server. I thought of using an FTP plugin on my IDE. Nevertheless, it was still very incovenient. I wasn't proficient at ssh and scp, or vim. The whole process was arduous. It sucked, and I thought this was what being a sys admin was like.

Then I started learning vim, then tmux, then starting to understand the GNU toolchain, sed, awk, grep, piping output, and all the nix stuff. Then I started to understand why people do this.

An IDE is like the swiss-army knife, but bulkier. Imagine owning a 10-in-1 tool, and you sit there wielding the tool, but all you need is the screwdriver. IDE is great for that all-in-one development environment, but it's just that, a development environment. Sometimes you don't need the entire set of tools, you just need one.

To be fair, IDEs for languages that aren't strict and strongly typed kinda suck. Things like autocomplete/refactor work half the time (and if they do, they're barely useful) for dynamically or weakly typed languages, for understandable reasons.

So text editors that are able to provide powerful and language-agnostic features, pretty much dominate that kind of usage.

* Awk & Sed are great, I use them regularly.

* IDEs for weakly typed languages exist, and they are nice. Try webstorm for example.

* True, IDE build scripts are not as strong as cmake and make. When the time comes, you will have to add manual build steps with external programs.

* Refactoring over huge progams is possible, try "visual assist" for example. It does a decent job refactoring C++ code by hueristics (it does not compile your entire code).

I have used text editors several times (did some obscurely compiled embedded programming). During this project we had a heck of a time writing a low memory huffman compressor on an embedded device. I had the usual "I can do everything in a text editor without a debugger" guy on my team. After he failed implementing the algorithm for 3 weeks straight, I rewrote his code in 3 days, in VS, with a debugger. I did it by writing automatic tests, and debugging with an inline debugger on a giant PC. Then I ported the working code to the embedded environment. The port took ~1hr because the embedded device was missing some ISO-C syntax. The man was so in love with his *nix-fu that he couldn't bring himself to use a proper tool-chain. Over the years I have had several jobs, in each one I have encountered the "I don't need a good toolchain" attitude. At best it wastes time, at worst it kills projects.

I'm not saying there is an IDE for everything, just that when there are (and many times there are) they are usually better than text editing . It can take several days to find the correct tool for obscure environments. But one should spend that time.

I'd argue that VIM is that overly complicated pocketnife. As each language/environment usually has it's own "best-for-the-job" IDE. VIM should be thought of as a "use in case of emergency" tool (stuck on a plane to India for 10 hours).

After he failed implementing the algorithm for 3 weeks straight, I rewrote his code in 3 days

That's a strawman. There are just as high a percentage of shitty engineers using Visual Studio as there are using a unix-like toolchain. Your experience with a few shitty engineers who didn't use IDEs hardly generalises to the rest of the world.

I'm a little offended at you continued insistence that I don't use a debugger, or write unit tests, etc. just because I use a text editor. Turns out that pretty much any decent engineer does all of those things, regardless of what set of tools they prefer.

Refactoring is that one feature I miss from an IDE. Nothing beats a good refactoring tool, and I have yet to find one for vim.

I don't think you would benefit much from using vim only in cases of emergency. Vim control keys are so complicated that if you only use it in cases of emergency, you would forget them fast. You'd then find yourself having to google for simple commands.

Don't get me wrong, I still use an IDE. Not saying vim > *. I would use an IDE when developing mobile apps. But IDEs aren't the only tools for all development work either. There are plenty of cases where you'd need to step outside of that nice GUI environment, and use command line tools to get the job done.

I'm a little offended at you continued insistence that I don't use a debugger, or write unit tests, etc. just because I use a text editor. Turns out that pretty much any decent engineer does all of those things, regardless of what set of tools they prefer.

Not meaning to offend, but... When your code throws an exception, does editor magically jump to the correct piece of code (in C++) ? Are all of the current scope variables already laid out nicely on the screen for you? From the same view can you edit your code, and sometimes recompile it to run (depending on language/ide)? Does VIM let you browse recursively through the contents of STL containers?

That's what I mean by integrated debugging. Using GDB command-line works, but it is not as productive as having all of the information at your fingertips.

I'm pretty sure there is a script to setup Vim/Emacs to do someof these things, but I'm also pretty sure that most people don't set it up.

Reagrding tests: Can you write the tests first, and then magically use the inbuilt code refactoring tool to create your real classes/functions just from their signatures? (Not talking about an external script, I'm talking about pressing a short-cut key)

These are powerful tools that come with my IDEs (or with an added plugin).

Using GDB command-line works

There are many graphical debuggers not explicitly attached to an IDE. And the debugger integrated in your IDE is only useful insofar as the IDE can (a) build the software, and (b) connect to the target environment - both of which are sadly often not the case in my work.

I'm pretty sure there is a script to setup Vim/Emacs to do someof these things, but I'm also pretty sure that most people don't set it up.

And that group of people wouldn't happen to have any overlap with the group that continually denigrates the capabilities of non-IDE development tools, would it?

Can you write the tests first, and then magically use the inbuilt code refactoring tool to create your real classes/functions just from their signatures?

Again, this is something that I've seen work moderately well in C# or Java, and miserably to not-at-all in most other languages. Unit tests tend to vastly under-specify even interface contracts in most programming languages (do your units tests really enforce const correctness in C++, the final keyword in Java, or generics in just about any language?).

For all the people that are text editor only, what do you do for autocomplete? I am super lazy. Once I type in the name of a function I almost never completely type out again. Then other times when working with some third party API I know what I'm looking for but I don't know the name of the function so I get the intellisense to popup so I can scroll through the list to see what I'm looking for.

both of which are sadly often not the case in my work

Use GDB if you must. It saved my behind more than once. It's great that such a universal tool exists. Your environment might require it. But too often I have seen people using it because it's there, and "it's good for everything". But I've actually seen EMACs master debugging JAVA through command line. The reasoning behind this was: "I need nothing nothing more than EMACs and neither should you".

And that group of people wouldn't happen to have any overlap with the group that continually denigrates the capabilities of non-IDE development tools, would it?

Actually, no. The times I have observed this happening is when I asked sworn VIM users why they are debugging by hand, and got a "VIM could do this if I wanted it to" answer back.

Again, this is something that I've seen work moderately well in C# or Java, and miserably to not-at-all in most other languages. Unit tests tend to vastly under-specify even interface contracts in most programming languages (do your units tests really enforce const correctness in C++, the final keyword in Java, or generics in just about any language?).

As a programmer with a strong belief that unit tests are overrated, you will see that I did not write "unit" tests :-). I happen to agree with you on this point. However, automatic code writing tools make tests easier for me to write, and thus encourages me to write them. So in the cases where unit tests are useful: Algorithmic code with alot of edge cases. I am encouraged to write them by the IDE.

There has been a lot of good additional things to consider added to this post. Nice.

I think the main reason I am liking Brackets and LightTable, might be for the reason people first liked Vim.

I have been wanting an IDE that is not so cluttered with features I probably don't need. Eclipse is a nightmare for me, and so is Xcode (the screwdriver analogy).

However, I would like to compile code simply. These two programs are "like" text editors, but they are more than that also. I have installed python interpreters for both already.

I guess I understand why some would even go to prefer the terminal.

I think it is a matter of "tools for the job."

How often do you need to customize a hammer? But some jobs do require custom tools. Then you have swiss army knives, which if designed well enough, would prove very useful.

But If I want a hammer, and all I need is a hammer, then a swiss army knife would just be in the way.

In a way, I think the idea of having a system, and then being able to upgrade that system as your needs might require it, is the most efficient type of system.