Naja, so anders dann doch nicht. Aber nach den Strapazen sowohl im Studium als auch im Job, hab ich meinem Wissensdurst einfach mal freien Lauf gelassen und mich mit Python und Webanwendungen mit Python beschäftigt. Das ist bei mir so. Wenn mich erstmal etwas gepackt hat, dann lass ich da nicht los. Das ist eine meiner Stärken – schon oft hab ich dann später von den Dingen profitiert, die ich einfach mal so aus Spaß ausprobiert hab – und genau so eine Schwäche, weil es mich auch davon abhält, die Sachen anzugehen, die gerade anstehen. Jetzt zum Beispiel weitermachen mit Web-Programmierung oder Mathe.
Python ist zwar nicht Bestandteil des Moduls Web-Programmierung, aber sich damit zu beschäftigen ist ja auch nicht völlig fachfremd. Daher hab ich meinem inneren Drang nachgegeben und mich etwas intensiver mit der Sprache und den Frameworks auseinandergesetzt.
Bei mir in der Firma wird vor allem mit Java (serverseitig und interne GUIs) und Delphi (Client- und Stand-alone-Anwendungen) gearbeitet. Die Kompetenz von uns Entwicklern liegt also eindeutig auf diesen beiden Sprachen, was dazu führt, dass auch kleine interne Tools wie Datenkonvertierung, Transformation von HTML-Seiten etc. damit erledigt werden. Dabei hatte ich aber schon immer das Gefühl, dass das manchmal alles viel zu umständlich und langwierig ist.
Delphi (wobei ich hier nur von der Win32-Version rede) ist z.B. ein hervorragendes Tool, um schnell eine GUI zusammen zu klicken und bietet unheimlich viele ausgefeilte GUI-Komponenten mit denen man Eindruck schinden kann. Aber wenn man die Standard-Bibliothek von Java gewohnt ist, fühlt man sich in Delphi immer ein bisschen behindert.
Java hat nicht nur eine große Standard-Bibliothek sondern auch noch eine riesige Auswahl an Open-Source-Bibliotheken (siehe z.B. Apache), die einem das Programmiererleben erheblich erleichtern können. In Java tendiert man meiner Meinung nach immer ein bisschen dazu, die Sache erst zu verkomplizieren, indem man noch eine weitere Zwischenschicht einbaut, das Problem noch einmal kapselt, etc. bis man dann an einem Punkt ankommt, wo alles zusammengenommen wieder alles vereinfacht wird. Mit Spring z.B. kann das dann auch sehr elegant sein und richtig Spaß machen, wenn man das einmal verstanden hat.
Um Daten in Textdateien zu SQL-Scripten zu konvertieren oder ein paar Anker in HTML-Dateien einzufügen erscheint mir diese Herangehensweise aber etwas zu schwerfällig.
Als ich also genau vor der Aufgabe stand, einen Haufen HTML-Dateien (dabei handelte es sich um ein von einer Webagentur nach HTML konvertiertes Fachbuch) so aufzubereiten, dass sie in unser Client-Server-Produkt integriert werden konnten, arbeitete ich mich ein wenig in Perl ein. Im Endeffekt waren nur ein Dutzend reguläre Ausdrücke enthalten, die ein paar Ersetzungen vornahmen, wie Anker oder Links einfügen, und ein Inhaltsverzeichnis als Suchgrundlage erzeugten. Alles andere war von der Agentur schon super gelöst. Das Ergebnis war ein Perl-Skript mit ca. 100 bis 200 Zeilen.
Allerdings konnte ich mich nie so richtig mit der Perl-Syntax anfreunden. Ein tieferes Verständnis dieser Sprache blieb mir verwehrt, was dazu führte, dass ich bei der nächsten Auflage des gleichen Fachbuchs, doch wieder zu Java griff. Diesmal waren die Voraussetzungen nicht so gut. Die HTML-Dateien waren ohne Sinn und Verstand mit Framemaker generiert, ein Großteil der Tabellen und Bildunterschriften fehlte völlig und musste manuell nachgetragen werden. Das Layout war auch entsprechend katastrophal und eine Aufteilung der Kapitel in kleinere Seiten musste auch noch gemacht werden. Zu jedem Kapitel gab es nur eine große HTML-Datei. Der einzige Vorteil: Durch die automatisierte Generierung wurden immer wieder die gleichen Konstrukte erzeugt, die dann leicht durch ein Programm erkannt und angepasst werden konnten.
Leider musste ich feststellen, dass mich mein mangelndes Perl-Verständnis daran hinderte, meine Vorstellungen in dieser Sprache zu realisieren. Ich konnte mich einfach nicht in Perl ausdrücken und war in der Zwickmühle. Entweder meine Perl-Kenntnisse “on-the-fly” erweitern und hoffen, dass es schon werden wird ohne mich zu verzetteln oder Java zu nehmen (hier konnte ich meine Gedanken ausdrücken) und nach entsprechenden Bibliotheken zu suchen, die zur Problemlösung effektiv beitragen konnten. Unter entsprechendem Zeitdruck entschied ich mich für die Java-Version. Neben der eingebauten Unterstüztung für reguläre Ausdrücke gibt es mit Jakarta ORO auch Unterstützung für Perl-kompatible reguläre Ausdrücke. Und mit NekoHTML hatte ich einen HTML-Parser, der auch mit nicht so korrektem HTML klar kam und vor allem keine automatischen “Verbesserungen” am HTML-Code vornahm. Zum Schluss hatte ich ein recht komplexes Transformationsprogramm, dass in mehreren Durchläufen aus den exportierten Framemaker-HTML-Dateien inklusive manueller Ergänzungen meine gesplitteten und aufbereiteten Ergebnis-HTML-Dateien erzeugte.
Das gleiche Programm wurde zwar später nochmal von zwei Studenten für ein ähnliches Projekt angepasst, aber im Prinzip war es ein Wegwerfprogramm.
Ein Wegwerfprogramm, das meinem Gefühl nach an vielen Stellen zu umständlich war (vom Code her). Aber ich wusste nicht, wie ich es in Java besser, sprich einfacher, hätte formulieren können.
In der Zeit danach beschäftigte ich mich immer wieder ein wenig mit diversen Script-Sprachen wie Ruby, Groovy oder Python. Ruby vor allem wegen Rails. Groovy wegen der Nähe zu Java und Grails und Python, weil ich schon immer wissen wollte, was für einen Sinn es hat, in einer Programmiersprache die Einrücktiefe zu einem wesentlichen Bestandteil der Syntax zu machen.
Nur bei Python hat es bisher Klick gemacht. Schon bei meinen ersten ganz einfachen Skripten fühlte es sich irgendwie “richtig” an. So einfach und doch so mächtig. Also setzte ich Python auch für einige winzige Aufgaben auf Arbeit ein, las ein paar Tutorials. Das Buch Python – Essential Reference half mir, dann noch etwas tiefer einzusteigen.
Mittlerweile bin ich ein richtiger Python-Fan geworden.
