IDE Wars!

Über bestimmte Themen können sich Softwareentwickler vorzüglich streiten: Tabs vs. Spaces, Klammersetzung oder natürlich auch die „richtige“ Programmiersprache. Und selbstverständlich kann man auch bei den eingesetzten Tools geteilter Meinung sein – insb. bei der Entscheidung für einen Texteditor (wobei für mich der Krieg der Editoren natürlich längst zugunsten des Vim beendet wurde ;-)). Aber auch die heißgeliebten IDEs sind oftmals Stein des Anstoßes zwischen Entwicklern. Und gerade im Java-Umfeld gibt es immer wieder Diskussionen bzgl. der „besten“ Entwicklungsumgebung. Hier kommt ein Artikel, der ausnahmsweise mal Eclipse gegenüber IntelliJ IDEA den Vorzug gibt: I Still Prefer Eclipse Over IntelliJ IDEA.

Ich muss sagen, dass ich Eclipse nun seit vielen Jahren benutze und tatsächlich keinen Grund sehe zu wechseln. Die Shortcuts sind in Fleisch und Blut übergegangen und performant (genug) ist die Umgebung auch. Außerdem ist sie (meiner Meinung nach) der de-facto Standard für Entwicklungsumgebungen. Teilweise habe ich auf meiner Maschine vier verschiedene Eclipse-Installationen parallel laufen, weil z.B. die Entwicklungsumgebung für Natural und auch den Integration Server auf Eclipse basiert.


Welche IDE verwendest du am liebsten? Warum hast du dich so entschieden?

4 thoughts on “IDE Wars!

  1. In einer Emacs Meeting Gruppe sind ein paar Stichworte gefallen, warum Emacs- und Vi- oder VIM auch in der Zeit von Starken IDEs noch Vorzüge haben können. Wenn wir die Situation eines Softwareentwicklers einmal mit einem Schied vergleichen. Das erste, was ein Schmied lernen musste, war wie er seine eigenen Werkzeuge herstellen kann. Im Prinzip ist es ja dass, was auch von einem Softwareentwickler erwartet werden kann – nämlich, dass er sich seine eigenen Werkzeuge auch herstellt, die er zum Arbeiten benötigt. Diese Anpassungsmöglichkeiten findet man in Vi oder Emacs.

    Der nächste Punkt ist „Effizienz“. – Put all Things in the Editor – Das ist das Credo von Vi- oder Emacs. Als Entwickler möchte ich nicht unnötig meine Hände von der Tastatur nehmen müssen. Rechnet man die Mausbewegungen- und Klicks – ist das der Punkt, der Effizienz ausbremsen kann. Vergleichen wir diesen Vorgang mit einer Restaurant-Küche. In einer Restaurant-Küche ist es völlig egal, ob es „schöne Geräte“ gibt – die Küche muss hunderte von Menüs ausbringen, wenn die Gäste Hunger haben. Gewissermaßen wird das auch von einem Softwareentwickler erwartet – Softwareentwickler lesen und schreiben letztendlich „Text“. Alles was dann stört- oder im Weg ist, den Workflow behindert – geht entgegen der Effizienz.

    Ein letzter Punkt – „Lebenszeit“ eines Editors. Eclipse, Emacs oder auch Vi / VIM können problemlos auf allen Arbeitsumgebungen eingerichtet werden – seit 20 Jahren – unverändert. Das heißt, man muss einmal richtig viel lernen, danach hat man dann erst einmal Ruhe. Man kann zu Hause auf dem Mac, im Büro mit Ubuntu und sonstwo mit Windows arbeiten – die Umgebung ist gleich. Das kann man nicht von allen kommerziellen Produkten behaupten. Ein kommerzielles Produkt „lebt“ solange, wie es das Unternehmen gibt. Unternehmen kommen und gehen.

    Org-Mode von Carsten Dominik – „Living in Plan Text“ – zeigt, wie man eine Arbeitsabläufe optimiert mit dem Emacs nach David Allens Getting Things Done Methode organisieren kann.

    Natürlich gibt es auch Gegenargumente. Im Zeitalter moderner „Browser“ mit allen möglichen Entwicklungswerkzeugen, kann der Emacs oder Vi nur noch bedingt mithalten. Auch PDF – geht nicht – zieht immer mehr in Workflows ein. Sicher sind gute IDEs auch eine Hilfestellung – vielleicht auch beim Lernen – aber der Beste „Debugger“ ist doch der „Kopf“ des Programmierers.

  2. Früher habe ich Netbeans verwendet. Das war dann mit irgendeiner Version so langsam beim indexieren, dass ich auf PHPStorm umgestiegen bin. Das ist jetzt ca. 6 Jahre her und ich will auf nichts anderes wechseln. Für mich einfach die beste IDE im Webbereich.

  3. Hallo Thorsten,

    vielen Dank für den umfangreichen Kommentar. Da kann ich in allen Punkten nur zustimmen! Wobei ich versuche, die Anpassungen am Editor möglichst klein zu halten, da ich meine Konfiguration nicht auf allen Geräten zur Verfügung haben kann und dann ggfs. wieder „umlernen“ muss, wenn ich z.B. auf einem nackten Linux-System arbeite.

    Viele Grüße!
    Stefan

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax