Bloonix und Perl – wohin geht die Reise
Eine etwas persönliche Story zu: Bloonix und die Zukunft von Perl 🙂
Jeder, der mich – Jonny – persönlich kennt, weiß, dass ich ein absoluter Perlfanatiker bin und das zum Trotz des „writeonly“ Rufes, den Perl seit Jahren verfolgt. Um den Ruf habe ich auch nie viel gegeben, denn schlechter Code lässt sich in jeder Sprache schreiben. Darüber hinaus haben mich die Sigils nie gestört, sondern haben den Code teilweise lesbarer gemacht.
Perl begleitet mich nun schon seit 12 Jahren im Job. Als ich mich damals zwischen Perl, Python, Ruby und PHP entscheiden wollte, fiel die Entscheidung auf Perl. Der Grund war einfach: ich suchte eine Sprache, mit der ich in der Systemadministration und auch im Webumfeld arbeiten konnte. Hauptsächlich war mir das Parsen von Texten wichtig, zum Beispiel von Logfiles, Programmausgaben usw. Perl war und ist noch immer das non plus ultra, wenn es um Regular Expressions geht, um Rückwärtskompabilität und ganz besonders bei CPAN. Guido van Rossum, der Erfinder von Python, sagte selbst einmal in einem Interview: „CPAN rules“.
Bloonix ist aus diesen Gründen vor 10 Jahren in Perl entstanden und besteht heute aus ca. 85000 Zeilen Perlcode. Viele Teile von Bloonix wurden selbst entwickelt. Hier eine kurze Liste der Module, welche die Basis von Bloonix darstellen:
Bloonix::DBI – Ein Interface zu Perls DBI
Bloonix::Config – Ein Plugin zum Parsen einer speziellen Konfigurationssyntax
Bloonix::Dispatcher – Jobs auf mehrere Prozesse aufteilen
Bloonix::FCGI – ein eigener Wrapper für FCGI
Bloonix::Heaven – Das Webframework von Bloonix
Bloonix::IO::SIPC – Client/Server Zeugs, serialisierte + verschlüsselte Kommunikation
Bloonix::IPC::Run – Systemcalls, (Timeout Handling, splitten von STDOUT + STDERR)
Bloonix::IPC::SharedFile + SharedMem – Speziell für Interprozesskommunikation
Bloonix::SQL::Creator – Um SQL Statements zu bauen
Bloonix::Plugin – das Basismodul für die Plugins (Checks) von Bloonix
Bloonix::ProcManager – Ein Prozessmanager (Forking nach Auslastung)
Bloonix::Timeperiod – Parsen spezieller Zeitangaben
Bloonix::Validator – Um Webforumlare oder JSON-Daten zu validieren
Jeder, der sich jetzt fragt, warum ich denn nicht auf vorhandene Perl Frameworks zurückgegriffen habe, ist die Antwort sehr einfach. Damals war zum Beispiel das Webframework Catalyst sehr populär. Ein großes Minus waren allerdings die Abhängigkeiten des Frameworks. Die meisten Module mussten von CPAN direkt installiert werden, weil es keine fertigen Pakete für Debian oder CentOS gab. Da ich aber schon immer den Anspruch hatte, Bloonix über einen Paketmanager komplett mit allen Abhängigkeiten installieren zu können, hätte ich sehr viele Perl Module für Debian oder CentOS bauen müssen. Oben drauf kommt noch, dass mir oft Features gefehlt haben oder ich mit dem Featureset bestehender Frameworks nicht zufrieden war.
Soviel zu Bloonix und Perl 5.
Seit einigen Monaten macht sich in mir der Gedanke breit, Bloonix eventuell in einer anderen Sprache neu zu entwickeln. Dieser Gedanke, der sich immer mehr manifestiert, hat verschiedene Gründe, auf die ich nachfolgend eingehen möchte.
Ein etwas weniger bedeutsame Grund ist die immer weiter steigende Anzahl von Anfragen und Diskussionen im Web: „The future of Perl“, oder „The Fall of Perl 5“. Natürlich sind die CPAN Commits nach wie vor unumstritten gut, aber selbst ich merke im Bekanntenkreis und auch bei Kunden, dass verstärkt auf andere Sprachen gesetzt wird und man versucht, den „Legacy“ Code, der in Perl 5 entwickelt ist, loszuwerden. Währenddessen werden Applikationen und Skripts in Python/PHP/Java eher auf neue Versionen aktualisiert. Vielleicht ist das auch nur eine subjektive Wahrnehmung meinerseits.
Noch weniger bedeutsam sind die komischen Blicke, die man sich einfängt, wenn man erzählt, dass man etwas in Perl entwickelt hat 🙂
Der Hauptgrund ist, dass die Zukunft von Perl 5 ungewiss ist, gerade mit Blick auf Perl 6.
Anfang des Jahres 2015 kam die lang erhoffte Meldung, dass das Release 1.0 von Perl 6 zu Weihnachten 2015 erscheint. Die Nachricht hatte mich sehr gefreut und das war einer der Gründe, weshalb mich meine Neugier im August 2015 auf den Swiss Perl Workshop 2015 trieb. Nicht nur das Larry Wall persönlich dort war, es gab dazu noch jede Menge Talks über Perl 6.
Zunächst einmal muss ich zugeben, das die Features von Perl 6 wirklich top sind, gerade im Bereich Threading und Parallelisierung hat sich extrem viel getan. Trotz Allem war das, was ich von Perl 6 gesehen habe, eine große Enttäuschung für mich. Was mich an Perl 6 so enttäuscht hat, möchte ich gerne an ein paar Stücke Code zeigen:
%!seats{@seat-labels}
self < 0 ?? -1 !! self == 0 ?? 0 !! 1
die "No such seat" unless %!seats{$seat}:exists;
Wem nicht klar ist, worauf ich hinaus möchte: es sind die Sonderzeichen. Ja, Perl 5 selbst war schon reich an Sonderzeichen, aber Perl 6 hat das allem Anschein nochmal getoppt und das stört mich enorm.
Entscheidend war auch die Frage in einem Talk auf dem Swiss Perl Workshop, wie lange es Perl 5 nach dem Erscheinen von Perl 6 noch geben wird. Klar, dauert es Jahre, wenn nicht Jahrzehnte, bis alles, was es so auf CPAN gibt, es auch in Perl 6 geben wird, dennoch vermute ich eine Spaltung der Community, denn nicht Jeder - und dazu gehöre auch ich - hat die Zeit, sich für 2 Sprachen zu engagieren. Oder wird Perl 6 vielleicht eine komplett eigene Community haben? Das kann ich mir ehrlich gesagt nicht vorstellen, zumal wahrscheinlich viele Entwickler von Perl 5 auf Perl 6 umsteigen und alte Module in Perl 5 nicht weiter pflegen werden. Heißt das auf lange Sicht, dass Perl 5 doch in naher oder weiter Ferne das zeitliche segnet, wenn immer weniger Module in Perl 5 entwickelt oder weiter supportet werden? Ich weiß es ehrlich gesagt nicht.
Diese vielen offenen Fragen und Hirngespinste - sind sie das tatsächlich? - sind mir persönlich ein Dorn im Auge. Das ist auch einer der Hauptgründe, weshalb ich angefangen habe, Python zu lernen.
Da ich in den letzten 12 Jahren hauptsächlich in Perl entwickelt habe, war es mein Wunsch, mal etwas anderes auszuprobieren und habe angefangen, die Basis für die Plugins von Bloonix (Bloonix::Plugins) in Python neu zu entwickeln. Ich muss zugeben, dass es mir sehr viel Spass macht, Code in Python zu schreiben. Was ich auch sehr ulkig finde ist, dass ich nach 1 Woche Python Code etwas bestürzt war, als ich mal wieder in ein Perl Modul blickte. Der Unterschied von vielen bis zu wenigen Sonderzeichen ist mir da besonders stark aufgefallen.
Wie die Zukunft von Perl aussieht, weiß ich nicht und kann wohl niemand genau sagen. Was ich auch noch nicht so genau weiß ist, welche Auswirkungen mein Gefallen an Python auf Bloonix haben wird. Sicher ist auf jeden Fall, dass sich 85000 Codezeilen nicht von Heute auf Morgen neu entwickeln lassen. Da ich aber bereits dabei bin, Bloonix::Plugins in Python neu zu schreiben, wäre der erste Schritt getan und es folgen in den nächsten Monaten/Jahren bestimmt weitere. Dabei kommt es ganz darauf an, wieviel Zeit ich in die Neuentwicklung investieren kann.
Perl ist noch immer die Sprache meiner Wahl, aber Python ist eine Alternative, die vieles ändern wird.
Das waren ein paar Worte zu: warum Perl; wie groß ist das Projekt; Perl 5; Perl 6; Python; und wohin eventuell die Reise mit Bloonix geht 🙂
Viele Grüße
Jonny
