{specialized, general-purpose} × {text editors, IDEs}

Some thoughts about text editors, IDEs, specialized or general-purpose applications.

Several languages Other tasks Plugins
Specialized text editor No No ?
General-purpose text editor Yes No Yes
Specialized IDE No Yes ?
General-purpose IDE Yes Yes Yes

The above table summarizes how I view the text editors and IDEs field.

Several languages

A specialized application focus only on one programming language, or several languages used together. A general-purpose application can support completely different programming languages and platforms.

Other tasks

A text editor focus only on editing text or source code, while simplifying as most as possible the writing of this code. An IDE integrate other features like building the source code, running it, writing commits, integrate a debugger, and so forth.

Plugins

For obvious reasons, a general-purpose application should have a plugin system. For a specialized application, the need for plugins is less obvious.

Two extremes

The general-purpose IDE with plugins is one extreme. The user interface must be generic enough to suit plugins and different programming languages. And it takes more time to learn and configure the application.

The specialized text editor without plugins is the other extreme. The developer has full control on the user interface, so the application has a potentially better usability. The application requires less time to learn and configure. Ideally, it should Just Work.

Not reinventing the wheel for specialized applications

Write libraries for the common features! Or at least ensure that your code is reusable. This is not limited to text editors and IDEs, I’m sure you can apply the same principles on your favorite field.

14 Responses to “{specialized, general-purpose} × {text editors, IDEs}”

  1. Anonymous says:

    I’m amused by this, because I run both Emacs and Vim. I use Vim as a general-purpose text editor, with a few key IDE features. I use Emacs with AUCTeX as a specialized IDE for LaTeX documents, and nothing else.

    • Anonymous says:

      You use Emacs as a specialized IDE for LaTeX, because you have configured it that way. But Emacs is more a general-purpose text editor (or IDE, since it can integrate a lot of different features like mails or IRC, from what I’ve heard).

  2. Karl Napf says:

    IMHO the term IDE is misused a lot nowadays. Some people use it to refer to “Collection of Tools” like geany, anjuta, that integrate a text editor with version control, a debugger and more. This seems to be what you are referring to as well.

    A proper IDE destinguishes itself from such a collection of tools by providing a code model. All good IDEs do that (basically all commercial offerings as well as eclipse, kdevelop and qt creator). That means it parses and understands the code.

    The code model enables things like:
    * Proper syntax highlighting, going way beyond what e.g. gtksourceview does.
    * Help with code refactoring
    * Help to write code (e.g. fill in skeletons of all virtual methods of classes this one is derived from)

    So basically everything that makes you productive when using a IDE comes from the code model. If there is no code model, then you can just as well use a text editor (provided you are happy to use stand-alone tools).

    I am not 100% sure of where you are going at with this blog post, but I am pretty sure you are referring to collections of tools, not IDEs. I strongly recommend getting a proper IDE and giving that a spin:-)

    Best Regards,
    Karl

    • Anonymous says:

      The distinction between a text editor and an IDE is not black and white. For me, a specialized text editor focus on the code. It can thus provide features like you describe (code refactoring, snippets, completion, etc).

      An IDE, for me, integrate other features that are not directly concerned by editing the code. View the git history, write a commit, build, run and debug the code. All these features can be achieved in the terminal, or with other graphical applications.

      I don’t say that specialized IDEs are bad, they are just more complicated to use because they have more features. If you want to develop a specialized IDE, the first step is to develop a specialized text editor. And then integrate the other features.

      • Karl Napf says:

        Whether you can debug, commit into one version control system or another, etc. that is all secondary to me. That makes up a “collection of tools” in my book. Those are not worth bothering with, at least not if you know the individual tools combined into those collections.

        The central feature to me is the code model. A IDE has one and offers tools (at least a text editor, but version control systems, debuggers, etc. are of course common, too) that integrate into that information. E.g. in Qt Creator even the small text editor you use to write commit messages is hooked up with the code model to offer completion for the class names used, etc. The “integration” of tools into one code model is what makes having an IDE worthwhile.

        A code model does need quite a bit of infrastructure: Simplified you can say that the code model needs the same information as the build system. It needs to know which files belong to the project, how those are built and which configuration (include paths, defines, etc.) are applied to each and every one of them. Without that information the code model is useless. E.g. it can not know which sections of the code are #if-defed out without the defines.

        That implies that (to me at least) a text-editor and a IDE are separate beasts. A text editor works on a file level. By that I mean that you open individual source files and the editor does not care whether and how these files are related.

        An IDE necessarily works on a project level, simply because the information needed for the code model is not available otherwise. So turning a text editor into an IDE is not trivial and needs a bit of plumbing to be in place first. It is more work than just bolting a UI for gdb onto your existing text editor.

        I also disagree that a “specialized IDE” must be harder to use then a text editor. You can provide a lot of benefits without any special UI. One example is proper syntax, including things like
        * assign a custom color to each variable,
        * take data types into accounts (e.g. add a blue tint to all vars containing an int)
        * show visibility (e.g. when using static functions they have a different color than non-static ones, etc.).

        It is really amazing what you can do with the information from the code model, even without adding UI elements.

        Best Regards,
        Karl

    • swilmet says:

      In “integrated development environment”, we can see the environment as:
      – editing the code
      – git
      – build system
      – debugger
      – the API documentations
      – etc.

      If all those components are integrated, we can call it an IDE.
      If tools are used separately, it is still a “development environment”, but not really integrated as one application.

      If we deepen the task “editing the code”, then a good tool for that provides indeed a code model.

      Does it make sense to view an IDE and specialized text editors like that?

      • Karl Napf says:

        If all those tools are integrated into one UI, then indeed many people will call that an IDE. But in fact it is more like a collection of tools sharing a UI.

        A good IDE starts where these tools share an understanding of code and to do that they need to integrate into a code model that is part of that IDE. If that is not happening, then that so called IDE is a waste of everybodies time.

        Check any commercially available IDE, check good free IDEs like Eclipse, KDevelop, Qt Creator, (sorry, I am not aware of anything in the gnome universe that qualifies here!) they all have one (or more) code models and have all the additional tools integrate into that/those.

        As pointed out above, the difference between a text editor and a IDE is that the first works on a set of files without any understanding whether those are related or not. The latter does by necessity work on a project since the code model needs similar information as the build system. To me that makes them separate beasts.

        • swilmet says:

          Yes it makes sense to have the “file level” or “project level/code model” axis to determine the application type.

          Personally, I prefer a specialized application (so for only one language/platform or several languages used together) working with a code model on the project level, like you describe. But for other features like git, a debugger, etc, I prefer to use command line tools. And I prefer to call that a specialized text editor, since it is only for editing the code (even if it has a code model and work on the project level).

          • Karl Napf says:

            Which text editor with a code model are you using if I may ask?

            I do mostly use Qt Creator, but I tend to use the command line for all my git needs and most other tasks, too.

            Creator adds some nice debugging capabilities (e.g. show the actual pixels in a QImage, so that I can step through my code drawing into that image) for Qt types on top of what gdb has to offer, so I do prefer the debugger built into Creator for Qt applications. Actually even when debugging pure C apps I stick inside creator nowadays…

          • swilmet says:

            In gnome there is no good text editor with a code model, so I just use Vim with the clang_complete plugin. The completion in Anjuta is not as good as clang_complete.

            My wish is to have a good gnome C/GObject text editor.

  3. I think IDEs got it wrong in a lot of ways as MSVS created the principle “the IDE does the build” — and therefore locking the project to the specific IDE and tools. I consider that wrong. Ideally there should be a interface between (multiple) IDEs and the build system allowing the build system to interact with any IDE.
    So I created something like that: https://gerrit.libreoffice.org/gitweb?p=core.git;a=blob;f=bin/gbuild-to-ide;h=0f08d7123fe989a5e0cf0b55d51a1fd815b25080;hb=cdb405f4e4b168d1e2f6dea9ac985df319a76015

    That creates project files from the LibreOffice build system for the IDE of your choice. Well, … initially only for Kdevelop — but the Kdevelop specific part was only some 200 LOC. And by now we have initial implementations for XCode and Visual Studio too. Patches for Anjuta appreciated of course. ;)

    Note that this doesnt allow “add this c++ file to that library” yet as IDEs have no hooks for that. So you still need to edit makefiles for that. But it allows a lot of other stuff like code-completion etc.:
    http://nabble.documentfoundation.org/Building-LibreOffice-from-an-IDE-td4083960.html#a4083968

  4. I have read a few excellent stuff here. Definitely value bookmarking for revisiting. I wonder how much effort you place to create any such great informative site.

  5. Andrew Pelt says:

    I run both Emacs and Vim. I use Vim as a general-purpose text editor.