Der Niedergang von Perl war kein technisches, sondern ein kulturelles Problem

• Perls Rückgang wird als Ergebnis einer konservativen und geschlossenen Entwicklungskultur gesehen, nicht technischer Grenzen.
• Aus der frühen UNIX-Systemadministrator-Kultur stammende exklusive Haltungen und ein „Experten“-Stolz blockierten die Weiterentwicklung der Sprache.
• Die Spaltung von Perl 6 wird als ein Ereignis bewertet, das eher interne Community-Konflikte und Konservatismus zeigte als ein technisches Scheitern.
• Gleichzeitig wuchsen Ruby on Rails, PHP und Python mit einer offenere(n), zugänglicheren Kultur heran und übernahmen Perls Platz.
• Perl bleibt zwar die Kern-Skriptsprache in POSIX-Umgebungen, doch seine Rolle als Hauptsprache der Mainstream-Entwicklung ist deutlich gesunken.

---

Kultureller Ursprung und Grenzen von Perl

• Perl entstand in der UNIX-Systemadministrator-Kultur, dominiert von internen Witzen wie „RTFM“ oder „luser“ sowie abgeschotteten Regeln.
  • Diese Kultur betrachtete Wissensmonopolisierung und das Aufrechterhalten von Einstiegshürden als Tugend und sah Schwierigkeiten selbst als Symbol von Können.
  • Dadurch entstand eine kollektivistische Struktur mit starker Abwehr gegenüber neuen Nutzern oder Veränderungen.
• Diese Haltung wird mit einer „Festungsmentalität“ verglichen.
  • Interne Mitglieder nahmen ihre eigene technische Komplexität als Stolz und nahmen externe Vereinfachungsversuche auf die leichte Schulter.
  • Das führte zu einer klassenähnlichen Struktur, in der nur „Berechtigte“ Zugang hatten.

Struktur der Perl-Community und die Spaltung von Perl 6

• Perl betonte mit dem Prinzip „TIMTOWTDI (There Is More Than One Way To Do It)“ die Flexibilität.
  • Dieses Prinzip verstärkte jedoch den Konservatismus gegenüber Sprachwandel: Die Kerndefinition blieb festgezurrt, und Innovationen wurden an den Rand außerhalb von CPAN verschoben.
  • Die CPAN-zentrierte Erweiterungsstruktur führte zu Dependency Hell (Abhängigkeitschaos).
• Das Auftreten von Perl 6 wurde als Ergebnis interner Konflikte und als Symbol der Spaltung gesehen.
  • Perl 5 setzte auf Praktikabilität und Stabilität, Perl 6 auf Innovation und Idealismus, wodurch eine kulturelle Spaltung entstand.
  • Die Entwicklung von Perl 6 verzögerte sich über 15 Jahre und wurde als das „am stärksten wasserfallartige Open-Source-Projekt“ bezeichnet.
  • In dieser Phase war Perl für neue Entwickler unfreundlich, und die Community wurde zunehmend geschlossen.

Aufstieg konkurrierender Sprachen

• Ruby besaß eine ähnliche Syntax wie Perl, machte aber „Programmierer-Zufriedenheit“ und Freundlichkeit zu Kernwerten.
  • Ruby on Rails erzielte mit entwicklerfreundlichem Tooling und konsistenter Struktur einen explosionsartigen Erfolg.
  • Perl entwickelte mehrere ähnliche Frameworks, scheiterte aber wegen mangelnder Interoperabilität und geringer Einstiegseignung an Verbreitung.
• PHP wurde als „benutzerzentrierte Sprache“ etabliert und erreichte breite Verbreitung durch einfache Installation und Bereitstellung.
  • Als Grundlage für Blog-Plattformen wie WordPress wurde es zur Einstiegssprache einer Generation von Webentwicklern.
• Python startete aus einem akademischen Hintergrund und hielt an schrittweiser Evolution und klaren Designprinzipien fest.
  • Nach der Übernahme durch Google folgte stabiles Wachstum, gestützt durch die Philosophie der „Batteries included (batteries included)“ und deren praktische Wirkung.

Perl heute und sein Erbe

• Perl existiert weiterhin als POSIX-Skriptsprache, die standardmäßig auf den meisten Systemen installiert ist.
  • Es wird in zahlreichen Legacy-Systemen und Automatisierungsskripten weiterhin eingesetzt.
  • Als Standardoption für neue Projekte wird es jedoch kaum noch gewählt.
• Zentrale Innovationen, die Perl hinterlassen hat:
  • Integrierte reguläre Ausdrücke und erweiterte Syntax
  • Paketverteilung über CPAN via Internet sowie Signaturprüfung
  • Verbreitung eines automatisierten Test-Harnesss (TAP) und des CI-Konzepts
  • POSIX-Funktionsintegration, die die Grenzen zwischen Shell und Systemprogrammierung aufhob
  • Dokumentationsinnovation durch das POD-Dokumentsystem

Fazit: Kultur, die Erfolg und Niedergang formte

• Perl erzielte in der frühen Web-Phase der 1990er Jahre explosionsartiges Wachstum, indem es zwei Kulturen (UNIX-Administratoren und Webentwickler) verband.
• Doch ein konservativer Kulturansatz und eine geschlossene Community vermochten sich nicht an den Wandel anzupassen, wodurch Perl den Mainstream verließ.
• Dennoch wird Perl als eine der Sprachen bewertet, die die Grundlage der modernen Softwareentwicklung mitgeprägt haben.
• Der Autor beharrt darauf, dass Perl nicht verschwinden wird: solange POSIX existiert, wird es auch Perl geben.
• Heute gehen aufstrebende Sprachen wie Rust und TypeScript erneut den kulturellen Transformationspfad, den Perl früher durchlaufen hat.

[kh0324]

Sobald in einem Text steht, dass Perl und Ruby eine ähnliche Syntax hätten, zweifle ich an der Eigenständigkeit des Textes. Das ist eine Formulierung, die als Zitat aus klassischen Perl-Kritiken verwendet wird, aber in der tatsächlichen Nutzung habe ich das nie so empfunden. Deshalb habe ich den Eindruck, dass alte Legacy-Kritiken an Perl unkritisch übernommen wurden, weil man den Inhalt grob auffüllt, alte Texte hineinkopiert oder den Rest der KI überlässt.

[GN⁺]

Hacker-News-Kommentar

• Ich fand dieses „Mönche-und-Zauberer“-artige Selbstbild der Perl-Community immer unerquicklich.
  Auch diese Kultur, mit Einzeilern möglichst clever wirken zu wollen, sagte mir nicht zu, und Python wirkte viel ernster und „normaler“.

  • Ich lerne Perl gerade, und es fühlt sich wirklich wie eine von Zauberern gemachte Sprache an.
    Die Syntax wirkt, als sei sie absichtlich komplex entworfen worden, und vieles ist ohne Dokumentation kaum zu verstehen.
    Damals war die Knappheit von Code sicher wichtig, aber im Jahr 2025 ist das einfach zu unzugänglich.
    Es fühlt sich an, als wäre in D&D irgendeine spontane Idee für immer im Regelbuch gelandet.
  • Perl war eine Sprache, die in die Tiefe der Ausdruckskraft investierte, und das Ergebnis war, dass man dieselbe Sache auf 1000 Arten schreiben konnte.
    Python betonte dagegen „einen klaren Weg“ und förderte damit sauberen Code.
    Auch Perl konnte man schön schreiben, aber dafür musste sich der Entwickler bewusst entscheiden.
    Python konnte durch die erzwungene Einrückung selbst Anfängern ein gewisses Maß an Lesbarkeit sichern.
  • Dass die Perl-Community mit CPAN das erste Modul-Repository der Welt geschaffen hat, erkenne ich an.
    Aber die Sprache selbst war so ausdrucksstark, dass das für gemeinsam genutzten Code eher giftig war.
    Für Textverarbeitung ist Perl immer noch hervorragend, aber als Sprache für Zusammenarbeit war es schwierig.
  • Ich habe ein Interview mit Larry Wall gehört, und er wirkte einfach wie ein schrulliger Entwickler, der gern experimentiert.
    Anders als das überzeichnete Bild der Community war seine menschliche Seite beeindruckend.
  • Auch bei Python ging es früher wegen Whitespace-Regeln und Debatten über das Typsystem hoch her.
    Perls Verspieltheit wirkte im Vergleich fast ehrlicher und weniger verbissen.
    Aber am Ende wurde Python Mainstream, und Perl geriet immer mehr in Vergessenheit.

• Ich denke, die dogmatische Kultur der Perl-Community hat den Niedergang der Sprache beschleunigt.
  Ein Freund, der mir früher Linux beigebracht hat, war ein Perl-Fanatiker, und wegen dieser spöttischen RTFM-Haltung gegenüber Unwissenden haben wir am Ende den Kontakt abgebrochen.

• Ich hatte fast keinen Kontakt zur Perl-Community und habe sie einfach in einer Zeit benutzt, in der ich Probleme per Google gelöst habe.
  Symbole wie @ und % waren einfach zu zahlreich, wodurch sie weniger zugänglich als Ruby oder Python wirkte.
  Ruby war von Anfang an als objektorientierte Sprache entworfen und fühlte sich viel natürlicher an.
  Wenn Pythons optionale Typ-Hinweise ungenau waren, stifteten sie eher zusätzliche Verwirrung.

  • Genau das ist ja der Zweck optionaler Typ-Hinweise.
    Wenn sie exakt sein müssten, wäre das bereits ein erzwungenes Typsystem und kein optionaler Hinweis mehr.

• In den 90ern hat jemand auf IRC zu mir RTFM gesagt, aber wie sich herausstellte, war das ein Witz und zugleich eine Anfänger-Willkommensaktion.
  Tatsächlich habe ich mit Perl-Zauberern Kaffee getrunken und Mentoring bekommen, und diese Erfahrung wurde zum Wendepunkt meines Programmiererlebens.
  An einen Satz von damals erinnere ich mich bis heute — „Perl it forward!“

  • Ich weiß nicht, ob das ernst gemeint ist oder ein Witz.
  • Ich würde gern mehr über diese Geschichte von Software Local 2142 hören.

• Dieses Phänomen, dass man Dopamin nach einer anstrengenden Erfahrung bekommt und sie deshalb für eine gute Erfahrung hält, ist in der gesamten Computerbranche verbreitet.

  • Eigentlich scheint genau das das Wesen jeder Entwicklung zu sein.
    Es ist immer verwirrend, und ständig fragt man sich: „Warum wurde das so gebaut?“

• Ehrlich gesagt ist Perl einfach verschwunden, weil andere Sprachen besser waren.

  • Perl war als experimentelle Sprache großartig, aber in der Praxis weniger nützlich.
    So wie man mit einem Prototyping-Board kein Produkt baut, war Perl ein Ergebnis des Experimentierens.
  • Unter der Philosophie „do what I mean“ verbarg sich viel Komplexität.
    Wenn man zum Beispiel @array als Skalar erhält, gibt es nur seine Länge zurück — diese Art von Kontextabhängigkeit gab es häufig.
  • Ich denke, die Einschätzung, Perl sei schlecht, hat sich wie ein bloßes Schlagwort verbreitet.
    Tatsächlich war es eher eine Geschmacksfrage, wie bei Toyota vs. Honda.
  • Ich war Teil der Perl-Community, aber der Grund für meinen Wechsel zu Python war Django.
  • Steve Yegges Text „Ancient Languages: Perl” erklärt die Gründe gut.
    Perls Referenzsyntax, das umständliche OO und die wiederholten Einstellungen wie use strict; / use warnings; waren ermüdend.
    Rails war viel knapper und sicherer, und auch das zeitliche Momentum war perfekt.

• Perl war meine erste große Lieblingssprache, aber 2012 bin ich vollständig auf Python umgestiegen.
  Wenn ich heute in Legacy-Code Perl-Skripte sehe, bin ich erleichtert und denke: „Gut, dass ich gewechselt habe.“
  In Perl-Code gab es fast keine Kommentare, und der übermäßige Einsatz von Regex machte die Lesbarkeit miserabel.
  Solche Muster löse ich heute mit dem objektorientierten Ansatz von Python.

• Ich habe viel Perl benutzt, bin aber wegen der Qualitätsprobleme bei CPAN letztlich zu Python gewechselt.
  CPAN-Module gingen oft kaputt, und man musste sie häufig selbst reparieren.

  • Ich bin zu Python gewechselt, weil die Ausführungsgeschwindigkeit von Perl-Skripten langsam war.
    In den 90ern und frühen 2000ern war der Unterschied ziemlich groß.

• Perl starb, weil andere Sprachen ein Ökosystem wie CPAN bekamen
  und weil Perls flexible Syntax für Zusammenarbeit im Team ungeeignet war.

  • Ich bin zu Ruby gewechselt, und die Erweiterbarkeit von MRI war revolutionär.
    Man konnte Module leicht verteilen, ohne SWIG oder komplizierte Typ-Magie,
    und die endlosen Entwicklungsverzögerungen von Perl 6 waren der entscheidende Schlag.
  • Die Kultur der freien Evolution bei Perl war attraktiv,
    aber in kollaborativen Umgebungen stieg die kognitive Last exponentiell.
    Python lagerte diese Debatten mit dem PEP-System nach außen aus und war dadurch viel effizienter.
  • Abgesehen von npm gibt es selbst heute kaum ein Repository so leistungsfähig wie CPAN.