How to wean oneself from IDE to text editor?

问题

I've been using IDE's for various languages over the years (VS, IntelliJ, Eclipse, NetBeans, FlashDevelop, etc), and i've always found them slow and cluttered (yes i know windows can be hidden, rearranged and what not). Recently however i've learned and become somewhat proficient with VIM and have been using it for as many projects as possible.

My problem is i've grown quite attached to the various features that the IDE's provide (intellisense, refactoring, embedded docs, the list goes on). Does anyone have any advice for how i can overcome these crutches and become truly IDE free?

回答1:

I don't understand why you would want to become IDE free? Why is programming like they did 20 years ago a virtue? It sounds like you just want to do this because that's what all the "uber" programmers do. Intellisense, refactoring, etc. are all tremendous evolutions that increase productivity. Our job is hard enough modeling complex business problems, why do you want to make that harder with an inferior development environment?

回答2:

If you are using Windows then there's definitely no point in switching to VIM. In UNIX/Linux however, the shell IS the IDE.

The most important point to get is that VIM is just the text editor. Don't do everything in it.

1. Your shell (BASH, etc.) is for managing files and directories.

   • You can't beat the shell integration you get with SVN/CVS/Git/etc.

2. Window management can be done with GNU Screen or using BASH job control (^Z, fg, bg)

3. intellisense is available for VIM/Emacs, but never under-estimate the power of just the built-in auto-completion.

   • Does intellisense auto-complete column names in query strings?

4. The most advanced refactoring tools in most IDEs are child's play compared to what I can do with keyboard macros in Emacs.

5. embedded docs: If you are doing C/Perl programming then the available man pages are usually sufficient.

   • Making a macro to look up the function under the cursor is easy.

回答3:

Some quick tips that have worked for me

• memorize the entire API space I'm working in
• use console output debugging
• use search and replace for rename-refactorings
• count braces, parens by hand to make sure they match

回答4:

@Jason Miesionczek: I hope you realize that using a text editor is a great way to learn the nuts and bolts and moving parts needed to actually compile something useful - but it's no way to be productive. As you imply in your question - Intellisense, refactoring, and other automation is really helpful - so don't give these features up just because they "hide" certain mechanisms.

Farmers use tractors - not because farmers don't know how to till the soil - but because time is money.

@everyone else: I think the OP already clarified that he wants to know how he can overcome the IDE's ability to "hide" the mechanisms behind coding and building apps. I think this is a valid point, especially for Microsoft products - because there is SO MUCH automation going on, that sometimes I don't even know which files need to be checked in to source control...

So in response, I think if you really don't want to use an IDE, I think it's pretty clear that a text editor and documentation are ALL you have. You can build or find utilities to help you recover some of the nice features you had with an IDE, but at that point - you are building an IDE!

回答5:

I don't see a point in going extreme either way. I use a combination of find, grep and vim for most of my production troubleshooting efforts but when I need to work on coding new classes from scratch, I'd use an IDE still. It just makes sense as I have no use for remembering things that an IDE can easily do for me.

回答6:

The best way is to view the IDE as training wheels. When you can anticipate everything it's going to hint and autocomplete for you, then you can start trying it on your own.

Probably the biggest incentive will be how much more quickly things will happen when you start up the editor. :) At least my experience with IDEs is that they sell a lot of hardware.

回答7:

You can use a modular system like JEdit or Emacs. These programs are text editors, but are extensible to nearly a full IDE style application. Get it set up the way that feels the most comfortable, then start removing extensions you think you can do without, one by one.

However, don't think that IDEs are completely unnecessary they are a very good tool to use in many cases.

回答8:

Jason, here's the thing: learning VI will take you years. And once you learn it, you'll have at your fingertips an immense and addictive power you never thought possible. However, it's a power that not everyone necessarily wants or needs.

If you plan to program for a while, because it's a good job, with good pay -- and then hopefully get promoted to manager or something or start your own business, go ahead and use the IDE. It's fine. Plenty of people do this and there's absolutely nothing wrong with it. If that is your career path, you don't have time to really learn VI, and you shouldn't bother.

On the other hand, if you actually really LOVE programming -- if programming is something you are passionate about and that you would do for free even if nobody paid you -- and you plan to program for your whole entire life until your fingers don't work anymore -- then learn VI.

There are VI scripts that you can download that give you intellisense, refactoring, etc. But IMO, by far the biggest win with VI is the ability to record and play back macros.

Macros give you wings, like Red Bull. The types of motions that you make to edit the text might seem odd when you first learn them, but when you start to fit them together into sequences and play back those sequences as macros, you will begin to understand that those strange keystrokes (capital A to position the cursor at the end of the line of text -- 0 to position it at the beginning -- w to skip a word -- etc) are like little cog-like Anime robots that can assemble themselves into a giant Transformer beast that can decimate any text-transforming problem you throw at it.

I can't tell you how many times someone gave me a file with messed up formatting or something and they thought I would have to write a program to fix it and I just opened up VI, typed in some macros, and fixed it right in my editor. I've had people watch over my shoulder and ooh and ahh about this -- and I don't say this to brag or to say that I get satisfaction out of that, but I'm just trying to impress upon you that VI itself is a powerful and impressive platform.

Add to that that you are using a tool that has continuously been improved and tweaked and fixed and debugged and added to for more than 30 years, and you've got something really special.

You get out of it what you put into it. This is true across all realms of human endeavor and it's true here. Put the time and effort into learning VI, and you'll find yourself in a world of efficient coding you didn't even know existed.

p.s. I forgot to mention one other thing -- what happens when language X, the one you are programming in, goes out of style? Time to learn another IDE. Unless you know VI, in which case, your old friend is still with you.

回答9:

The various features that IDEs provide are not crutches. Giving those features up are what would be crippling.

Not to say that you can't be a good programmer without using an IDE, but given two identical programmers, the one using a high quality IDE will wipe the floor with the other.

回答10:

I have purchased viEmu for Visual Studio, and I use jVi for NetBeans. There's also a vim plugin for Eclipse but I stopped using it because it lagged on my computer and sometimes missed my keystrokes, which got very unproductive. By doing this, I don't have to choose between vim and an IDE. The vim plugins are emulators and so aren't perfect, but they've got all the most important functions I find.

回答11:

What it sounds like to me is that you are disatisfied with the speed of IDEs, and you want something as fast as a text editor (with the low memory footprint) but can still be productive.

Ignoring the question of if this is worthwhile (that can only be ascertained by productivity comparisons which really vary from person to person, and can vary depending on the team, as well as the language), here are some ideas for making it work:

Use a text editor with syntax highlighting. These are commonly available (like Notepad++) and do not slow things down. Because they are regex based they are only 95+% accurate, but good enough.

Next, look for the capability of scripting chunks of code. For Java, there would be BeanShell, or perhaps favor a language like Ruby or Python which have that inherently, and develop/look for macros which let you select a chunk of text and pass it to the script runner (to quickly check syntax when you are not sure). Depending on the language, it may also be fairly trivial to get a macro which selects an API call and figures out how to open the documentation in a browser window.

To really be productive, though, you will need to really know your API and your text editor very well, and develop a lot of muscle memory, and be fast at developing little macros to do redundant tasks.

It's not my cup of tea, but the people I have seen who are productive that way follow that kind of path.

回答12:

I guess you seem to be asking "what does an IDE do for me?" and "what are alternative to [bloated IDE of choice]?" and "How can I learn how an IDE does these things?"

So.

1. vim does a lot of neat things besides 'editing'. vim will do auto-indent (==), and some autocomplete (ctrl-P). When churning out code, that's what you're doing right there.

2. You can write your build scripts by hand. Not that that is a particularly efficient way to do it, but you gain a huge appreciation for what eclipse does in the background. Also, you will have full control of dependencies, and know exactly how the build process works. No more "I can't even build it without netbeans!"

3. Which means, learn either make or one of the java build-script-things (ant?) You can definitely write java buildscripts in make, and makes pretty darn useful anyway.

4. If you are writing C code, indent is a pretty useful tool - though vim's pretty-printing is often good enough.

5. Learn grep for searching through files (especially the -n, -R, and --color options!) As an added bonus, you'll start learning regex.

回答13:

The pragmatic programmer has a good section on text editing that hits home for me. The core principle is that once you learn a powerful (and extensible) editor then you can slice and dice code with efficiency, very little effort, and without regard for language you happen to be working with at the time.

A good IDE can be a good editor providing that it supports the various languages and text formats you routinely edit.

On that note I'm a bit disappointed that Visual Studio doesn't have built-in support for file types such as .ini, .cmd, .bat, .reg, and so on. seems like this would be trivial to add and would make developers more likely to rely on that editor for everything.

(aside: this is very different from relying on an IDE as a crutch. every developer should understand every bit of code in their project and not rely on wizardry.)

回答14:

I guess the question would be 'why?'.

I tend to not use IDEs when I am trying to learn a new language. Right now I am using gedit to learn C but even with that I use line and bracket highlighting, auto-tab, and syntax highlighting + some custom build/run scripts.

Use an IDE when your programming is a means to an end. The purpose of an IDE is to speed up your work.

Use a simple text editor when your programming is the end itself.

回答15:

How to wean yourself off? I believe that it all starts with a good build script. Knowing how to make a build, FAST, from the command line is key. This is one place where IDEs hold you back. If you're not doing your own builds, and you're letting the IDE autogen it all for you, you're missing out on a lot of flexibility.

So instead of memorizing the API space, learn the build language and how to run the compiler and linker the way you want. Keep using your IDE to edit. Then, as you get comfy with that, you can switch to whatever editor you like without much friction. But IMO if you start editing in another editor, but use the IDE to do your builds, you'll be a lot worse off, especially if you do end up deciding that the IDE is good for something after all!

回答16:

Install emacs and don't look back.

回答17:

This is Mac OS X specific, but I love TextMate. It's a text editor with "half-auto-completion" and a number of shortcuts to docs etc. So you can get some help if you want it, but it's still a text editor.

回答18:

I don't recommend you to quit IDEs. Going from IDE to notepad can be quite painful (you will miss Intellisense and breakpoints A LOT). The only way to abandon IDEs is to uninstall them and start with notepad. Again: I don't recommend it. IDEs are designed for making you more productive and they use to do those boring tasks we don't want to do (creating the code for a blank form, the events for a button, etc).

I use Notepad for writting little dlls in C++ and... oh! I really miss Intellisense and a lovely IDE that corrects my syntax errors...

回答19:

Editors? IDEs? Real programmers use butterflies. src

回答20:

You could probably get a lot of the features of an IDE in VIM if you learn how to configure it correctly. But ultimately, the question is WHY would you want to do that? Why mess with configuration for each project, when you have something working that is much easier in an IDE already. I think time would be much better spent learning whatever language you use, than learning how to use a text editor, powerful as it may be.

回答21:

I personally use emacs as my editor, and then the tools of my OS to do the rest.

On Linux, I always use the shell to do everything. manpages for documentation (oh how I miss these when coding on Windows), grep to... er, "grep" files, scripts to do useful things, etc.

Try to find external tools that do the jobs that you want VIM to do, that your bloated IDE did for you. Modular is good.

回答22:

Buy a 2nd monitor.

回答23:

You can use both the IDE and the text editor.

The IDE for refactoring, documentation, search, usage, build tool integration, seamless different tech transition (yea, idea), tasks/issue integration, time tracking integration, code/libraries experimentation.

The text for... well.. whatever else makes you happy, and for cases when you don't have the IDE, such as ssh command line, test/integration machine (this is when you want to have the build tool at hand, and don't rely on the IDE for build tasks).

回答24:

I thought Visual Studio 2K5 and 2K8 felt slow and "bloated" until I upgraded to a midrange SSD drive.

After making sure you have plenty of RAM, putting your IDE on a speedy disk drive is often one of the best performance upgrades you can make - perhaps even moreso than CPU speed. See: http://weblogs.asp.net/scottgu/archive/2007/11/01/tip-trick-hard-drive-speed-and-visual-studio-performance.aspx

After upgrading to a SSD and making a few SSD-related tweaks to Windows, Visual Studio 2005 loads about as quickly as a text editor for me on a 2.4ghz Core 2 Duo laptop.

Should we have to buy an expensive disk drive just to run a "modern" IDE in a responsive manner, when the uber-3l337 UN1x c0derz happily run EMACS on 386s with 32MB of RAM? Well, there's no doubting that plenty of coders are extremely productive without IDEs, many moreso than IDE jockeys. More power to them. But if you prefer to use an IDE and coding is how you make a living, should a few hundred dollars should be a dealbreaker? Up to you to decide, but worth considering, I think.

来源：https://stackoverflow.com/questions/1085165/how-to-wean-oneself-from-ide-to-text-editor