Springe zum Hauptinhalt Profilbild Hartmut Goebel

Hartmut Goebel

Diplom-Informatiker, CISSP, CSSLP, ISO 27001 Lead Implementer



Anfrage
Logo Goebel Consult

Warum Sie nicht Perl programmiern sollten

Ein Freund hatte angekündigt, es wolle jetzt "richtig" Perl lernen. Ich rat ihm dringend davon ab. Hier, was ich ihm geschrieben habe

Ein Freund hatte angekündigt, es wolle jetzt "richtig" Perl lernen. Ich rat ihm dringend davon ab. Hier, was ich ihm geschrieben habe:

Lieber Freund

es lässt mir keine Ruhe, dass Du Deine Lebenszeit mit so schlechten Dingen wie Perl vertun möchtest.

Ich hab schon mit einigen Programmiersprachen gearbeitet und mir viele angesehen. Perl ist eine der schlechtesten! Perl versagt bei der wichtigen Aufgabe, dem Programmierer zu unterstützen. Im Gegenteil: Perl steckt voll Fallstricke und Undurchdachtem.

Ein paar Beispiele:

Der Rückgabewert vieler Standard-Funktionen hängt vom Aufrufkontext ab. Mal ein Scalar, mal ein Hash, mal ein Objekt.

Durch automatische Typumwandlung fällt man immer wieder auf die Schnauze. Statt der Liste oder dem Hash hast du plötzlich die Anzahl der Elemente darin - oder war es der höchste Index? Damit musst du aber auch denn wissen, was eine Funktion liefert, wenn dich der Wert überhaupt nicht interessiert und du ihn nur an eine andere Funktion weiterreichen willst.

Übergeben von Parametern an Funktionen t eine Krankheit, alles muss der Programmierer selbst schreiben:

  • Die Parameter einer Funktion werden als dumme Liste übergeben, man muss sie selbst den einzelnen Variablen zuweisen. Welche Parameter die Funktion annimmt, *kann* man in einem Prototype festlegen, aber trotzdem muss man die Liste der Argumente weiterhin händisch auswerten.

  • "Named parameter" muss man komplett händisch implementieren, siehe das Beispiel in http://docstore.mik.ua/orelly/perl/cookbook/ch10_08.htm. Wenn der Nutzer der Funktion dann zu viele oder unbekannte Parameter übergibt, gibt es keine Fehlermeldung -- außer der Programmierer hat das extra programmiert. Doppelte Parameter werden dabei gar nicht erkannt.

Dinge die eigentlich der Normalfall sind, muss man ausdrücklich hinschreiben und der Normallfall ist das, was man nur selten will:

  • Dinge, die man eigentlich immer braucht, um sauber zu programmieren muss man extra einschalten: use strict, user warnings.

  • Unausgereiftes Scope-Konzept: Der Normalfall ist eigentlich, dass man lokale Variablen nutzen möchte. Auch hier muss man den Standard Fall wieder mit „my“ angeben.

Eine Klasse zu definieren ist ein religiöser Akt ("bless") und insgesamt umständlich. Es scheint zwar ein Modul zu geben, dass das besser macht, aber da sind wir wieder bei: "einfaches ist umständlich".

  • Zitat vom "perlmaster" aus dem aktuellen Linux-Magazin (8/2016, S. 92): "… niemand, der einigermaßen bei Verstand ist, hätte auch nur in einem mittelgroßen Programm die zu Klassen gestempelten Hashstruktuen […] verwendet."

Das Modulkonzept ist der Sprache aufgepfropft.

Die gesamte Syntax ist unübersichtlich, es gibt keine EBNF o.ä. der Grammatik, "only perl can parse Perl". Für alles Mögliche gibt es eigene Syntax-Konstrukte, die aber keine wirklichen Vorteile bringen. Man merkt, dass Larry Wall Sprachwissenschaftler ist und keine Ahnung von Programmiersprachen hat. Das Ganze ist zusammengestöpselt aus alten Unix-Tools, und so schaut es auch aus.

Kein Exception-Handling, dadurch muss man eval() benutzen, wenn man Fehler abfangen will. Wenn Du einmal erkannt hast, wie elegant man Programmieren kann, wenn es Exception-Handling gibt, möchtest Du es nicht mehr missen. Der Clou ist nämlich, dass man nicht bei jeder Funktion eine Fehlermeldung zurückgeben muss und nicht bei jedem Funktionsaufruf auf Fehler prüfen muss.

Nachgestellte Kontrollstrukturen – lassen sich super einfach lesen.

Ständig muss man kryptische Zeichen vor den Variablennamen schreiben, teilweise mehrere. Was ich mich damit abgekämpft habe.

Ich habe auch ein halbes Jahr mit Perl programmiert. Das war die unproduktivste Zeit meines Lebens. Zum Glück habe ich dann Python entdeckt, siehe auch die ca. 20 Zeilen des "Zen of Python" [1],[2]. Ich spare es mir, aufzuzeigen, dass alle oben genannten Punkte in Python besser gelöst sind, aber zu Parametern empfehle ich einen Blick auf http://www.diveintopython.net/power_of_introspection/optional_arguments.html

Lieben Gruß
Hartmut