Sprache Perl
(Weiterleitung von Perl)
 
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern

Perl. Practical Extraction and Reporting Language. 1987 entwickelt von LarryWall.

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:


Stärken:

Schwächen: Typische Einsatzgebiete:
Diskussion

...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

...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

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

Das ist halt eine allgemeine Perl vs Python (pro Python) Stellungname bzw. Perl-Kritik. Von den vielen Kritikpunkten sehe ich auf den ersten Blick nichts, was direkt zu "zu viele Möglichkeiten" passt. Ich bin kein Perl-Spezialist, habe aber in den letzten Monaten viel in Perl programmiert. Ich habe vieles Positives und einige negative Punkte gefunden, aber im Grunde sehe ich in in Perl weniger Variationsspielraum als in anderen klassischen Sprachen (wie z.B. C++, Java oder Basic). Deswegen meine Frage. --hl

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

Mmmh. Eine Sprache mit im Prinzip 4 Datentypen überladen? Kryptisch ja! Am schlimmsten finde ich die 3 Dutzend systemeigenen Variablen, wie @_ , $_, $!, $%, $/, $+, $", $\, $^T, ... . Gottseidank kann man die beim Programmieren weitgehend vermeiden oder kapseln. --hl
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;
wobei die Klammern um die Parameter von open nicht Pflicht sind. Ich benutze die "or"-Variante. Passt immer, ausser bei
        system(...) and die; 
Inzwischen benutze ich wenn möglich und sinnvoll, SprachePython. Da gibt es eine Exception, wenns schiefgeht und fertig. -- JensQuade?

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:

my $FH; unless( open( $FH, '<', $filename ) ) {
    die "Error: couldn't open file '$filename' for reading: $!\n";
} # unless

oder auch:

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

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

oder sogar, wenn der Dateiinhalt in einem Rutsch eingelesen werden muss:

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>;
}; # do

--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

Man kann dadurch das Betonen, was einem wichtig ist, z.B.
Was ist da wichtig: ob $DEBUG gesetzt ist, oder die Ausgabe des Wertes? if ($DEBUG) { print "DEBUG: Wert ist $wert\n"; } print "DEBUG: Wert ist $wert\n" if $DEBUG;
oder Datei-Oeffnen: open (FILEHANDLE, $dateiname) or die "Error in opening '$dateiname': $!\n";
unless (open (FILEHANDLE, $dateiname)) { # unless ist if not
  die "Error in opening '$dateiname': $!\n";
}
if (open (FILEHANDLE, $dateiname)) {
  # code hier
} else {
  die "Error in opening '$dateiname': $!\n";
}
$! beinhaltet eine Fehlermeldung

Perl ueberlaesst es dem Programmierer, ob er einen Fehler abfangen will oder nicht. Ich finde da Sprachen, die da von selbst sterben, wenn was fehlschlaegt, nicht so schoen, weil man da die kritischen Operationen alle in Evaluationsbloecke (z.B. try, ...) packen muss, was der Lesbarkeit normalerweise nicht gut gut

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.

use Readonly; Readonly::Hash our %actions => (
    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
    },
    # ...
); --MartinFabiani

    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:
und zwar, dass Variablen in regulaeren Ausdruecken automatisch evaluiert werden: my $variable = "test.txt"; $irgendwas =~ /$variable/; # hier wird der . zu einem beliebigen Zeichen

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


KategorieProgrammierSprache KategorieSkriptSprachen KategoriePerl KategorieOpenSource
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
Text dieser Seite ändern (zuletzt geändert: 3. Mai 2007 3:19 (diff))
Suchbegriff: gesucht wird
im Titel
im Text