© aquafun, 123RF

Für Perl-Entwickler gibt es ausgefeilte Plugins für Texteditoren, aber auch für ausgewachsene IDEs. Ob der Einsatz solcher Plugins oder Anwendungen tatsächlich beim Skripte-Programmieren hilft, lotet die aktuelle Bitparade anhand des Editors Vim, der Perl-IDE Padre sowie des Eclipse-Plugins Epic aus.

Die Programmiersprache Perl [1] zählt wohl nicht zu jenen, die in den letzten Jahren besonders viel Aufhebens um sich gemacht haben. Das muss sie auch nicht, stecken ihre Qualitäten doch im Verborgenen. Egal ob Perl Text verarbeitet oder Prozesse automatisiert, kaum eine große IT-Firma, zu nennen wären Google, Amazon oder Yahoo, kommt ohne Perl-Skripte aus. Und kaum eine Frage, die sich der geübte Perl-Programmierer stellt, kann CPAN (Comprehensive Perl Archive Network, [2]) nicht beantworten.

Die meisten Hardcore-Perl-Programmierer haben in der Regel mit den Jahren ihren Lieblingseditor gefunden und kommen nun mit diesem aus. Kein Wunder: Wer sich mit Vim oder Emacs noch im Schlaf zurechtfindet, vermisst beim Programmieren nichts.

Dennoch kann es gerade bei umfangreichen Projekten mitunter sinnvoll sein, einmal in fremde Schuhe zu schlüpfen und zu einer ausgewachsenen Entwicklungsumgebung (IDE) zu greifen. Oder zumindest die vorhandenen Möglichkeiten mit Plugins zu erweitern.

Die Bitparade will die Frage nach den Vor- und Nachteilen solcher Schuhwechsel anhand dreier solcher Helfer beantworten. Wer auf Vim nicht verzichten möchte, freut sich womöglich über das Plugin Perl-Support [3], da es die Grundfunktionen des Lieblingseditors hilfreich erweitert. Daneben stellt der Artikel Padre (Perl Application Development and Refactoring Environment, [4]) vor. Diese maßgeschneiderte Entwicklungsumgebung will Perl-Programmierern sämtliche Werkzeuge, die sie benötigen, aus einer Hand liefern. Schließlich wendet sich die Bitparade noch dem Eclipse-Plugin Epic [5] zu, dieser sehr ausgereiften und zugleich umfangreichen IDE für Perl-Entwickler.

Alle drei Tools sind quelloffen, ihr Einsatz ist sowohl unter Linux als auch unter Mac OS und Windows möglich. Als Basis für die Tests diente ein frisch installiertes Ubuntu 14.04 LTS.

Perl-Support

Ubuntu setzt Vim weder als Standardeditor ein, noch installiert es den Editor mit. Der Artikel greift zu Gvim, einer Version des Editors mit grafischer Oberfläche, die gerade für weniger Vim-Affine etwas komfortabler zu bedienen ist. Ein

sudo apt-get install vim-gnome  libperl-critic-perl

installiert Ubuntus Gvim-Ausgabe mit den bekannten Gnome-Symbolen (Abbildung 1) sowie das Perl-Modul »critic« , das zum Einsatz kommt, wenn der Programmierer seinen Perl-Code auf Syntaxfehler hin überprüft. Das Perl-Plugin für Vim heißt Perl-Support, der Entwickler Fritz Mehner pflegt und erweitert es seit 2003 regelmäßig.

Abbildung 1: Der geöffnete Menü-Eintrag »Perl« im Editor Gvim, einem Frontend für Vim.

Der Download von »perl-support.zip« gelingt über die Webseite [3], der Entwickler entpackt das Archiv über »unzip perl-support.zip« am besten im Verzeichnis »$HOME/.vim« . Das legt gleich eine passende Ordnerstruktur an.

Startet er Vim für Gnome über das Kommando »gvim« und wählt den Menüpunkt »Werkzeuge | Load Perl Support« , erscheint der neue Menü-Eintrag »Perl« , der die Funktionen des Plugins auflistet (Abbildung 1). Der Menü-Eintrag wird auch zugänglich, sobald Gvim eine Perl-Datei erkennt. Das passiert, wenn der Entwickler eine solche öffnet oder wenn er auf der Kommandozeile von Gvim den Dateityp über

:set filetype=perl 1

setzt. Abbildung 1 zeigt einen Ausschnitt der Erweiterungen, die das Plugin dem Editor hinzufügt. Die ersten Menü-Einträge liefern jeweils leere Gerüste, um verschiedene Befehle syntaktisch korrekt in das Skript einzufügen, dazu gehören Kommentare (»Comments« ), Deklarationen (»Statements« ) und Ausdrücke (»Idioms« ). Dass diese Einteilung teilweise deutlich von der in der Literatur üblichen Gruppierung abweicht, mag anfänglich überraschen. Insgesamt betrachtet ergibt sich mit der weiteren Einteilung aber eine sinnvolle Struktur, über die der Programmierer effizient an den passenden Befehl gelangt und sich einiges an Schreibarbeit erspart. Weniger geübte Perl-Nutzer erhalten dadurch einen raschen Einblick in die Syntax.

Profiling und Debugging

Die weitergehende Einteilung orientiert sich wesentlich stärker an dem, was Entwickler regelmäßig brauchen: Reservierte Variablennamen, reguläre Ausdrücke, die POD (Auszeichnungssprache zur Dokumentation) und diverse Optionen, um Datei-Eigenschaften zu überprüfen. Die Funktionen im »Snippets« -Submenü verwalten Coderoutinen fürs Recycling.

Mit dem »Profiling« -Eintrag überprüft der Entwickler die Effizienz seines Codes. Dafür braucht er allerdings zusätzliche Perl-Module, die nicht als fertige Ubuntu-Pakete vorliegen. Am einfachsten holt er diese mit dem Tool CPAN-Minus und den Befehlen aus Listing 1 direkt aus dem CPAN.

01 sudo apt-get install cpanminus
02 sudo cpanm Devel::SmallProf
03 sudo cpanm Devel::FastProf
04 sudo cpanm Devel::NYTProf

Die Befehle berücksichtigen auch alle Abhängigkeiten und installieren die entsprechenden Module mit. Über »Run« lässt sich das Perl-Programm ausführen. Dabei kann der Entwickler beim Start auch gleich diverse Parameter übergeben. Hinter dem Menü-Eintrag verstecken sich außerdem der Zugriff auf den Perl-Debugger sowie auf die Tools Perltidy [6] und Perlcritic [7].

Mit dem Debugger muss der Entwickler an dieser Stelle bereits vertraut sein, da das Gvim-Plugin keine weiteren Hilfestellungen zu dessen Bedienung anbietet. Perltidy will ihm zu ordentlich formatiertem Code verhelfen (was nicht immer gelingt) und Perlcritic warnt vor schlampiger Syntax, die früher oder später zur Stolperfalle werden könnte.

Sämtliche Ausgaben eines gestarteten Programms sowie jene der hier verankerten Tools (den Debugger ausgenommen) schreibt Gvim in einen neuen Frame. Wer die Ausgaben lieber in einem Terminal mitlesen mag, konfiguriert dies über den untersten Menü-Eintrag »output: Vim->buffer->xterm« .

Fazit

Wer an umfangreichen Projekten mitarbeitet, schätzt möglichst übersichtlichen und leicht zugänglichen Programmiercode. Üblicherweise hilft eine ausgefeilte Navigation, um die eingebundenen Routinen, gesetzten Variablen, definierten Funktionen, geschachtelten Objekte sowie die Kontrollstrukturen rasch anzuspringen. In diesem Punkt bietet das Plugin keine Lösung. Auch auf eine automatische Vervollständigung des Perl-Codes, die in modernen IDEs selbstverständlich ist, muss der Entwickler verzichten. Den Perl-Debugger kann er zwar aus dem Editor heraus starten, die Arbeit damit erfolgt jedoch auf dem herkömmlichen Weg. Eine sinnvolle Integration in den Editor fehlt.

Zur Ehrenrettung des Programmautors sei gesagt, dass für Vim unzählige Plugins existieren, die einige der Funktionen nachrüsten. Eine Suche nach »vim plugins« oder »vim ide« im Netz bringt Hinweise auf Codevervollständigung, Codebrowsing, Versionierung und einiges mehr. Dass das Perl-Support-Plugin diese Funktionen nicht neu erfinden möchte, lässt sich nachvollziehen.

Und es gibt weitere Pro-Argumente. Da das Plugin schlicht und zurückhaltend gestaltet ist, finden sich Entwickler damit rasch zurecht. Seine Macher pflegen es zudem laufend, das Projekt bietet Kontaktmöglichkeiten und eine Mailingliste [3]. Wer dort fragt, erhält üblicherweise rasch und kompetent Antwort.

Auch die Dokumentation des Plugins ist umfangreich und gut verständlich. Die Performance entspricht jener des Editors und lässt kaum Wünsche offen. In Arbeitsumgebungen, in denen mehrere Personen zusammenarbeiten, kann das Plugin Vim sinnvoll ergänzen. Dass es einen Mehrwert für die Teamarbeit liefert, ist aber eher unwahrscheinlich.

Der allgemeine Nutzen des Plugins gegenüber dem bloßen Editor besteht wohl darin, dass es dem Editor in einer eigenen Struktur Perl-Spezifisches hinzufügt, ohne den Editor selbst zu verändern. Dem Einsteiger in die Perl-Programmierung kann dies dabei helfen, sich rascher in die Möglichkeiten der Programmiersprache einzuarbeiten.

Ob das Plugin allerdings geübten Perl-Programmierern und Vim-Nutzern hilft, bleibt offen. Zwar könnte ihnen das Plugin mit der einen oder anderen Funktion theoretisch regelmäßige Tipparbeit ersparen, häufig haben sich die Perl-Experten dafür jedoch schon im Vorfeld die eine oder andere Krücke zurechtgelegt.

Padre: Eine Perl-IDE

Mit Padre [4] betritt eine Anwendung die Bühne, die selbst in Perl geschrieben ist und gezielt gestandene Perl-Programmierer, aber auch Einsteiger ansprechen möchte. Besonders erwähnenswert ist, dass Padre Entwickler nicht nur beim Programmieren, sondern auch dabei unterstützen möchte, komplexen Code neu zu strukturieren (Stichwort: Refactoring, [8]). Auf diesem Weg wird der Code auf Dauer besser lesbar, wartbarer und weniger fehleranfällig.

Ein weites Anwendungsgebiet für Refactoring öffnet sich, wenn Entwickler ihren Code von Perl 5 auf Perl 6 migrieren wollen. Werkzeuge nehmen ihnen dabei einiges an mühsamer und fehleranfälliger Arbeit ab, die aufgrund der deutlich unterschiedlichen Syntax zwischen den beiden Perl-Versionen entsteht. In den Ubuntu-Paketquellen befindet sich die Version 1.0 von Padre, die der Befehl

sudo apt-get install padre

installiert. Ist das Programm gestartet (Abbildung 2), schaltet der Benutzer die Oberfläche im Menüpunkt »View | Language« von Englisch auf Deutsch um. Ein erster Blick in das Menü verheißt nur Gutes. Alles, was sich das Programmiererherz wünscht, scheint vorhanden zu sein.

Abbildung 2: Die auf Perl spezialisierte IDE Padre zeigt Informationen in Rahmen an.

Unter »Datei | Projektstatistik« finden sich einige Zahlen (Anzahl der Zeilen, Zeichen, Kommentare und so weiter) zu den Projektdateien sowie eine Schätzung des geöffneten Projekts nach dem Constructive Cost Model [9]. Dieses schätzt auf Basis des vorliegenden Codes die investierte Zeit und gibt die damit verbundenen Kosten in US-Dollar aus.

Solche Zahlen erweisen sich in der Praxis zwar teils als interessant, teils sind sie aber auch ziemlicher Nonsens. So ergibt die Schätzung unter anderem, dass sich der für den Artikel verwendete Beispielcode in sechs Wochen schreiben lasse, während der Entwickler Jahre daran gefeilt hat, ihn zu warten und zu perfektionieren. Aber das weiß Padre nicht, es sieht bloß das Endergebnis.

Im Menüpunkt »Bearbeiten« warten die üblichen Verdächtigen, aber auch die automatische Vervollständigung, die der Entwickler mit [Strg]+[Leerzeichen] auslöst. Codeschnipsel verwaltet er hier ebenso, um wiederkehrende Muster elegant zu bevorraten. Zudem lassen sich hier Dateien patchen und Diffs erzeugen. Im Test ergaben sich indes Probleme mit Auswahl und Anzeige der zweiten, abzugleichenden Datei, weshalb die Funktionen ungenutzt blieben.

Padre vervollständigt den gesamten Perl-Code, wozu die Namen von Variablen, Funktionen, Objekten und dergleichen gehören, wenn sie innerhalb der geöffneten Datei Erwähnung finden. Kommen sie hingegen in anderen Projektdateien vor, kennt sie Padre beim ersten Aufruf nicht. Das wundert nicht, würde so eine Funktion doch bei umfangreichen Projekten sehr viele Ressourcen binden und ein flüssige Arbeiten bremsen.

Als sehr nützlich entpuppt sich der Eintrag »Lesezeichen« im »Suchen« -Menü. Gesetzte Lesezeichen springt der Entwickler recht einfach an. Als Wermutstropfen bleibt, dass Padre diese nicht innerhalb der Projektdateien, sondern im Homeverzeichnis des Nutzers verwaltet. Sie lassen sich daher nicht oder nur sehr mühsam über die Versionsverwaltung abgleichen.

Der Menüpunkt »Ansicht« zeigt indes deutlich, wie viele Tools Padre vereint und in einem eigenen Rahmen anzeigen kann. Über den CPAN-Explorer lässt sich nach Perl-Modulen fahnden, die Padre auf Wunsch installiert. Immer wieder aber fehlen Module, die eigentlich im CPAN stecken und die CPAN-Minus (das auch bei Padre im Hintergrund wirkt) durchaus installieren könnte.

Der Eintrag »Funktionsliste anzeigen« präsentiert übersichtlich alle definierten Routinen und stellt diese zum Navigieren innerhalb des Codes bereit, während »Projektansicht anzeigen« deutlich macht, welche Dateien zu einem Perl-Projekt gehören. Über die angezeigte Liste öffnet der Perl-Coder dann die zugehörigen Dateien.

»Übersicht anzeigen« liefert einen schnellen Überblick der geladenen Perl-Module und eingebundenen Methoden, unter »Ausgabe anzeigen« bringt Padre die Ausgaben eines gestarteten Skripts sowie jene, die Perl auch in einem Terminal anzeigen würde, in einem eigenen Rahmen zum Vorschein.

Der Punkt »Syntax-Check ausführen« gibt Meldungen des Moduls Perl::Critic aus, wobei der Entwickler den Level der kritischen Kommentare (üblicherweise von sehr streng bis eher nachlässig) nicht einstellen kann. »TODO-Liste anzeigen« wäre ein praktischer Platz, um sich Notizen aufzubewahren. Allerdings verwaltet Padre auch diese Liste im Homeverzeichnis des Benutzers, sie lässt sich daher nur mühsam mit anderen abgleichen.

Wer sich die »Versionskontrolle anzeigen« lässt, erhält einen Überblick zum Versionsstand lokaler Dateien gegenüber einem Repository, das Subversion oder Git verwalten. Die Installation erfolgt mit:

cpanm Padre::Plugin::Git
cpanm Padre::Plugin::SVN

Anschließend aktiviert der Entwickler beide Plugins im Pluginmanager. Leider scheiterte die Konfiguration eines beliebigen Git-Repository mit dem Git-Plugin 4 im Test. Auch die Recherche nach den Ursachen lief ins Leere. Die Versionskontrolle über SVN sortiert sich anschließend als eigener Eintrag unter dem Menüpunkt »Werkzeuge« ein und lässt sich fortan von dort aus steuern.

Nicht zuletzt interessiert in diesem Menüpunkt noch die Funktion »Code-Ausblenden verwenden« . Mit ihrer Hilfe klappt der Perl-Nutzer, wie auch in anderen Editoren und IDEs, zusammengehörige Codeteile bei Bedarf ein und aus, um die Anzeige übersichtlich zu gestalten.

Refactoring inklusive

Der Menüpunkt »Refactor« vereint laut Beschreibung auf der Homepage [10] Funktionen, die beim Umarbeiten komplexer Programme in eine besser lesbare Form helfen. Sie benennen Variablennamen automatisch um und machen sie mit Binnenmajuskeln (Camelcase) zugleich besser lesbar. Zudem unterstützt das Programm Entwickler dabei, Programmcode aus Routinen zu lösen und in andere einzufügen. Leider traten bei allen Versuchen Meldungen zu “unbekannten Fehlern” auf, was das Refactoring momentan unbenutzbar macht. Im Padre-Wiki [11] deuten Einträge an, dass die Software diese Fehler schon einige Jahre mitschleppt.

Die Funktionen im Menüpunkt »Debugging« arbeiten hingegen vorbildlich (Abbildung 3). Die grafische Oberfläche führt zu den wichtigsten Befehlen des Debuggers. In einem Rahmen am unteren Bildschirmrand lassen sich dessen Ausgaben betrachten. Der linke Rand zeigt in einem Rahmen die definierten Haltepunkte an, der rechte bietet Navigationsmöglichkeiten durch den Code. Auch Variablenwerte lassen sich dort inspizieren. Insgesamt ist die Integration des Debuggers also gelungen, sowohl Anfänger als auch Fortgeschrittene finden sich dort sofort zurecht.

Abbildung 3: Die Integration des Perl-Debuggers in Padre ist gut gelungen.

Der Menüpunkt »Werkzeuge« beherbergt alle Einstellungen, die Padre konfigurieren, einen gut umgesetzten Editor für reguläre Ausdrücke sowie den Pluginmanager, um die aus CPAN installierten Erweiterungen zu aktivieren.

Last but not least verdient der Menüpunkt »Hilfe« Beachtung. Nicht selten fragen Programmierer lieber schnell nach, statt etwas zu lesen. Doch hier versammelt Padre eine Fülle an Quellen rund um Padre und Perl. Als nette Idee lässt sich verbuchen, dass User via IRC Kontakt zu anderen Padre-Nutzern erhalten, allerdings legen die Logfiles nahe, dass der Channel eher Kommunikations-Sparsamkeit zelebriert [12].

Fazit

Der Wert von Padre gegenüber einem bloßen Editor besteht sicher darin, viele Perl-Eigenheiten abzudecken. Neue Programmierer an Perl heranzuführen dürfte Padre hingegen kaum gelingen, denn Hilfe wartet nur in Form von ein paar Links auf externe Informationsquellen. Dafür ist die Anwendung sehr übersichtlich gestaltet, sodass neue Nutzer sich rasch zurechtfinden.

Die Dokumentation ist ausführlich und beschreibt Funktionen und Schnittstellen zum Programm umfassend und gut verständlich. Über SVN lässt sich Padre in typische Team-Arbeitsumgebungen integrieren. Externe Tools binden Entwickler jedoch nur mit einigem (Programmier-)Aufwand über die definierten Schnittstellen des Programms ein.

Zudem bietet Padre viele Möglichkeiten, umfangreichen Code übersichtlich darzustellen und darin zu navigieren. Wer häufig mit fremden Perl-Programmen zu tun hat, wird diesbezüglich gut versorgt. Auch der Perl-Debugger ist vorbildlich integriert, weil Padre die allermeisten seiner Funktionen über grafische Elemente zugänglich macht und das auch übersichtlich umsetzt.

Zwar pflegen die Entwickler den Code laufend, dennoch schleppt Padre einige lästige Fehler seit Jahren mit, die den Zugang zu nützlichen Funktionen verhindern. Die Performance entspricht jener eines typischen Editors und stellt an gängige Hardware keine besonderen Anforderungen.

Epic für Eclipse

Als integrierte Entwicklungsumgebung richtete sich Eclipse [13] ursprünglich ganz an Java-Programmierer. Über die Jahre hat es sich zu einer Anwendung entwickelt, die modular aufgebaut ist und sich für eine Vielzahl von Zwecken einspannen lässt.

Seit Version 3 im Jahr 2004 setzt die Java-Software im Kern auf das Framework Equinox [14]. Die Anwendung selbst besteht jedoch aus einer Vielzahl an Plugins, die sich im Kern einklinken und das Ergebnis wie eine monolithische Anwendung erscheinen lassen.

Eclipse dient aufgrund dieser äußerst flexiblen Architektur gern als Basis für andere Anwendungen, die sich als Plugins entweder in Aussehen und Bedienung an Eclipse anpassen oder aber die typischen Eclipse-Funktionen nutzen, ohne der Anwendung sehr ähnlich zu sein. Im zweiten Fall bedienen sich die Anwendungen über Eclipse RCP (Rich Client Platform, [15]).

Dank dieses Grundkonzepts ist Eclipse natürlich als IDE für eine Vielzahl an Programmiersprachen prädestiniert. Ein

sudo apt-get install eclipse

installiert die etwas angestaubte Version 3.8 aus den Ubuntu-Repositories. Die Vielzahl an abhängigen Paketen deutet bereits an, dass Eclipse einiges an Ressourcen beansprucht. Perl-Entwickler brauchen zudem mehrere Module:

sudo apt-get install libpadwalker-perl  libmodule-starter-perl libperl-critic-perl

Das zu Eclipse passende Perl-Plugin heißt Epic ([7], [16]) und lässt sich am besten aus Ecplise heraus installieren. Über die Menü-Einträge »Help | Install New Software« gelangt der Entwickler zum Installationsdialog und gibt dort als Quelle »http://e-p-i-c.sf.net/updates« ein, um dann den Anweisungen zu folgen, die das Perl-Plugin in Version 0.6.57 auf die Platte holen. Eclipse sucht in der Standardeinstellung automatisch nach Updates und weist auf sie hin, sodass neuere Versionen einfach zugänglich sind. In dem Menüpunkt lässt sich zudem die Sprachunterstützung für Deutsch nachrüsten, der passende Link wartet unter [17].

Ist eine Sprache installiert und entspricht diese der Standardsprache des Betriebssystems, wählt Eclipse sie fortan automatisch. Leider fehlt dann ein Menüpunkt, um zwischen den Sprachen umzuschalten und die Standardsprache einzustellen. Überraschenderweise gelang dies im Test nur auf der Kommandozeile über »eclipse -nl en« für Englisch.

Hat sich der Entwickler mit der anfangs gewöhnungsbedürftigen Bedienung von Eclipse vertraut gemacht, gelangt er rasch an sein Ziel. Dabei spielt es keine Rolle, ob er die IDE nun als Perl-IDE oder XML-Editor einsetzt. Im Unterschied zu den anderen beiden hier vorgestellten Tools kann der Nutzer in Eclipse viele Funktionen erst verwenden, wenn er seine Dateien in ein Projekt integriert beziehungsweise importiert. Es genügt also nicht, einfach eine Perl-Datei neu anzulegen oder zu öffnen. Ist diese Hürde genommen, listet ein Projekt-Explorer am linken Bildschirmrand die vorhandenen Dateien auf (Abbildung 4). Ein Gliederungsrahmen unterhalb bietet raschen Zugriff auf die Strukturelemente (Module und Funktionen) eines Programms.

Abbildung 4: Die typische Frame-Ansicht von Eclipse listet links die vorhandenen Dateien auf.

Über den Menüpunkt »Source« gelangt der Eclipse-Anwender an die Funktionen der beiden Perl-Module Pod::Checker und Perl::Critic. Startet er diese, erscheinen am linken Rand des Editors Warnmarkierungen (Epic-Markers), mit deren Hilfe er über das entsprechende Symbol navigiert. Am rechten Bildschirmrand der Anwendung blendet Eclipse geraffte Sprungmarken ein, mit denen er bequem an einzelne Positionen hüpft. Der Menü-Eintrag »Format« versucht sich via Perltidy an einer einheitlichen Formatierung des Perl-Codes, die nicht immer zu besseren (wohl aber zu sehr einheitlichen) Ergebnissen führt.

Komfortabel debuggen

Eclipse verändert sein Aussehen (die »Views« ) je nach Aufgabe. Das mag für den Anfänger verwirrend erscheinen, da sich dabei einzelne Frames schließen und andere öffnen. Für Entwickler, die Code bearbeiten, versionieren oder debuggen möchten, ergibt dieser Ansatz jedoch Sinn. Schließlich konzentrieren sich dabei alle Funktionen auf die zu erledigende Aufgabe.

Über den Menüpunkt »Run« starten Nutzer Perl-Programme und betrachten deren Ausgaben in einem Frame. Hier versteckt sich auch die Option, Programme im Debug-Modus zu starten, wobei Epic die Möglichkeiten des Perl-Debuggers sehr gut umsetzt (Abbildung 5). Anfänger kommen gut damit zurecht, Fortgeschrittene arbeiten komfortabel.

Abbildung 5: Auch die Integration des Perl-Debuggers in Eclipse lässt kaum Wünsche offen.

Erwähnenswert ist auch, dass gesetzte Breakpoints einen Neustart der IDE überleben und sich innerhalb des Projekts mitführen lassen. Leider legt Epic sie nicht in den Projektdateien selbst ab, sodass eine Versionskontrolle sie nicht erfassen oder gar mit anderen abgleichen kann. Ist das Perl-Modul Padwalker installiert, zeigt der Debug-Modus zudem sehr komfortabel die aktuellen Inhalte von Variablen an.

Die Funktionen »Run« und »Debug« sind über entsprechende Icons unterhalb des Menüs zugänglich. Die bei einer etablierten IDE wie Eclipse zu erwartenden Funktionalitäten sind da. Dazu gehören:

• Syntax Highlighting
• Automatische Vervollständigung von Funktionen und Variablen
• Führen von To-do-Listen
• Verwalten von Codeschnipseln (hier Templates)
• Eine integrierte Hilfe für Perldoc

Gut versteckt im Menü unter »Window | Show View | Other | EPIC | RegExp« wartet der Editor für reguläre Ausdrücke. Ein Highlight des sehr einfachen Editors ist, dass er einen regulären Ausdruck auch schrittweise ausführt und Epic dabei den jeweiligen Text anzeigt, den der aktive Ausdruck gerade matcht.

Refactoring ist auch in Eclipse prominent im Menü vertreten. Momentan unterstützt Epic es jedoch nur, um Code aus bestehenden Subroutinen in neue zu übernehmen. Dabei greift es auf das Perl-Modul Devel::Refactor [18] zurück, das sich noch in einem frühen Entwicklungsstadium befindet (aktuell v0.05). Die Epic-Entwickler geben an, Weiterentwicklungen an diesem Modul in ihrem Plugin zu berücksichtigen.

Fazit

Der Mehrwert von Epic besteht sicher darin, dass mit Eclipse vertraute Programmierer mit seiner Hilfe eine umfassende Perl-Unterstützung vorfinden. Interessant ist auch, dass Epic nicht nur lokal installierte Programme bearbeitet und ausführt, sondern im Remote Mode auch jene, die innerhalb des CGI eines Webservers laufen oder auf einem entfernten Rechner. Eclipse bietet obendrauf für alle Arbeitsschritte Plugins an und lässt sich hervorragend in unterschiedliche Szenarien der Einzel- oder Teamarbeit integrieren.

Epic bietet zudem viele Möglichkeiten, umfangreichen Code übersichtlich darzustellen und darin zu navigieren. Wer häufig fremde Perl-Programme umarbeitet, wird dies schätzen. Auch der Perl-Debugger ist bestens integriert und innerhalb einer eigenen View einfach zu bedienen. Die Kommunikation mit den Entwicklern, die den Code laufend pflegen, klappt via E-Mail, Mailingliste und innerhalb eines Forums ausgezeichnet. Die Dokumentation ist übersichtlich gestaltet und nicht durch Details überfrachtet. Neben dem eigentlichen Programmcode pflegen die Epic-Macher auch die Dokumentation sorgfältig.

Die Anwendung ist jedoch sehr gewöhnungsbedürftig, da das häufige Umschalten in den Views für Verwirrung sorgen kann. Anfänger müssen mit einem gewissen Aufwand beim Einarbeiten rechnen, bis sie sich gut zurechtfinden. Wer auf die Performance eines Editors setzt oder gar auf dem Arbeiten in einem Terminal besteht, wird sich beim Umgang mit Eclipse umstellen müssen.

Auf einem durchschnittlichen Arbeitsplatzrechner zeigten sich keine Engpässe oder andere Misslichkeiten, die auf nicht ausreichende Ressourcen zurückgehen. Die Qualität der Ubuntu-Pakete scheint aber nicht die beste zu sein, viele Installationen der Originalpakete führten zu diversen Fehlern. Alternativ lässt sich das Ecplise-SDK unter [23] herunterladen, für das unterschiedlichste Builds existieren. Die Installation der Version 4.5.0 gelang im Test problemlos, sie ließ sich zudem flüssiger bedienen als die aus Ubuntus Standard-Repository.

Resümee

Wer sich oft mit komplexen Perl-Programmen beschäftigen und neu vorliegenden Code rasch überblicken möchte, dem hilft eine IDE in der Tat. Ob er dabei auf den geliebten Editor der Wahl setzt, ihn über Plugins schrittweise zu einer IDE umbaut oder gleich zu einer ausgereiften wie Eclipse mit Epic-Plugin greift, mag Geschmackssache sein.

Dass die unterschiedlichsten Zugangsweisen nebeneinander existieren können, zeigt auch der Umstand, dass für die Editorfunktionen von Eclipse ein Vim-Plugin existiert. Jene, die mit dem Ausbau des Editors hin zu einer IDE stranden, dürften sich hier ein wenig aufgehobener fühlen. Anwendungen wie Padre stehen zwischen diesen beiden Ansätzen, zeigen im Arbeitsalltag jedoch weder die hohe Flexibilität noch den notwendigen Reifegrad, um die verschiedenen Bedürfnisse eines Perl-Programmierers möglichst umfassend abzudecken.

Der Autor

Dr. Harald Jele ist Mitarbeiter an der Universität Klagenfurt. Mit Perl beschäftigt er sich seit 1993 und ist stets überrascht, in welchen Kontexten er darauf stößt.