Perl-Programmierung: Geschichte

Zurück zu Eintauchen in die Perlenwelt | Hoch zu Inhaltsverzeichnis | Vor zu Larry und die Perl-Kultur

Ursprünglich waren Skripte Textdateien mit Befehlen, die man auch in die Kommandozeile (System-Shell) eingeben könnte. Diese Skripte ließen sich vergleichsweise schnell schreiben und es war damit möglich, Befehle des Betriebssystems mit Programmaufrufen zu kombinieren, um so komplexere Aufgaben dem Computer zu überlassen, ohne in langer Arbeit ein neues Programm zu schreiben. Die Kommandozeileninterpreter, die diese Skripte ausführten, hatten aber wesentlich geringere Fähigkeiten, Daten zwischenzuspeichern oder den Ablauf zu regeln als eine Programmiersprache wie C. Außerdem konnte man in Skripten die Daten nur wie durch ein Nadelöhr von einem Programm hinaus und zum nächsten Programm hinein leiten.

Larry Walls Reaktion auf diese Situation war, einen erweiterten Kommandozeileninterpreter zu schreiben, der nicht nur fast den gesamten Sprachschatz von C beherrscht, sondern auch viele der kleinen nützlichen Helferlein kopiert, besonders sed, awk und grep, die die Kommandozeile des Betriebssystems UNIX so mächtig machen. Damit lassen sich viel mächtigere Skripte schreiben, die Textdateien durchsuchen und die von anderen Programmen ausgespuckten Ergebnisse sortieren und aufbereiten können. Aus diesem Grund nannte man PERL auch eine: 'Practical Extraction and Report Language' (praktische Auszugs- und Berichtsprache), was aber nur ein Backronym ist, weil die ursprüngliche Bedeutung des Namens Perl eine andere ist (siehe nächstes Kapitel). Ein anderes Backronym, das von Larry ebenso für „offiziell“ erklärt wurde, ist: 'Pathologically Eclectic Rubbish Lister' (krankhaft wahlloser Auflister von Blödsinn), denn mit Perl kann man wirklich sehr sehr unverständliche Programme verfassen. Warum das so ist, erklär' ich auch im nächsten Kapitel.

Mit der Zeit lernte Perl auch mit binären Daten umzugehen und viele weitere nützliche Dinge, die überall abgeschaut wurden. Besonders mit seiner fünften Version veränderte sich Perl zu einer „richtigen“ Programmiersprache, als nicht nur die objektorientierte Programmierung eingeführt wurde, sondern auch die diesem Konzept zugrunde liegenden Module. Diese Module, die Perl meist um eine wertvolle Fähigkeit ergänzen, zum Beispiel graphische Ausgabe, Herunterladen von Webseiten oder Steuern von Robotern, findet man in großer Anzahl und in oft sehr guter Qualität in dem zentralen Archiv namens CPAN. Kritiker und Anhänger von Perl sind sich zumindest darin einig, dass der Erfolg von Perl heute zu einem bedeutenden Teil am CPAN liegt, mit dessen Hilfe man auch anspruchsvollere Aufgaben in nur wenigen Zeilen Quellcode lösen kann, indem man mehrere fertige Module kombiniert.

Das entspricht eigentlich immer noch dem ursprünglichen Prinzip des „Skriptens“, obwohl sich dieser Begriff erweitert hat auf eine Bedeutung, die man etwa mit kürzeres, schnelleres, komprimiertes Programmieren übersetzen kann. Neben Perl entstanden nämlich noch seit den 80er Jahren eine Reihe weiterer „Skriptsprachen“ wie Ruby, Python, PHP, Tcl, Visual Basic Script, die dem Programmierer einiges an Arbeit abnehmen oder vereinfachen. Manche Autoren sehen darin eine „nächste“ oder „höhere“ Generation an Computersprachen, die sich noch näher an den Bedürfnissen der Programmierer orientieren und noch weniger an den konkreten Fähigkeiten einer Maschine.

Auch eine wichtige Gemeinsamkeit dieser Skriptsprachen ist, dass es Interpretersprachen sind. Das sind Sprachen, bei denen das Programm immer noch einen Interpreter benötigt, der den Quellcode ausführt. Ein Vorteil daran ist, dass man keinen weiteren Aufwand treibt, um ein lauffähiges Programm zu bekommen. Nur den Quellcode schreiben und das Programm ist fertig. Es läuft sogar meist unverändert auch unter anderen Betriebssystemen. Man braucht dafür nur einen neuen, unter diesem Betriebssystem lauffähigen Interpreter. Dieser Vorteil wurde aber lange Zeit wenig genutzt, weil diese Interpreter zu langsam waren, was aber mit den hohen Geschwindigkeiten neuerer Hardware ausgeglichen wird. Außerdem erkannte man mittlerweile, dass interpretierte Programme viel besser optimiert werden können als kompilierte, weil zum Zeitpunkt der Ausführung sehr viel mehr über den aktuellen Computer bekannt ist als bei der Programmierung.

Zurück zu Eintauchen in die Perlenwelt | Hoch zu Inhaltsverzeichnis | Vor zu Larry und die Perl-Kultur