3 ms·
I'm still having trouble seeing the value of an IDE. When programming, all I'm doing is editing text and occasionally running an external program. what does an
by greyfade 15y ago
I'm still having trouble seeing the value of an IDE.
When programming, all I'm doing is editing text and occasionally running an external program. what does an IDE have that makes it so valuable?
(Honest question! I've used IDEs in the past - MSVC, Eclipse, NetBeans, Anjuta, Code::Blocks, and several others - and found that the generally poor editors made it more difficult to program.)
- BHSPitMonkey 15y agoFor one, they provide a way to stay immersed in all aspects of your project continually while switching around between tasks (seeing your files/class tree + code + warnings/errors + status simultaneously on one screen). Even if you're savvy enough to achieve some of this through a careful terminal splitting/tiling setup, you're just halfway-implementing a graphical interface. Like most GUIs, you're also provided with organized menu-based access to tools and features you might otherwise have to spend time remembering or learning how to do from a terminal. Finally, IDE-centric features like in-editor static analysis / error highlighting can come in handy from time to time (Oops! Forgot a paren. Glad I didn't have to waste 15 seconds attempting to build, reading/understanding the error output, and coming back to this file/line). (I agree that a lot of IDEs I've tried such as MSVC and Eclipse can be burdensome to use. I like using Geany, since it's foremost an editor, with useful panes and functionality added in.)
- tikhonj 15y agoEmacs also lets you stay immersed in all aspects of your project at once. However, unlike a GUI, using different panes in Emacs is uniform: the commands you use to get around the file/tree view are the same commands you use to get around your code are the same commands you use to get around your compiler output. Emacs also provides some really nice technology for finding commands including ido-mode and C-h m (which lists commands for the current mode and is incredibly useful). However, here the real magic is that getting around a help buffer is again the same as navigating code--you can use the same command to search and the same commands to move around. Emacs also has a nice system for integrating arbitrary output from an external process into your code, letting you have error highlighting and static analysis for arbitrary languages. On top of this, it has several really nice modes like js-2 and SLIME that create an even more compelling experience for certain languages. On top of this, Emacs has a bunch of really nice features like TRAMP which lets you visit arbitrary remote files and even open remote shells trivially. On top of this, it is much easier to extend than any IDE or even any other editor I have ever seen. So really, Emacs can provide everything you want, it can provide it in a much more consistent UI and it is infinitely configurable.
- greyfade 15y agoWell, with the exception of a class tree (which I've had trouble using in the past), those are all the reasons I just use a text editor. So, I guess I still don't understand. You see, I have file/project trees, warning/error buffers, build status and shells (among other things) in Vim and Emacs with keyboard-driven access to all the tools I use, without having to hunt through a twisty passage of menus, all alike. Even static analysis and error highlighting is available (even for C++ with vim-clang-complete, for example). So I guess what I don't understand is why there is a need for all of this to be "integrated" in a WIMP-style GUI.
- thurn 15y agoI find them most valuable in a larger codebase. The project I work on at Google is millions of lines of Java. I'm an Emacs user by preference, but a lot of my job isn't writing code, it's discovering and using the existing abstractions. For that part of my job, Eclipse serves my needs a lot better.
- HalibetLector 15y agoI've been told by IDE users that a large part of why they use IDEs is just how much work it can do for you without you having to think about it. Need to change a class name that gets referenced hundreds of places throughout a project? Project-wide search and replace! Can't figure out what the string of 4 integer parameters to a function are? Just hover over it with a mouse and the IDE will tell you! Some IDEs even go so far as to create code for you using templates. And then there's always interactive debugging. But, all this wonder comes with a price. For me, the key reasons I prefer vim to any ide out there is: 1) speed. compared to vim + bash, every ide is slow. 2) code portability. I work with lots of different languages on a daily basis and having to switch from Eclipse (java) to Monodevelop (C#) to whatever the http/css/php du jour is these days. 3) IDE maintenance. No matter what you use, ides have a ton of setup overhead just for the specifics of the project you're working on, let alone if you want to customize the environment. 4) fragility. Vim + bash rarely breaks or leaves me unable to work on a project. I have been left high and dry by IDEs multiple times. All it takes is a coworker checking in personal changes to a team-wide project file. Then you're left in a broken state, figuring out what went wrong. so, there are some pros and cons. Everybody's style is different and there are real advantages to both approaches.
- recursive 15y ago* Auto-complete (that actually works based on the syntax tree of your entire project, not just text matching) * Refactoring tools that can not be done by an editor that does not also understand the language. (like block select -> "Extract Method" or "Implement Interface") * "Go to definition", which can take you to the definition of a method, property or field, that always works, even with the most convoluted syntax. * Debugger and breakpoints integrated into the environment * Expression-level type inference, or the ability for the IDE to tell you the type of an expression, and examine that types' definition in all cases. * Basically any manipulation of the files that requires more understanding of the source files than text-based operations.