Login


 
Newsletter

Thema: Nutzen Sie Perl?

34 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
2
Von Flupo am Fr, 21. Dezember 2012 um 15:53 #

Zeigt mir den Gnu/Linux-User der kein Perl benutzt.. wenn auch unbewusst.

Perl ist immer noch meine lieblings Skriptsprache wenns darum geht irgendwelche Daten zu verarbeiten oder was zu automatisieren. Bash brauch ich nicht, ich mach alles mit Perl.

1
Von al am Fr, 21. Dezember 2012 um 15:58 #

Die Perl 5 - Perl 6 Situation ist Idiotie. Solange das nicht behoben ist werde ich keines von beiden anfassen. Nennt Perl 6 um oder steht zu Perl 6 und sagt deutlich, dass Perl 6 der Nachfolger von Perl 5 sein soll und entwickelt Perl 5 nicht mehr weiter.

  • 2
    Von Clean Coder am Fr, 21. Dezember 2012 um 17:21 #

    Die Situation ähnelt ein bisschen der von PHP damals. Da ist PHP6 gekillt worden, weil die Entwickler zu faul waren und die wichtigsten Dinge sind zurückportiert worden.
    Der Unterschied ist allerdings, das hinter den Implementationen von Perl6 und Perl5 verschiedene Leute stecken und das die Perl6-Leute eigentlich nicht faul, sondern die Featureliste sehr sehr umfangreich ist.

    1
    Von beccon am Fr, 21. Dezember 2012 um 19:15 #

    auch nicht schlimmer als bei Python 2.6 / 2.9 (???) :-)

    Mein Tip ist, daß Perl 6 pünkltlich zur Veröffentlichung von Hurd herauskommen wird :-)

    Dieser Beitrag wurde 1 mal editiert. Zuletzt am 21. Dez 2012 um 19:15.
    2
    Von boelwerkr am Sa, 22. Dezember 2012 um 11:04 #

    Der Irrglauben es gäbe noch keine Perl6 rührt daher, das die Entwicklung für Perl ungewöhnlich ist.
    Zuerst wurden alle Wünsche zu Perl6 gesammelt und zusammengefasst. Das ist das was mal als Perl6 bezeichnet. Es ist die Sprachspezifikation.
    Danach begann man mit Perl6 Implementierungen (Rakudo ist einer der bekannteren). Die Leute in der Planung arbeiten eng mit denen zusammen, die Perl6 Interpreter programmieren. Dabei tauchen immer wider Probleme und neue Ideen auf. Das hat zur Folge, das egal wie weit ein Interpreter ist, es immer noch eine lange Liste von Dingen gibt, die Implementiert werden müssen.
    Außerdem ist es eine sehr abstrahierte Sprache. Man programmiert auf einem sehr hohen Abstraktionsgrad, das hat zur Folge das der Interpreter einiges verwalten und beachten muss, das macht diesen komplex und ohne die Optimierungen langsam.

    Rakudo hat mittlerweile einen Stand erreicht, das man damit Programmieren kann.
    Ich teste es schon und es ist eine wirklich gute Sprache.
    Dennoch arbeite ich weiter mit Perl5, da der Interpreter einfach ausgereifter ist. Es ist für jede dynamisch typisierte Sprache schwer an die Qualität des Perl5 Interpreters heran zu kommen.

    Es wird weiterhin immer behauptet Perl6 habe Perl5 getötet. Das Gegenteil ist der Fall, mit Perl6 kamen neue Leute zu Perl5, Cpan wird überschwemmt mit neuen Modulen und alte werden wieder gepflegt. Eine Menge neuer Features hielten in Perl5 Einzug. Die Entwicklung des Interpreters hat sich beschleunigt. nicht mehr alle paar Jahre gibt es eine neue Version sondern einmal im Jahr.
    Es passiert eine ganze Menge.

    Immer wider taucht die Behuptung auf man könne in Perl keine großen Projekte schreiben, da die Sprache zu chaotisch wäre.
    Es stimmt, Perl ist eine sehr variable Sprache, die einem viele Freiheiten gibt. Und man kann damit so Programmieren, das es aussieht als wäre jemand auf der Tastatur herum gesprungen. Aber man muss es nicht. Man kann Perl aussehen lassen wie C++ oder Java, man kann es etwas wie Python aussehen lassen, oder wie Ruby.
    Man kann mit Perl strukturiert Programmieren und man kann damit so programmieren, das man den Code in 10 Jahren noch versteht. Aber man muss auch sehen, das es Disziplin erfordert.

    Man kann so was schreiben um eine Datei zu lesen


    my $data=eval{local($/,@ARGV)=(undef,$file);<>};

    Man muss es aber nicht:


    my $data;
    if( open my $fh, '< ', $file )
    {
    local $INPUT_RECORD_SEPARATOR = undef;
    $data = readline $fh;
    close $fh;
    }

    oder objektorientiert:


    use IO::File;
    my $data;
    if( my $fh=IO::File->open( $file, 'r' ) )
    {
    $fh -> input_record_separator( undef );
    $data=$fh -> getline();
    }

    oder man benutzt etwas fertiges:


    use File::Slurp;
    my $data = read_file( $file ) ;

    Aber möglicherweise ist es diese Varianz die viele verschreckt. Viele scheinen zufrieden zu sein, wenn es nur einen einzigen, nicht ganz perfekten Weg gibt ein Problem zu lösen. und schreiben dann lieber den dreifachen Code um ihr Ziel zu erreichen.

    • 1
      Von al am Sa, 22. Dezember 2012 um 11:30 #

      > Der Irrglauben es gäbe noch keine Perl6 rührt daher

      Das ist nicht das Problem. Das Problem ist, dass Perl 6 eine komplett andere Programmiersprache ist als Perl 5, beide aber den gleichen Namen tragen und beide weiterentwickelt werden. Das ist die dümmste Dummheit überhaupt, eine Spaltung in der eigenen Community, und macht Perl endgültig nicht mehr ernstnehmbar.

      • 1
        Von lichtkind am Sa, 22. Dezember 2012 um 20:39 #

        dummheit zu schreien ist sher einfach, , mal was zu tun aber mit aufwand verbunden. um ein so grosses vorhaben wie perl 6 überhaupt anfangen zu können braucht es einige die da mitziehen, daher wohl das perl branding. denn community kann software fixen aber nicht umgekehrt.


        perl 6 ist der versuch idealversuch zu verwirklichen in einem umfang wie sonst keienr die eier dazu hat.

      0
      Von Clean Coder am Sa, 22. Dezember 2012 um 11:38 #

      Diese Argumentation finde ich nicht so gelungen.

      Keines des obrigen Beispiele sieht so aus wie Java, Python oder Ruby aus, geschweige denn, fühlt sich so an.
      Und alle drei verursachen bei Neulingen auf den ersten Blick Augenkrebs wegen der vielen $, -> und ::.
      Gut, es fehlt die Einrückung, was vermutlich durch die Forensoftware kaputtgemacht wurde.
      Aber z.B. das Encoding ist hier noch nichtmal berücksichtigt, genauso wenig wie Fehler beim Zugriff.
      Das vierte Beispiel nutzt ein Modul, das man scheinbar von CPAN laden muss.
      Module von CPAN lebendig auf den eigenen Rechner zu bekommen wird unterschätzt, besonders, wenn es sich um Bindings zu C-Bibliotheken handelt.
      Viel Spaß dabei SDLx zum Laufen zu kriegen.
      Überhaupt wird CPAN gnadenlos überschätzt. Ähnlich wie die Drölfzillionen Apps im iStore.
      Viel Redundanz, häufig miese Dokumentation - hier ist z.B. die Dokumenation der LibXML zu nennen - und viel Kram den wirklich niemand braucht; sucht ruhig mal nach "ASCII Art".

      Was Perl6 angeht, scheint Rakudo schon bald fertig zu sein, wenn man dieser Tabelle hier glauben darf:
      http://perl6.org/compilers/features
      Allerdings haben die Parrot-Leute das Problem, die Releasen-wir-mal-jede-Woche-und-schauen-wir-mal-wer-in-zehn-Jahren-noch-da-ist-Methode übernommen zu haben.
      Das ist schade, denn wenn man diesem Benchmark hier trauen darf
      http://www.rapideuphoria.com/bench.txt (relativ weit unten)
      ist Parrot schon gut schnell und einen brauchbaren Garbage Collector zu haben ist auch nicht verachtenswert.

      • 0
        Von Clean Coder am Sa, 22. Dezember 2012 um 13:15 #

        Ach ja, nicht zu vergessen: Die Seite von Parrot ist halb verweist. Die Links zu den Sprachen führen zu 2/3 ins Leere, es scheint, dass nur noch Rakudo aktiv entwickelt ist und der Newsstream auf der rechten Seite der Hauptseite ist nicht mehr up-to-date.

        • 0
          Von lichtkind am Sa, 22. Dezember 2012 um 20:29 #

          kann sein aber die Entwicklung geht gut vorran

          • 0
            Von Clean Coder am Sa, 22. Dezember 2012 um 20:40 #

            Leider weiß es aber keiner...

            • 0
              Von lichtkind am Sa, 22. Dezember 2012 um 23:40 #

              keiner ist reichlich übertrieben, zum einen die entwickler wissen ja, die fans im irc, dann gibt es taufrische infos im aktuellen Perl 6-Adventkalender, perl6.org ist auch ziemlich auf dem stand und in der nächsten foo gibts auch wieder update, dann gibts noch blogs der entwickler, besucher der konferenzen ..... weil endlich endlich kommen threads auch langsam in parrot an was ja in frankfurt thema war, vielleicht wollstest du ja auch sagen das es dich nicht wirklich interessiert :) aber klar parrot seite könnte mal überbügelt werden auch das lemma auf wikipedia

1
Von Clean Coder am Fr, 21. Dezember 2012 um 17:15 #

...als besseres Shellscript für Wegwerfscripte, an denen ich alleine arbeite. Das ist die Nische, die Perl heutzutage am besten abdeckt. Wobei man immer aufpassen muss; bekanntlich hält nichts länger als ein Improvisorium.

Für richtige Anwendungen nutze ich aber lieber Anderes.
Ich habe großen Respekt vor den Entwicklern von gmusicbrowser und Shutter. Das sind gute Anwendungen, aber der Quelltext sieht nach Schmerzen aus.

  • 1
    Von glasen am Fr, 21. Dezember 2012 um 17:30 #

    Das sind gute Anwendungen, aber der Quelltext sieht nach Schmerzen aus.
    Perl ist halt eine "Write Only"-Sprache, die den Entwicklern viel zu viele syntaktische Freiheiten lässt.

    • 1
      Von Clean Coder am Fr, 21. Dezember 2012 um 17:55 #

      Das ist nichtmal der wirklich schlimme Teil.
      Was mich wirklich erschreckt hat, sind die ganzen Workarounds für verschiedene Unterversionen von GTK.

      3
      Von beccon am Fr, 21. Dezember 2012 um 19:13 #

      Perl Quelltext läßt sich nicht lesen und sieht vor und nach RSA Verschlüsselung gleich aus ... :-)

      Nee das stimmt nicht. Ich muß in mehreren Projekten Perl Programme von anderen weiterentwickeln.

      Es macht mir immer wieder Freude, aber es ist immer das Gleiche: 1-2h den Quelltext anschauen und hin und herblättern, dann ein, zwei Zeilen ändern und die neue Funktionalität ist implementiert...

      Ob die Codequalität von solch eine Vorgehensweise besser wird oder nicht, darüber läßt sich trefflich streiten. Fest steht für mich aber, daß Perl hervorragend für ein agiles Vorgehensmodell geeignet ist.

      Wir bauen da gerade an einer Schnittstelle im Bankenbereich. Leider ist sich die Fachabteilung nicht ganz so sicher, wie sie das haben wollen - also muß ständig der Code angepaßt werden. Mit Perl ist das beherrschbar - die offenbar vorher angedachte Alternative mit Java wäre schnell an ihre Grenzen gelangt. Ich bin jetzt der dritte Entwickler an dem Code (die Fluktration ist halt ein wenig höher ;-) ) - Ich finde mich damit noch zurecht und kann die notwendigen Änderungen noch mit einbauen...

      1
      Von turrican mcguire am Fr, 21. Dezember 2012 um 23:37 #

      Das Buch "Einführung in Perl" hatte ich durchgearbeitet. Perl ist meiner Ansicht nach stark kontextbasiert, wenn ich die Variablen $_ usw betrachte. Als ich es begriff kam mir Perl total logisch und super einfach vor. Nur als ich Perl dann wenig nutzte, verflog dieses sichere Gefühl und es war mühsam für mich sich wieder einzuarbeiten.

      Auf Arbeit hatte ich Perl für neuen Samba/LDAP-User anlegen in einem kleineren Skript (vielleicht 40 Zeilen)angewendet und funktionierte prima. Durch LPIC 301 hatte ich entsprechende Vorkenntnisse.

      Auch für ein Bacula-Plugin für Zabbix hatte ich ein bereits vorhandenes Perl-Skript angepasst.

      OTRS halte ich für eine schöne Perl-Webanwendung. Im Produktiv-Betrieb stellte ich einen hohen Arbeitsspeicherverbrauch fest, was im oben genannten Buch Perl nachgesagt wurde.

      OCS Inventory schaue ich mir gerade an und basiert ebenso auf Perl.

      Python ist ja zur Zeit so sehr in Mode, ich habe jedoch schlechte Erfahrungen gemacht. Auf einem Gentoo-System konnte ich nur entweder den Passwort-Manager kedpm oder emerge benutzen.

      Bei Perl bin ich mir sicher, dass es kompatibler ist und nicht so stark auf eine bestimmte Python-Version fixiert ist.

      Python ist Marketing, weches Perl nicht hat, aber verdient hätte.

      1
      Von Eric MSP Veith am Sa, 22. Dezember 2012 um 04:06 #

      Das Argument ist heute überkommen. Mit Moose &Co besitzt Perl Merkmale, die vielen anderen Sprachen fehlen. Ich empfehle mal die Lektüre von www.modernperlbooks.com.

      1
      Von Eric MSP Veith am Sa, 22. Dezember 2012 um 04:19 #

      Das Argument ist heute überkommen. Mit Moose &Co besitzt Perl Merkmale, die vielen anderen Sprachen fehlen. Ich empfehle mal die Lektüre von www.modernperlbooks.com.

4
Von beccon am Fr, 21. Dezember 2012 um 19:23 #

Schaue ich mir die Programmiersprachen an, die mir den meisten Umsatz bescheren, dann liegt Perl ungeschlagen vorn.

Die Projekte beinhalten meist Schnittstellen mit etwas Geschäftslogik (wo sich die Kunden nicht von Informatica - klick klick klick und fertig ist das Interface - knürre machen haben lassen).

Einmal war auch ein ganzes Banksystem (Oracle basiert, mit Terminal- und Weboberfläche) zu erweitern - das war richtig cool.

Perl wird gefolgt von T-SQL (Sybase and Microsoft), irgendwann kommt ganz hinten abgeschlagen VBA und Access.

Naja - die Programmiersprache mit der ich die meiste Zeit verballert habe, ohne etwas gescheites damit zu verdienen: PHP (da kann nicht unbedingt die Sprache etwas dafür- es war halt nur so)

  • 0
    Von wio am Mo, 24. Dezember 2012 um 17:03 #


    Schaue ich mir die Programmiersprachen an, die mir den meisten Umsatz bescheren, dann liegt Perl ungeschlagen vorn.
    Naja - die Programmiersprache mit der ich die meiste Zeit verballert habe, ohne etwas gescheites damit zu verdienen: PHP (da kann nicht unbedingt die Sprache etwas dafür- es war halt nur so)

    Bei mir ist es genau umgekeht. Vermutlich bist du nicht im Webbereich unterwegs ich hingegen ausschliesslich, im Web spielt Perl heute praktisch keine Rolle mehr verglichen mit PHP. Ob ich jetzt das eine oder andere nutzen müsste ist mir ehrlich gesagt wurscht, hat sich halt so ergeben.

    Im Prinzip ist es sch* egal welche Scriptsprache man verwendet, Hauptsache man bekommt seinen Job damit gebacken.
    Und was die Lesbarkeit betrifft, das ist reine Übungssache. Wenn man Perl nur alle Monate Jahre mal verwendet und zuvor noch nie länger damit gearbeitet hat ist es schwieriger wieder reinzukommen, verwendet an es aber sehr oft ist die kurze und 'kryptische' schreibweise unübertroffen. Die Sourcecodesammlung von CPAN ist im Vergleich zu anderen Scriptsprachen ungeschlagen, PEAR/PECL, PIP, Rubyforge/GEM das stinkt alles mächtig ab obwohl im CPAN auch viel Müll und Ungepflegtes steckt, man findet trotzdem immer was Brauchbares und das über sehr viele Bereiche.

1
Von dergutekoenig am Sa, 22. Dezember 2012 um 08:55 #

Der gute König und die Programmiersprache... unendliche Geschichte. Interessiere mich für C, C++, Java, Python und Vala, springe ständig zwischen diesen Sprachen hin und her und lerne deshalb irgendwie keine so richtig. :-(

Perl hingegen hat mich bislang nicht ansatzweise gereizt. Vielleicht tu' ich der Sprache Unrecht, aber andererseits habe ich mit der Entscheidung für eine Sprache eh schon genug zu kämpfen. ;-)

0
Von dirk am So, 23. Dezember 2012 um 05:23 #

Ein Perl-Programm debuggen: Einfach am Ende eine neue Funktion/Klasse/etc. schreiben, die die vorherige, fehlerhafte überschreibt, weil es kein Schwein mehr lesen kann … :)

  • 0
    Von cool am So, 23. Dezember 2012 um 17:56 #

    programmierende Schweine, das musst mir mal zeigen

    0
    Von beccon am Mo, 24. Dezember 2012 um 12:49 #

    jetzt geht der Sparwahn schon so weit, daß Schweine programmieren müssen. Na vielleicht bewahrt sie das wenigstehs vor dem Grill...

    Früher hieß es: If you pay peanuts - you get monkeys to work... :D

    0
    Von beccon am Mo, 24. Dezember 2012 um 13:24 #

    Gerade der eingebaute Debugger macht Perl zu einer leistungsfähigen Enwicklungsumgebung. Leider hat er noch ein paar Schwächen, die sich aber durch zusätzliche Module (z.B. Readline, um die Kommando-Historie zu haben oder Data::Dumper zur Anzeige von Array, Hash und Hashref Strukturen) wunderbar ausbügeln lassen.

    Eine der Stärken von Perl - wenn nicht die größte Stärke - sind die Datenstrukturen, die ohne Probleme mehrere Megabyte umfassen können und die mit mengenorientierten Befehlen wie grep, map oder sort als Ganzes bearbeitet werden können. Viele Programme sind so aufgebaut.

    Ich gehe dabei immer so vor, daß ich das Programm an bestimmten Stellen anhalte und mir die Datenstrukturen anschaue -ok, das geht bei Java und Eclipse auch. Was aber mit Perl besonders gut geht ist, daß sich Programmbefehle auch als Kommandos ausführen lassen. So kann ich schrittweise den nächsten Befehl zusammenbauen.

    So relativiert sich die - schon nicht so aus der Luft gegriffene - Geschichte von der schweren Lesbarkeit erheblich.

    Wie schon vorher einmal erwähnt: Ich ändere und erweitere erfolgreich Perl Programme von anderen Programmieren und das fällt mir nicht schwerer als mit anderen Sprachen.

0
Von o.teske am Mo, 24. Dezember 2012 um 16:43 #

Ich habe mich mal eine Zeit lang in Perl und Perl/Tk versucht. Mal abgesehen davon dass ich keine Typenlosen Sprachen mag hatte ich einen ständigen Kampf mit der Kontextsenstitivität, das ist der größte Sch.... Perl hat mich immert anders verstanden als ich wollte. Ich habe dann viel Energie aufgewendet die Kontextsensivität auszutriksen um möglichst nah an C zu kommen, das macht keinen Sinn für mich. In Perl OO zu programieren ist dann noch einmal ein ganz besonderer Spaß. Für kleine Sachen OK aber was über einen Dreizeiler hinausgeht ist es echt nichts für mich; wer es mag OK.
Gruß
Oli

  • 0
    Von Unerkannt am Di, 25. Dezember 2012 um 00:36 #

    Und C ist nicht Kontext-sensitiv? Vermutlich verstehe ich den Begriff einfach nicht richtig. Formale Informatik ist schon so lange her.

    Meinst du mit typenlosen Sprachen, nicht statisch typisierte Sprachen?

    • 0
      Von besoffener weihnachtsmann am Di, 25. Dezember 2012 um 11:17 #

      Verstehe auch nicht was er meint. Vielleicht die Sichtbarkeit von Variablen? Auf jeden Fall hat er die Sprachgrundlagen nicht verstanden, ist halt kein C.

Pro-Linux
Frohe Weihnachten Fest!
Neue Nachrichten