Trollwut: Eclipse

Ich programmiere nun schon seit einigen Jahren mit den verschiedensten Sprachen, Tools und Bibliotheken. Bei der Frage ob eine Umgebung für mich nutzbar ist, kommt es auf einige wenige Variablen an. In diesem Artikel will ich mich kurz mit Eclipse befassen und prüfen inwiefern dieser Haufen Hackermist für meine Belange geeignet ist.

Bevor wir jedoch zu Eclipse selbst kommen, sollten wir vlt. meine Erwartungen etwas definieren...

Die wichtigste Frage ist wohl, wie schnell ich mit dieser Umgebung programmieren kann, also wie gut ich beim Finden von Funktionsnamen, bei reinen Syntaxfragen oder der Verwendung von SVN/CVS/Wasauchimmer unterstützt werde.

So ist mir z.B. eine Erleichterung wie Code-Completion einiges wert, da es mir beim Programmieren viel Zeit mit dem Nachschlagen von irgendwelchen Funktionsnamen erspart. Wichtig sind dafür natürlich auch sprechende Funktionsnamen, z.B. PHP als Sprache eignet sich dafür überhaupt nicht, da alle gängigen Funktionen unsortiert auf einem Haufen liegen und teilweise Bezeichner haben, deren Sinn sich mir auch noch verschließt wenn ich weiß was sie tun. Wirklich überzeugt hat mich dies jedoch bisher selten, einzig Delphi/Lazarus haben bisher wirklich zeitweise eine Befehlsreferenz für mich unnötig gemacht, Visual Studio.Net versucht dem nahe zu kommen, scheitert jedoch an den verwendeten Sprachen und Bibliotheken. (VCL und das Free-Pascal-Pendant waren halt wirklich sehr auf derartiges ausgelegt und wurden nicht erst nachträglich angepasst.)
Selbst wenn man diese Funktion hat, gibt es natürlich immer Funktionen deren Name und Kurzbeschreibung nicht alles aussagt, in diesem (und vielen anderen Fällen) ist sehr praktisch wenn man eine gute Hilfefunktion zur Verfügung hat. Erneut können Delphi und Artverwandte hier punkten, bei einem Druck auf F1 sofort die Beschreibung des Elementes unter der Cursorposition zu erhalten liegt ziemlich nahe am Optimum.
Hier finden sich allerdings auch schon viele andere Umgebungen die das ähnlich gut können. Namen zu nennen sprengt hier fast schon den Rahmen, erstaunt war ich jedoch besonders über die Qualität dieser Funktion bei einigen Prolog-spezialisierten Umgebungen.
Die Liste derartiger Funktionen lässt sich beliebig fortsetzen, wichtig wären z.B. noch die grafische Erstellung von GUIs, Syntax-Hervorhebung (Welche IDE kann das heutzutage nicht?), automatisches Einrücken oder die Anzeige von Syntax-Fehlern direkt im Code.

Nahezu ebenso wichtig ist mir, wie schnell ich eine IDE zum produktiven Funktionieren bringe. Was habe ich schon davon dass ich mit einer IDE wahnsinnig komfortabel Ook! schreiben kann, wenn ich für das nächste Projekt Malbolge verwende, für das übernächste Whitespace und ich für jeden Wechsel die IDE länger Einstellen muss, als ich für das ganze Projekt an Zeit benötige.
Hier muss man natürlich zwischen Sprach-/Systemspezifischen und generell verwendbaren Umgebungen unterscheiden, Delphi ist sicher schnell verwendbar, kann jedoch außer für Object Pascal/Delphi nur noch für C++ verwendet werden (zumindest bei den älteren Versionen die man noch ernsthaft verwenden konnte und auch C++ benötigte dort eine komplette Neuinstallation fast des selben Programms unter einem anderem Namen). Ein einfacher Texteditor mit Shell-Tools auf der anderen Seite kann nicht nur fast unter jedem System für jede Sprache (natürlich mit Einschränkungen, z.B. wird nicht immer jede Sprache von jedem Editor für Syntax-Hervorhebung unterstützt) eingesetzt werden. Auch die Zeitdauer die ich zum setzen aller Einstellungen benötige ist meist überschaubar (was zum Teil auch an der geringen Menge der Funktionen liegt).

An dritter Stelle meiner Erwartungen würde ich darauf achten wie stabil eine Umgebung ist (es nervt ungespeicherten Quellcode zu verlieren) und wie solche Dinge wie Ladezeiten die Arbeit verzögern. Die relativ späte Platzierung rechtfertige ich nur damit dass die meisten Systeme stabil und schnell genug sind, man verbringt heute einfach nicht mehr 2/3 der Zeit mit dem Anblick eines Ladebildschirmes.

Nun wollen wir mal Eclipse in Relation zu diesen Anforderungen setzen...

Was die Funktionsbandbreite betrifft lässt Eclipse wohl wenige Wünsche übrig, es gibt Erweiterungen für Code-Vervollständigung, für SVN-Unterstützung, für GUI-Erstellung und was auch immer ein Entwickler sich sonst noch wünschen kann.
Diese Funktionen sind jedoch fast alle frickelmäßig Programmiert, Eclipse ist eine der wenigen Umgebungen unter der ich lieber von Hand meine Button-Positionen eintippe als sie im Fenster zusammen zu schieben (wer das mal unter Java und Eclipse versucht hat wird wohl wissen was ich meine). Auch ist die Code-Vervollständigung und Hilfe für die meisten Sprachen einfach unbrauchbar oder nur über Drittsoftware zu ermöglichen. Was wirklich nicht ganz schlecht funktioniert sind Dinge wie CVS/SVN-Unterstützung und Syntax-Hervorhebung. Dieser kleine Triumph hat leider nur einen kleinen Makel: so ziemlich JEDES andere System kann das auch.
All diese Funktionen werden natürlich über Plugins realisiert, wo wir dann auch schon beim Zweiten Punkt sind. Eclipse für eine neue neue Sprache um zurüsten ist grauenvoll. Man hat schon eine IDE die den Anspruch stellt für so ziemlich jede Sprache verwendbar zu sein, doch dann braucht man für so ziemlich jede Sprache zum Einrichten länger als wenn man eine neue IDE installiert.
Man hätte die Plugins auch über die Paketverwaltung des Betriebssystems abhandeln können, doch Eclipse verlässt sich lieber auf sein eigenes Paketsystem. Ich habe inzwischen einige Eclipse-Distributionen verwendet, doch das einfache Installieren von weiteren Funktionen über das dafür gedachte Menü (das übrigens im Punkt "Hilfe" so ziemlich an der bescheuertsten Stelle seit "Start->Beenden" platziert ist) funktionierte nur in den wenigsten Fällen "out-of-the-box". Das Ganze ist so umständlich zu verwenden, dass ich irgendwann angefangen habe mir lieber für jede(s) Sprache/Framework/API eine spezielle Eclipse-Distri parallel zu bereits vorhandenen zu installieren. Eine eigentlich wirklich bescheuerte Idee.
Auch das Einbinden eines neuen Projektes dauert extrem lange. Natürlich hat man das passende Plugin für SVN oder welche Quelle man auch immer gerade braucht nicht bereits installiert und natürlich hat man vom letzten Projekt her keine Ahnung mehr über welches der 10 Dutzend Projekt Anlegen/Importieren/Öffnen-Menüs man es das letzte Mal geschafft hat das Projekt so einzubinden dass es möglichst wenig Probleme gab. Auf der Konsole wäre man mit diesem Vorgang sicher um Längen schneller gewesen, im Notfall tippt man halt mal ein "svn help" ein um auf ca. 1-2 Bildschirmseiten die wichtigsten Kommandos zusammengefasst zu lesen.

Kommen wir nun zum dritten Punkt, bei dem es für Eclipse wirklich peinlich wird.
Eclipse läuft auf Java-Basis und das merkt man auch sehr deutlich, die Ladezeiten sind immens... Warum zum Henker verwendet jemand Java für ein Programm das permanent auf dem System laufen soll? Habt ihr zu viel RAM? Sind euch Ladezeiten egal? Warum muss eine Java-IDE unbedingt in Java geschrieben sein?
Bitte kommt jetzt nicht mit diesem Scheinargument dass Eclipse unbedingt Platformunabhängig sein soll, das kann so ziemlich jede andere Sprache auch. Im schlimmsten Fall bastelt man halt eine Portierung für die 3-4 wichtigsten Systeme, wenn man sich die verwendeten Bibliotheken gut ausgesucht hat hält sich der Aufwand dabei auch in Grenzen.
Ich sehe durchaus ein dass Java seine Daseinsberechtigung hat, aber es gibt da draußen Leute die würden dieses Bibliothekenmonster auf Precompilerbasis wirklich für jeden blöden Texteditor verwenden. Dafür wurde die Sprache nicht optimiert! Es gibt bessere für sowas und man sollte das auch einsehen. (Das gleiche Argument trifft übrigens auch auf die ganzen IDEs mit .Net-Basis da draußen zu. -.-)

Eclipse verwendet exzessiv Plugins, für jede kleine Standardfunktion ist ein Plugin zuständig. Wer schonmal was von der Neigung komplexer Systeme gehört hat, komplexe Probleme zu verursachen, dem muss ich die Schlussfolgerung daraus wohl nicht mehr nennen.
In der Tat hatte ich bei einigen Projekten permanent mit Eclipse-Abstürzen zu kämpfen, da hilft es auch nicht unbedingt weiter wenn man z.B. das hängen gebliebene Fenster für einen Commit mit einem Tastendruck in den Hintergrund bewegen kann (das Fenster verschwindet wirklich und wird durch eine kleine Anmerkung in der Statusleiste ersetzt), wenn man mit der IDE dann dennoch nicht weiterarbeiten oder sie gar regulär beenden kann... es läuft ja immerhin noch ein Vorgang.
Was in solchen Fällen bleibt ist dann also den ganzen Eclipse-Prozess zu killen und erneut zu starten... Die Ladezeiten (die übrigens manchmal länger sind als die meines ganzen OS inkl. grafischer Oberfläche) lassen grüßen.

Das alles zusammen ergibt dann eine Punktzahl irgendwo zwischen 0 und 0.5 von 3... Sehen wir es positiv, Eclipse hat viel Raum für Verbesserungen.