IDE vs. Editor

March 7, 2014

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.

If you find the content interesting, you can subscribe and get updates


 

7 Responses to “IDE vs. Editor”

  1. You’ve just written about one a pet peeve of mine. I actually hate both categories.

    I’ve been trying out every editor/IDE I found on my way that would run on my computer (Windows) and would remotely serve my needs (PHP coding). Most of them fell in these clearly defined categories:

    - Editors stuck in the glory days of Unix (1970s), where you can write your own scripts to do any kind of advanced stuff like saving files.

    - Editors stuck in the glory days of Windows (2000s): hundreds of toolbars with useful features like “bold”. The most advanced include a “Code” pane with a plain text list of everything that has a bracket on current file.

    - TextMate clones, with… Well, I’m a Windows guy so I’ve never used TextMate. I’ve seen screenshots and it’s definitively a GUI tool; it even has dialogues—no idea why its clones don’t.

    - Conventional IDEs, with everything you need to code C and C++. In the best cases, their PHP support consists on syntax highlighting (.htaccess support not included).

    - Java IDEs, with support for many languages, as long as they’re Java. No, seriously, with awesome code intelligence, assuming you have an 8-core computer with 16 GB of RAM and a solid-state drive.

    - On-line IDEs: the speed of browser JavaScript with the trustfulness of the cloud.

    In fact, bloated Java IDEs are among my favourites, especially:

    - NetBeans, where file encoding in a global setting.
    - PhpStorm, where you cannot type the € symbol.

    At least, they help me with the part of programming work that’s not related to typing text. But we already had extraordinary text editors on the late 1990s that were lightning fast on our Pentium computers and had already invented most of the basic tools known today (syntax highlighting, rectangular selection, regexp search, snippets…). Why do modern IDEs embed editors that are hardly better than a ?

  2. Being a bit easier to work with another languages is probably the biggest reason for me to invest in learning and customizing an editor.
    Developer tools maturity takes a long time, and so your language options are kept very small if you stick to full-blown IDEs.

    Most people choose languages mainly based on the tooling available for it — that’s a bit unfortunate, if you share the vision of better languages being the future.

  3. Simplicity is always a valid argument. Except the obvious(Java, C#, etc.) IDEs bring in way much more complexity than they solve(IMHO). A text editor is rarely more complex than needed, because it gains features progressively as you find the need for them. And IDE has all the fancy functionality needed in a workflow that it’s creators have deemed most useful in some sense. And for many people use cases that is obviously good and should not be thrown away for the sake of being “the text editor guy”.
    I tend to have this itch(call it a NIH thing if you will), that not knowing how something works drives me crazy. Your text editor rarely does something you don’t understand in a good degree of detail, as most it does is what you extended it to do. Same reason why I think things like prebuilt dotfiles for editors are a bad way to start learning them, it starts you off on the wrong foot. It’s about building it yourself, since that will allow you to know as much details about it’s functionality as you can.
    For the same reason someone who likes he’s IDE and is comfortable in it, won’t use a heavily packed vim/emacs setup with all the good plugins for the needed language, it doesn’t have the same idea behind it. An IDE is a monolithic structure and you can depend on it to always function the way it does, you are free to accept it as a black box. A text editor you view as a black box will either not give you much more than a bare vi(mind you: vi != vim :)), or even worse – explode in your face once every few days and cause you far more loss than gain.

  4. Hands down. I’ve tried eclipse, worked in VS for years, FlashDevelop. For editors I tried notepad++ and sublime text. Now I’m doing primarily javascript with frameworks and JetBrains webstorm is the BEST IDE / CODING EXPERIENCE i’ve ever had. I do not work for them, but would consider it. Code completion and jump-to-definition is a must for fast coding.

  5. The custom nature of the ASIC chip design has made it possible to squeeze in more functionality under specific system
    size, while simultaneously reducing power requirements, heat and cost.

    In the warp-speed world of technology, five years is an eternity.
    The screen paste file for surface mount applications will be required to order the stencils
    for the solder paste application to the board prior to the part placements.

  6. Great article, exactly what I wanted to find.

    my page – agen judi online indonesia (buccaneers.tv)

  7. […] against the rest of the procedures you are forced to do. And that’s part of the reason why I prefer an IDE over a text editor, I don’t use Emacs and I don’t like Scala, and I don’t use […]

Leave a Reply