Are you using an IDE, or an editor? Are you a “hardcore” programmer, or you are one of those sissy modern developers that use IDEs? Have you personalized your emacs or vim to make you 200% more productive? Or do you think that emacs is useless, at least for Java. Either way, it’s an interesting topic to discuss – what are the pros and cons of using an IDE vs using a customizable text editor (vim/emacs/Sublime/…). And of course, I’m starting with the disclaimer that the distinction between “IDE” and “editor” is not that sharp.
Let’s first look at the trivial example – Java (and C#). It is a no-brainer there and the IDE wins by a huge margin, because of all the wonderful features like refactoring, debugging, hierarchies, integration with frameworks and build tools. Writing Java in anything other than an IDE should be restricted only for educational purposes, otherwise you are losing too much.
But it’s not that black-and-white for other languages, where the IDEs are not that mature or you cannot have some of the features that you have in statically-typed/compiled/jvm/.. languages.
Let’s take Groovy. A JVM language. The IDE has syntax coloring, autocomplete where possible, jumping to files with shortcuts. You get that with text editors as well. But with a text editor you can easily plug shell scripts that run your grails application and then run selenium tests, while running a grails application from within the IDE is (or at least used to be) painful. So, you might be better off going for a text editor?
Additionally, the IDE may leak something into the application. Novice developers may commit absolute build paths, the IDE might have a very cool support for a framework, but lack one very important parameter that appeared in the latest version, so that you have to make a workaround. The IDE may make it too easy to generate tons boilerplate code, that will later be hard to support. Minor, even subliminal pitfalls maybe, but still – an editor isn’t leaking anything because it doesn’t have anything to leak.
But let’s elaborate a bit more on customizability. The cool text editors allow you to write simple scripts that plug into the editor and thus let you improve your experience. And that’s important. I didn’t realize it until I had to switch to IDEA and there ALT+arrows didn’t jump through camel humps, but only through whitespaces. And hovering on a class didn’t show its package. Very minor things that it turns out are important for me. Luckily, IDEA had these things configurable, but it might not have had them. If you want to write a plugin, you may need to know OSGi, SWT, a complex plugin API and whatnot. It’s an overkill to write a plugin for such small things.
So a very important thing I would like to see from IDEs – they should be more easily customizable. Simply dropping a file (in any jvm language, for example) should have the ability to alter the behaviour. At your own risk, of course, and soon you may spend hours debugging which two files are in conflict and are blocking your IDE, but that should be available.
Remember the example where you add a shell-script that runs selenium tests. It poses a question that spans a lot of these editor customizations – should they really be part of the editor? Don’t they belong to the build tool instead? Many of them indeed belong to the build tool. Pre/post-processors, code-generation, one-command deployment, performing release, running functional tests, etc. I would say that these belong to the build tool, because a CI server must be able to do them as well, and it’s headless.
And apart from the “plugins” you would add to the editor, that make writing code and navigating the project easier, all others will probably need to be shared with other team members. Having a separate repository? And tested on multiple versions? That might turn out to be a time-consuming task, while keeping them to yourself may lead to inconsistency across the team. And you would usually bring your entire text editor configuration with you on each project, but then the configurations of other members may conflict with yours. I cannot give a concrete example, because I’ve never heavily customized a text editor, but the general feeling is that you should not make something too custom for yourself, and for your personal process, unless you are working on your own. A good argument here is that you will be able to switch the language you use without having to lose the productivity tricks. And that’s a fair point, given the lack of interoperability of IDEs. But most sensible IDEs do allow you to reach a certain, significant level of productivity, and maybe the rest 20% are not worth it.
Regardless of whether you agree with the statements in the above paragraph or not, if IDEs provide the “plugs” for quick and easy customization, I don’t think there will be any remotely compelling reason for using a text editor, apart from “I’m too used to that”. Any IDE by definition has more features than a text editor, but it lacks the flexibility/customizability. If that issue is fixed in a reasonable and reusable way, it will no longer be a tradeoff to use an IDE even for a dynamic language. Open-source IDEs, of course.
I recently published a blog with the title “Evolution: form Emacs to Eclipse to IntelliJ and back to Emacs?” (http://michaelscharf.blogspot.de/2014/03/evolution-form-emacs-to-eclipse-to.html). I would agree with most what you say.
My choice is very light IDE Codelobster – http://www.codelobster.com