Perl ist die universelle Programmiersprache mit ausgeprägten Stärken in der TextVerarbeitung, der Datensynchronisierung und der InternetProgrammierung. Als InterpreterSprache ist sie für schnelles Prototyping geeignet, wobei sich der Performanceverlust durch Compilation und Ausführung eines Zwischencodes in Grenzen hält. Aber mit ein wenig Selbstdisziplin ist es kein Problem, auch recht große Programme damit zu schreiben, und sie gut lesbar, flexibel, wartbar und erweiterbar zu halten.

Man kann in Perl auch objektorientiert programmieren, wobei man ein wenig merkt, daß in Perl OOP nicht von Beginn an dabei war, sondern erst nachträglich hinzugefügt wurde. OOP in Perl ist recht einfach gehalten, aber sehr flexibel, und bietet sogar Mehrfachvererbung.

Perl ist OpenSource.

In Perl gibt es diverse Module für eigentlich sehr viele Bereiche der Programmierung. Weitere Infos gibt es unter http://www.perl.com/. Die Module gibt es unter http://www.perl.com/CPAN/ oder man kann Pakete auch direkt auf der Konsole mittels folgenden Zeilen installieren:

# perl -MCPAN -e shell cpan> i/Tie::DBI/ # regex suche nach Tie::DBI ... Module Tie::DBI (L/LD/LDS/Tie-DBI-1.01.tar.gz) cpan> install Tie::DBI # installation von Tie::DBI ... /usr/bin/make install -- OK cpan> help # sehenswert :)

so werden die Sourcen automatisch heruntergeladen, kompiliert, getestet und installiert.

Siehe auch:

• PerlResourcen,
• /PerlFürBasicProgrammierer
• /Fragen

Stärken:

• dynamische Arrays und Hash-Tabellen (einfacher als in C++ oder Java)
• Komplexe Datenstrukturen.
• mächtige Textverarbeitungsfunktionen (u.a. Regular Expressions)
• Für viele Problemstellungen sind vorgefertigte Module in einem zentralen, offenen Repository (CPAN) im Sourcecode verfügbar
• Tools, die das automatische Installieren und Auflösen von Abhängigkeiten unterstuetzen
• Auf vielen Plattformen verfügbar
• Grafische Benutzeroberflächen
• Es gibt eine Tk-Anpassung für Perl --rae und ua. Win32::GUI --ru
• Anbindung an Gnome via Gtk - das GimpToolkit?
• Anbindung an KDE via PerlQt? - Zugriff auf die Qt-Bibliotheken
• weiterhin: Win32::GUI, WxPerl? ...
• ausdrucksstark, so dass der Programmierer die dem Kontext des Problems oder seinem Wissen entsprechende beste Möglichkeit auswählen kann
• Gute Lesbarkeit. Syntaktische Abkürzungen und umfangreiche Modulbibliotheken ersparen eine Menge Code.
• Die Speicherverwaltung wird nicht dem Programmierer aufgebürdet.
• Einbinden vieler weiterer Programmiersprachen möglich (z.B. auf C via XS oder Inline::C, und auch für viele andere Sprachen gibt es Module, die meist mit Inline:: beginnen)
• Man kann Code on-the-fly generieren (z.B. AUTOLOAD, Sub::Installer, ...) oder bestehenden Code verändern (z.B. mit Sourcefiltern)
• Man kann einfache Variablen an Klassen binden (Ties), über die hinter den Kulissen irgendwelche Magie stattfindet, z.B. Tie::File
• ...

• Schlechte Lesbarkeit: Es gibt in Perl extrem viele (zuviele) Möglichkeiten, dasselbe auszudrücken. Die Sprach-Konstrukte sind im Vergleich zu anderen SkriptSprachen mit ähnlichen Anwendungsgebieten leider nicht orthogonal und auch für Aussenstehende selbsterklärend.
• Perl hat keine "flachen" Datenstrukturen ("struct" in C), sie müssen bei Bedarf mit Arrays (nur indizierte Elemente) oder Hashes (benannte Elemente mit langsamerem Zugriff und größerem Speicherbedarf) nachgebildet werden.
• Perl arbeitet nicht mit Funktionsprototypen. Parameter einer Funktion werden als Array übergeben und werden meist manuell in einzelne Variablen zugewiesen.
• Perl unterstützt auch Funktionsprototypen. Allerdings kann nur zwischen Strings, Arrays, Hashes (und Referenzen darauf) und Subroutinenreferenzen unterschieden werden, sodass eine strikte Parameterprüfung wie z.B. in SpracheCpp nicht möglich ist. --cg
• Technisch-/mathematische Aufgabenstellungen
• Was will die obige Zeile aussagen? Ich sehe weder eine Stärke noch eine Schwäche in Technisch-/mathematische Aufgabenstellungen. Den Bezug zu Perls Schwächen (oder Stärken) kann ich da nicht erkennen.
• "obfuscated perl contest" freundliche Syntax (siehe SpracheCee).
• Diversifikation des Modulsystems.
• Es gibt zu viele Abhängigkeiten. CPAN/CPANPLUS und weitere Module kümmern sich darum, daß diese den Programmierer nicht belästigen müssen.
• Die Speicherverwaltung wird nicht dem Programmierer aufgebürdet.
• Komplexe Datenstrukturen.
• Nach einigen Jährchen Entwicklung leakt das ganze immer noch. Und perl6 mit sicherer und schnellerer GarbageCollection anstatt ReferenceCounting dauert immer noch. Thread-Safety: naja.
• Bei Threads muss man tatsächlich darauf achten, keine Memoryleaks zu coden. Wenn man jedoch Threads nicht verwendet, leakt (ausser eventuell bei schlampig programmierten C-Bibliotheken) nichts, wenn man einigermaßen sauber arbeitet. Und auch bei Perl6 wird voraussichtlich ReferenceCounting verwendet. --MartinFabiani
• ...

• Verarbeitung von Textfiles, Office-Dokumente
• InternetProgrammierung bzw. CgiProgrammierung
• Mailprocessing, Spamfilter und Contentfilter
• Datensynchronisierung (z.B. für MetaDirectory?)
• Systemadministration und Fernsteuerung von externen Anwendungen
• GUI-Anwendungen
• Grafikbearbeitung (TheGIMP?, GD, ImageMagick?, ...)
• Middleware, Datenbanken, Verzeichnissysteme
• IP- und Telefonie-Billing
• RapidPrototyping
• Software Tests
• ...

...jeden Teil der Programmierung... Also Spieleprogrammierung oder BildVerarbeitung möchte ich in Perl nicht unbedingt machen...

BildVerarbeitung und ComputionalGeometry? hab ich in perl gemacht. Alles geht. Allerdings war der Aufwand die XS Extensions zu schreiben recht groß. Ich brauchte erst typisierte Arrays um den Platzbedarf und die Geschwindigkeit in Griff zu kriegen. Irgendwo auf meiner Homepage ist Geometry und Tie::CArray. Beim zweiten Versuch hab ich's dann in Lisp gemacht. Das war viel einfacher und eleganter. --ReiniUrban

zu Spieleprogrammierung: wenn die Spiele grafisch nicht besonders aufwendig sind, ist es mit Perl durchaus möglich, Spiele zu entwickeln, siehe z.B. http://www.fabiani.net/ -> Downloads -> Tk-Mines. Wenn die Spiele aufwendiger werden, wird Perl pur meist etwas langsam. Wenn man es schafft, die Berechnungen z.B. in C auszulagern, spricht jedoch nicht besonders viel dagegen. Ein Bekannter schreibt sogar einfache OpenGL-Programme in Perl. --MartinFabiani

Es gibt dazu einen ausgezeichneten Artikel (leider nur in Englisch) von LarsMariusGarshol?, der dieses Thema ausführlicher beleuchtet, als ich es hier tun kann: http://www.garshol.priv.no/download/text/perl.html -- PeterFunk

Ohne weitere Diskussionen entfachen zu wollen. Ich halte es für höchst irrelevant, was jemand sagt, der eine Logfile-Auswertung in Perl geschrieben hat und nun meint, er habe die Aufgabe, Obfu-Beispiele (für ihn Obfu) zu sammeln, um Perl als eine Sprache darzustellen, in der man nichts lesbares verfassen könnte. Dabei sind seine Beispiele nur aus 2 Gründen für ihn "obfuscated": a) Er kennt den Konstrukt nicht oder b) Der Code ist vom Autor durch irreführende Variablenbezeichner und zu wenig Whitespace unlesbar gemacht worden. Nein, unter objektiver Kritik verstehe ich etwas anderes.

Ein deutschsprachigen Artikel zu dem Thema habe ich hier gefunden: http://www.ndh.net/home/sschwarzer/python/perlpy_vortrag.html -- PeterFunk

Er meint wohl, daß perl ziemlich überladen ist, im Verein mit 'kryptisch'. das heißt, man sollte das nicht so total wörtlich nehmen.

Daß perl ziemlich überladen (wie auch zsh) und kryptisch ist, ist durchaus auch meine Meinung.

Ich meine, man kann zudem Interpreter-Sprachen kaum mit klassischen Compiler-Sprachen vergleichen, denn perl ist eine Mischung von 5-10 dieser klassischen Sprachen.--hs

Ich meine nicht: an Datentypen überladen, sondern an Syntaxformen überladen.

     $value =~ s/xyz/pack("C",hex($1))/eg;

Das mal als Beispiel - Da ist für mich eine Grenze überschritten.

     pack :e C `hex $1`
     subst :value xyz $e

finde ich als (kurz ausgedachte) Kommandoform lesbarer.

Auch daß fast das ganze \Alphabet bei den REs Spezialsequenzen bildet, ist auch ein wenig viel. --hs

Also.

     $value =~ s/xyz/pack("C",hex($1))/eg;

Ist zunächst einmal nur _eine_ Möglichkeit, klar. Lesbar ist es trotzdem, für jemanden der Perl ein wenig kennt. Vielleicht würde so mancher gar nicht auf die Idee kommen, irgendetwas zu kritisieren, wenn dort stünde

     $value =~ s{
               xyz
         }{
               pack( 'C' => hex($1) )
         }xeg;

Das ist völlig gleichbedeutend. Das Problem ist bei dieser Diskussion, dass manche gerne etwas als kryptisch abtun, nur weil sie es nicht kennen und ihnen zu wenig Buchstaben drin vorkommen. Wer Perl kennt, weiß das und diese Argumente fallen schlichtweg aus, ganz objektiv.

Kryptisch ja, aber nur, wenn man auch kryptisch programmieren will. Perl lässt den Programmierer machen was er will und schränkt ihn so wenig wie möglich ein. Man kann Programme schreiben, die aussehen wie SpracheCee oder aber SpracheSh. Wer will, kann wirklich unlesbaren SpaghettiCode oder aber gut strukturierte nachvollziehbare Programme erstellen. ThereIsMoreThanOneWayToDoIt. --ChristianGarbs

Ich finde es schwierig, mit Perl einen Stil einzuhalten, will man etwa eine Exception (oder einen Programmabruch) erreichen, wenn open fehlschlägt, hat man die Auswahl zwischen folgenden "Stilen":

        die unless open(...);
        die if not open(...);
        unless (open(...)) { die; }
        if (not open(...)) { die; }
        open(...) or die;
        open(...) || die;
        not open(...) and die;

        system(...) and die; 

In Perl hat man die Freiheit, entweder Exceptions zu verwenden oder keine Exceptions zu verwenden... Eine weitere Möglichkeit ist, keine Fehlerabfrage zu machen und stattdessen Fatal (z.B. use Fatal qw(open close); ) zu verwenden. Dann muss man sich nicht entscheiden ;-) Ich verwende meist eins der folgenden Konstrukte:

    die "Error: couldn't open file '$filename' for reading: $!\n";

oder auch:

open( my $FH, '<', $filename )

    or die "Error: couldn't open file '$filename' for reading: $!\n";

my $content = do {

    open( my $FH, '<', $filename )
        or die "Error: couldn't open file '$filename' for reading: $!\n";
    local $/; # auf undef setzen, d.h. alles wird auf einen Rutsch eingelesen
    <$FH>;

--MartinFabiani

Exceptions kann man in Perl auch sehr gut nutzen und das schöne daran ist, dass man es nicht muss, aber kann.

        eval {
             open ... or die "wasauchimmer $!";
        }
        if( $@ ){
             #$@ ist die "Exception"
        }

Fast Java-like kann man es mit dem Exception Modul ( http://search.cpan.org/author/PJORDAN/Exception-1.4/Exception.pm ) machen. TIMTOWTDI

Oder meiner Meinung nach noch schöner mit Exception::Class ( http://search.cpan.org/~drolsky/Exception-Class-1.23/lib/Exception/Class.pm ). TIMTOWTDI

Perl hat keine DatenStrukturen?, sie müssen bei Bedarf mit Arrays oder Hashes nachgebildet werden

Dieser Einwand leuchtet mir nicht ein. Arrays und Hashes sind doch Datenstrukturen. Und aus den eingebauten Datenstrukturen können komplexere Datenstrukturen aufgebaut werden. So funktioniert es auch in den höher entwickelten Programmiersprachen. Was ist hier mit "nachbilden" gemeint?

Ich habe oben ergänzt, was der OP wahrscheinlich gemeint hat. Für den echten Perler ist das wahrscheinlich unerheblich, aber zwischen:

// C struct Bildpunkt { char r,g,b; }; x=Bildpunkt.r; # Perl my %Bildpunkt = { 'r'=>17, 'g'=>255, 'b'=>87 }; $x=$Bildpunkt{r};

liegen so große Unterschiede in der tatsächlichen Realisierung (C: direkter Zugriff / 3 Byte - Perl: hash-code-Zugriff ca. 10+ allokierte Speicherblöcke ca. 160+ Byte), dass Perl z.B. für Aufgaben der Bildverarbeitung ausscheidet. Zumindest lassen sich die Perl-Datenstrukturen so nicht einsetzen. --hl

Ich denke, es ist relativ unsinnig, das abzustreiten oder Perl zu verteidigen. Es ist aber genauso unsinnig, diese Dinge als Schwächen der Sprache zu deklarieren: Wer zeitkritische und rechenintensive Aufgaben, z.B. komplexe Grafikanwendungen, mit Perl ernsthaft anfängt, ist selbst schuld, denn es ist einfach die falsche Sprache dafür. Perl dient zur Lösung wesentlich abstrakterer Probleme und höhere Abstraktion fordert eben ihren Tribut in Form von weniger effektivem Rechenvorgehen. Wenn mir diese Millisekunden so wichtig sind, verwende ich SpracheCee und brauche halt drei mal so lange, um den Code zu entwickeln. Wer fällt denn Bäume mit seinem Schweizer Taschenmesser?

Ich verwende SpracheCee um zeit- und speicherkritische Programmteile zu implementieren und binde diesen als shared Object ein. Den Rest programmiere ich effektiv mit wenig Zeit in Perl. Perl taugt auch zum number crunching, siehe {{ http://pdl.perl.org/}}. Perl ist nicht ein sondern auch ein schweizer Taschenmesser, vor allem aber ein mächtiges Universalwerkzeug und Kleber zwischen ganz unterschiedlichen Sprachen.

Ein paar Anmerkungen zu den Aussagen

• "Schlechte Lesbarkeit": Perl ueberlaesst es wie kaum eine andere Sprache dem Programmierer, wie er sich ausdruecken will. Und eben durch diese Freiheit hat man die Freiheit, in Perl klareren Code zu schreiben als in Sprachen, die versuchen, diese Klarheit zu erzwingen. Jeder Programmierer ist also selbst für die Lesbarkeit seines Codes verantwortlich, und wenn jemand aus Unwissenheit oder Nachlaessigkeit keinen gut lesbaren Code produzieren kann/will, kann man das Perl nur in folgendem Gebiet anlasten: Bei Perl kann man mit sehr wenig Mitteln schon recht viel machen, leider aber auf eher haessliche Weise. Aber die Lernkurve ist lang, und nach einiger Zeit des Lernens erkennt man dann die Moeglichkeiten zur Eleganz und Lesbarkeit, die Perl bietet. (Wenn viele der Autofahrer schlecht fahren, kann man dies wohl nicht den Autos anlasten...)
• "Diversifikation des Modulsystems: Es gibt zu viele und zu viele Abhängigkeiten": fuer Perl gibt es sehr viel mehr Module (=Libraries) als z.B. fuer Python oder PHP. Manche Module sind hervorragend gepflegt, bei manchen frage ich mich auch, wieso sie nicht aus CPAN geloescht werden. Zu den Abhaengigkeiten: ein professioneller Programmierer wird wohl nur in zwigenden Gruenden das Rad neu erfinden, wenn es schon eine gut funktionierende Loesung gibt, von daher gibt es die Abhaengigkeiten einfach. Es gibt aber auch Tools (z.B. die Module CPAN, CPANPLUS, PPM), die einen bei der Modulinstallation und gerade den Abhaengigkeiten sehr gut helfen.
• "Speicherverwaltung und komplexe Datenstrukturen: Nach einigen Jährchen Entwicklung leakt das ganze immer noch": ich finde es seltsam, dass ich als professioneller Perl-Entwickler eigentlich nie mit Memoryleaks zu kaempfen habe (ausser bei Thread-Programmierung, die in Perl noch ziemlich neu und verbesserungswuerdig ist).
• Der groesste Pluspunkt fuer Perl ist meiner Meinung nach, dass man in fast allen Bereichen sehr schnell Programme entwickeln kann. Und durch die dadurch eingesparte Zeit wird gerade bei groesseren Anwendungen viel eingespart, was man z.B. in schnellere Hardware investieren koennte. Und falls sich dann immer noch Leistungsengpaesse ergeben sollten, kann man mit Hilfe einiger Perl-Module sehr gut herausfinden, wo denn die CPU-Zeit (oder was auch immer) verbraten wird, und bekommt dann konkrete Hinweise, wo sich eine Optimierung ueberhaupt lohnt. Und falls Perl fuer die Optimierung zu langsam sein sollte, kann man auch sehr gut Code aus C in Perl einbinden (XS, Inline::C)
• "...zu viele Möglichkeiten, dasselbe auszudrücken... Ich sehe nicht, dass sich Perl hier besonders von anderen Sprachen unterscheidet. Vielleicht könntest du an einem Beispiel erklären, was du damit meinst. -- HelmutLeitner"

  die "Error in opening '$dateiname': $!\n";

  # code hier

  die "Error in opening '$dateiname': $!\n";

• "Ich finde es schwierig, mit Perl einen Stil einzuhalten, will man etwa eine Exception (oder einen Programmabruch) erreichen, wenn open fehlschlägt, hat man die Auswahl zwischen folgenden "Stilen":..."

• "Perl hat keine DatenStrukturen??, sie müssen bei Bedarf mit Arrays oder Hashes nachgebildet werden": wie oben schon gesagt, hat Perl zwei Datenstrukturen: Arrays und Hashes, und aus Kombination der beiden zusammen mit Referenzen kann man sich jede beliebig komplexe Datenstruktur zusammenbauen (in C sind es halt anstelle von Referenzen Pointer, die man fuer sowas verwenden kann). Da auch die objektorientierte Programmierung von Perl auf Referenzen aufgebaut ist und man da als Basis fast alles nehmen kann, was in Perl an Variablentyp vorhanden ist, ist da die objektorientierte Programmierung um einiges flexibler als in den meisten anderen Sprachen. Sie geht von der Realisierung nur von einem etwas anderen Ansatz als die meisten anderen Sprachen aus, indem fast ausschliesslich schon vorher bekannte Sachen (z.B. Referenzen) verwendet werden. Das einzige, was da neu hinzukommt, ist das Schluesselwort bless, das eine Referenz zu einem Objekt macht (d.h. sie in eine Klasse aufnimmt). Dazu kommen noch besser lesbare Schreibweisen wie z.B. $objekt->methode(...), die man jedoch nicht unbedingt verwenden muss.

Mal angenommen, ich bräuchte eine simple Liste von Listen, eine 2x2-Matrix mit den Elementen A, B, C und D. Wie könnte ich das aufschreiben? Vielleicht so:

  matrix = ((A,B),(C,D))

Schade, ist eine Liste mit 4 Elementen geworden. Also braucht man wohl Referenzen. Mal schauen, ob wir nachher die erste Zeile extrahieren können:

  matrix = ([A,B],[C,D])
  print $matrix[0]

Komisch, die Hex-Repräsentation einer Adresse kommt heraus. Ach richtig, Arrays muss man ja mit @ anfordern. Okay...

  print @matrix[0]

Nanu, wieder nur eine Adresse?! Das ergibt einfach keinen Sinn... ein Guru im Usenet erklärt einem dann das:

  print @{$matrix[0]}

Bei allem Respekt, wenn das eine Stärke von Perl ist, dann will ich die Schwächen gar nicht sehen.

Es ist von Vorteil zu verstehen, wie Referenzen funktionieren, wenn man sie (z.B. fuer komplexere Datenstrukturen) verwenden will. Auch in anderen Sprachen muss man korrekt dereferenzieren. Ein Vorteil aber ist, wenn man keine homogenen Datenstrukturen benoetigt, sondern vermischte, z.B. Arrays of Hashes oder komplexer, z.B.

    login => {
        coderef     => \&Actions::SubLogin?,   # Referenz auf Subroutine
        template    => 'template_start.html', # Skalar
        defaultUser => 'guest',               # Skalar
    },
    logout => {
        coderef  => \&Actions::SubLogout?,         # Referenz auf subroutine
        template => 'template_end.html',          # Skalar
        targets  => [ qw( start end external ) ], # Referenz auf Array
    },
    # ...

• Perl ist z.B. nicht geeignet, ein Betriebssystem damit zu schreiben (dafuer gibt es Assembler, C,...);
• Was SimonCozens? vor 4 Jahren nicht davon abgehalten hat, es dennoch zu tun. --SörenMLairdSörries?
• Perl ist jedoch in der Regel hervorragend fuer alles geeignet, was in irgendeiner Weise mit der Manipulation von Zeichenketten oder binaeren Inhalten zu tun hat, und das trifft irgendwie fuer fast alle Problemstellungen zu. Ich klaube mir einfach mal den Punkt Webprogrammierung heraus:

1. Perl/CGI ist fuer viele Sachen durchaus angemessen, wenngleich auch recht langsam, weil fuer jeden Aufruf perl geladen werden muss, dann das komplettes Script eingelesen und compiliert und ausgefuehrt. Aber z.B. fuer ein Gaestebuch reicht es durchaus, oder wenn man Schnittstellen zu anderen Systemen braucht, die von CPAN-Modulen abgedeckt werden, dann ist es haeufig die am schnellsten zu entwickelnde Loesung.
2. PHP laeuft (gerade als Apache-Servermodul) in der Regel um einiges schneller als Perl/CGI, ist aber vom Sprachumfang her nicht so maechtig wie Perl (vor allem Dank CPAN).
1. Eine Libelle in einem Flugzeug fliegt schneller als ein Vogel... PHP/CGI ist nicht schneller als Perl/CGI, mod_php nicht schneller als mod_perl. Bitte nicht Pferdeäpfel mit Glühbirnen vergleichen. --SörenMLairdSörries?

3. mod_perl: hier laeuft Perl "im" Apache, und die Scripte werden (normalerweise) schon vorcompiliert im Speicher gehalten. Dadurch ist mod_perl aeusserst schnell (in der Regel schneller als mod_php), und man hat Zugriff auf fast alle Schnittstellen der Apache-APIs (und sei es ueber das Einbinden von C-Code), sodass man die zahlreichen Moeglichkeiten des Apache Webservers optimal ausnuetzen kann. Dazu gibt es noch Templating-Systeme wie z.B. HTML::Mason (=sowas aehnliches wie PHP, nur mit Perl als Scriptsprache), was auf mod_perl (oder wahlweise Perl/CGI) aufbaut und selbst schon ein sehr gutes Caching implementiert, wodurch das ganze nochmal schneller wird, und auch einfacher verwendbar als mod_perl pur. Denn da muss man schon recht sauber programmieren, damit man nicht unnoetig Arbeitsspeicher verbraet (oder sogar Memoryleaks coded).

In Perl gibt es eigentlich nur eine Sache, die mich richtig stoert:

man kann dieses Verhalten durch ein Quoting verhindern, z.B. $irgendwas =~ /\Q$variable\E/; # hier ist der . ein .

und ueber dieses Verhalten stolpert wohl jeder mal mehr oder weniger boese, weil es im Extremfall (z.B. in $variable kommt ein ( vor) sogar Fehler mit Abbruch geben kann. (Ich habe vor einiger Zeit mal laenger mit Damian Conway darueber diskutiert, ob fuer Perl6 dieses Verhalten nicht geaendert werden soll, konnte ihn aber nicht davon ueberzeugen)

Gruss,

Martin Fabiani ( http://www.fabiani.net/, http://www.perl-community.de/ )

Nun, ich glaube, dass in Perl6 dieses Verhalten kein Stolperstein mehr sein wird, denn die Rule-Syntax ist tatsächlich idiotensicher/übersichtlich (und wird sogar Java-Fans gefallen :-). Es kann im Übrigen nicht geändert werden, da die Abwärtskompatiblität stark leiden würde. Apropos Perl6 und Rules: http://perlmonks.org/index.pl?node_id=326619 --RichardVoß

Re Datenstrukturen

Mindestens zwei Dinge benötigt man, um Datenstrukturen (AlgebraischeTypen) zu bauen, nämlich Summen (union in C, wenn auch etwas Low-Tech) und Produkte (struct in C). Perl hat beides nicht. Man kann beides über Hashtabellen und Referenzen nachbilden, aber eine Stärke von Perl sind komplexe Datenstrukturen deswegen ganz sicher nicht.

Sehr gut unterstützt sind in Perl lediglich HashTabellen und RegExe?. Das führt dazu, dass beispielsweise die diversen Wikiengines die Umformatierung von spezifischem Markup in HTML mit Regexen erledigen - gilt nicht nur für Perl, sondern auch für die diversen Implementierungen in verwandten Sprachen - wo eine BaumTransformation geeigneter wäre.

Bei den Datenstrukturen gebe ich dir großteils Recht, obwohl ich das Gewicht nicht verstehe, das du den Unions gibst. Im übrigen hängt es immer davon ab, wie man eine Sprache benutzt. Man kann in einer modernen OO Sprache Mist schreiben und in Perl saubere Programme. Was Erik Naggum sagt, ist natürlich völliger Unsinn. Perl ist ideal für Textverarbeitung (wie in diesem 13000+ Zeilen Wiki = ca. 210 Seiten) und hat einen total sympathischen Umgang mit dynamischen Arrays und Hashes. -- HelmutLeitner

Die Union-Geschichte stammt übrigens nicht von Udo, wie Diff beweist. Was Erik Naggum sagt, ist natürlich völlig korrekt. Reguläre Ausdrücke kann man in fast jeder Sprache mit entsprechenden Bibliotheksfunktionen behandeln, dafür muss man sich die Perl-Syntax und -Semantik nicht antun. Eine Programmiersprache eignet sich nicht dadurch für große Projekte (wie zum Beispiel die Wiki), dass man immer noch was hinzufügen kann, sondern dadurch, dass man auch nachträglich noch Änderungen vornehmen kann und einem der Übersetzer penibel alle dadurch entstandenen Brüche aufzeigt. -- HenningThielemann

Ich glaube, dass der Begriff GroßeProjekte zu unspezifisch ist. Es gibt verschiedene Arten davon, die unterschiedliche Werkzeuge nahelegen. Das wäre eine eigene Diskussion. Es ist aber merkwürdig, dass du nahelegst, bei einem größeren Perl-Projekt würde "nur hinzugefügt" aber man könne nicht "noch Änderungen vornehmen" (wie in einer "richtigen modularen Sprache"). Das klingt in meinen Ohren etwas nach "ex cathedra".-- HelmutLeitner 20. September 2004 17:23 CET

Ich verstehe das Argument nicht. Naggum ist ein Hitzkopf mit einem Diskussionsstil, der weit unter der Gürtellinie liegt ( GründerWiki:Flame). Das Körnchen Wahrheit in seinen Aussagen spreche ich ihm nicht ab - eben so wenig wie seinen jeweiligen Opponenten -, aber mehr auch nicht. Baumstrukturen und RegEx und haben herzlich wenig miteinander zu tun und der Vorwurf, Perl-Programmierer würden alles mit RegEx lösen, ist in seinem Über-Den-Kamm-Scheren empirisch nicht fassbar und deswegen einfach lächerlich. -- HelmutLeitner 20. September 2004 17:14 CET