relevanz?

[steph12]

schön, aber wird perl heutzutage überhaupt noch eingesetzt?

[baldur]

Ich hab schon paarmal kleine Skripte für irgendwelchen Kleinkram geschrieben, z.B. ein Skript um mir eine große Menge Subrepositories zu aktualisieren oder Dateien zu konvertieren.

Mit dem Perlsyntax komme ich besser klar als mit Bashskripten und manche Dinge gehen mit Perl auch richtig schön einfach. Man kann z.B. einfach einen Shellbefehl ausführen und die Ausgabe zeilenweise mit einer foreach-Schleife durcharbeiten. Reguläre Ausdrücke lassen sich sehr einfach nutzen, wenn man Dateien oder Ausgaben nach einem Muster durchsuchen will.

Muss mir mal den Perl6 Syntax anschaun, bin neugierig :)

[SelfEsteem]

steph12 schrieb:
--------------------------------------------------------------------------------
> schön, aber wird perl heutzutage überhaupt noch eingesetzt?

Spielt es eine Rolle? Es ist halt eine neue Sprache (und eben nicht nur ein Perl5 Update) mit ein paar ziemlich coolen Aspekten. Ob es Anklang findet, wird sich zeigen.

Die aktuell wohl meistverbreitete Skriptsprache duerfte Python sein, aber auch das hat Stellen, die mich schlicht nerven, obgleich ich Python insgesamt recht angenehm finde.

[olqs]

So zeilenweise die Ausgabe in der Bash verarbeiten ist ein wenig gewöhnungsbedürftig, aber wenn man sich mal dran gewöhnt hat:

IFS="
"
befehl | while read line
do
echo $line
done

[mxcd]

SelfEsteem schrieb:

> Die aktuell wohl meistverbreitete Skriptsprache duerfte Python sein, ...

Da glaube ich kaum.
Ich denke, dass JS und PHP vor Python liegen.

http://goo.gl/pyQ6XW

[DrWatson]

mxcd schrieb:
--------------------------------------------------------------------------------
> SelfEsteem schrieb:
>
> > Die aktuell wohl meistverbreitete Skriptsprache duerfte Python sein, ...
>
> Da glaube ich kaum.
> Ich denke, dass JS und PHP vor Python liegen.
>
> goo.gl

[githut.info]

[Vanger]

Etwas schöner: IFS=$'\n'

Ich empfehle außerdem immer IFS in der selben Zeile zu definieren in der auch der Aufruf der Schleife erfolgt. Ist nichts (quasi-)offizielles, hilft imho aber bei der Lesbarkeit (zusammengehöriges zusammen behandeln) und zwingt einen dazu bei wirklich jedem Aufruf IFS zu definieren (vermeidet unerwartete Ergebnisse).

Sprich:
IFS=$'\n'; befehl | while read LINE; do
echo "$LINE"
done

[freebyte]

mxcd schrieb:
--------------------------------------------------------------------------------
> SelfEsteem schrieb:
>
> > Die aktuell wohl meistverbreitete Skriptsprache duerfte Python sein, ...
>
> Da glaube ich kaum. Ich denke, dass JS und PHP vor Python liegen.

Auswertungen dieser Art haben das gemeinsame Problem, dass als eine der Achsen immer die Anzahl der öffentlichen "Hilferufe" im Auswertungszeitraum als "Popularitätsindex" missbraucht werden muss um überhaupt eine Auswertung zu bekommen.

Um es mal überspitzt zu sagen: ABAP, COBOL, BASIC, MASM, BASH sind der Kitt, der unsere Wirtschaft zusammenhält und sind vermutlich nach Codezeilen die am meissten genutzten "Sprachen" - aber weil dazu jede mögliche Frage bereits in der Vergangenheit beantwortet ist erscheint die aktuelle Popularität nach aussen als gering.

Meine Meinung, kein wissenschaftlich abgesicherter Standpunkt.

fb

[baldur]

Da gibts immer irgendwelche Unschärfen.

Die andere Statistik die hier genannt wurde, versucht es anhand der Githubrepositories zu deuten, was für größere Projekte vermutlich sinnvoller ist, als die Anzahl der Hilferufe.
Auf der anderen Seite gibts jetzt nicht so viele große Projekte in Perl, dafür aber viele kleine Skpte, die man sich schnell zusammenhackt, aber nie veröffentlicht. Die werden da auch nciht mit gezählt.

Ganz oben in der Statsitik steht JavaScript, das aber teilweise von anderen Tools generiert wird, was das ganze auch ein bisschen bevorteilt.

So oder kanns also immer nur ein Näherungswert sein.

[baldur]

Kannte ich tatsächlich noch nicht, auch wenns eigentlich fast schon naheliegend ist wenn man ein bisschen Bash kennt ;)

Da ich aber nur alle paar Monate mal ein Skript zusammenhacke, muss ich für Bashsyntax immer wesentlich mehr googlen, als für Perl, komme mit letzterem also schneller zum Ergebnis.

Um Text bzw. die Ausgabe von anderen Tools weiterzuverarbeiten ist Perl mit seinen Regex auch wesentlich angenehmer als in einem Bashskript mit sed und awk rumzuhantieren.

[freebyte]

baldur schrieb:
--------------------------------------------------------------------------------

> Die andere Statistik die hier genannt wurde, versucht es anhand der
> Githubrepositories zu deuten, was für größere Projekte vermutlich
> sinnvoller ist, als die Anzahl der Hilferufe.

Danke für den Hinweis, der Post mit der github-Statistik muss reingekommen sein als ich am Schreiben war.

> Ganz oben in der Statsitik steht JavaScript, das aber teilweise von anderen
> Tools generiert wird, was das ganze auch ein bisschen bevorteilt.

Im Fall von Javascript hängt die Popularität an einer dritten, nicht immer bemerkten Variablen: HTML und CSS.

Um mit letztgenannten Möglichkeiten irgendeine Form von Interaktivität (vulgo: Abbildung eines fat-clients auf web-client) hinzubekommen ist massiv Javascript vonnöten.

Dass man 3 völlig unterschiedliche "Beschreibungssprachen" für ein Projekt braucht scheint mir eine Erfindung der Neuzeit zu sein - früher hatten wir das alles im Code.

> So oder kanns also immer nur ein Näherungswert sein.

Ja.

fb

[freebyte]

baldur schrieb:
--------------------------------------------------------------------------------
> Um Text bzw. die Ausgabe von anderen Tools weiterzuverarbeiten ist Perl mit
> seinen Regex auch wesentlich angenehmer als in einem Bashskript mit sed und
> awk rumzuhantieren.

Solange deine Scripte beim Produktiveinsatz hinreichend gereift sind, spricht dem nichts entgegen - unter der Randbedinung dass das später niemals jemand verändern, anpassen oder erweitern will denn Rexex ist "write only".

fb

[baldur]

freebyte schrieb:
--------------------------------------------------------------------------------
> baldur schrieb:
> ---------------------------------------------------------------------------
> -----
> > Um Text bzw. die Ausgabe von anderen Tools weiterzuverarbeiten ist Perl
> mit
> > seinen Regex auch wesentlich angenehmer als in einem Bashskript mit sed
> und
> > awk rumzuhantieren.
>
> Solange deine Scripte beim Produktiveinsatz hinreichend gereift sind,
> spricht dem nichts entgegen - unter der Randbedinung dass das später
> niemals jemand verändern, anpassen oder erweitern will denn Rexex ist
> "write only".
>
> fb

Dem wage ich nicht zu widersprechen :D

Hatte aber bisher eher selten daß ich an nem RegEx noch was ändern musste, der einmal funktioniert hatte.

Mit den neuen Features von Perl6 kann man RegEx aber vielleicht auch etwas mehr Lesbarkeit verschaffen:

token sigil { \$ | @ | % };
token twigil { \. | ! | \? | \* };
token identifier { <[a-zA-Z_0-9]> };
regex perl6_variable { <sigil> <twigil>? <identifier> };

[freebyte]

baldur schrieb:
--------------------------------------------------------------------------------
> Hatte aber bisher eher selten daß ich an nem RegEx noch was ändern musste,
> der einmal funktioniert hatte.

Irgendwie formt sich in meinem Kopf bei Deiner Aussage der unangemessene Gedanke "Baldur hat seine Regex mit viel Elan und Liebe zum Detail irgendwie so hingefrickelt dass für die Menge im Testcase ihren Dienst erfüllt" xD

Wäre schön wenn es bei mir anders wäre - ich nehme Regex nur dann, wenn es in Bash ausufert. Gewonnen habe ich nicht wirklich was - statt 30 Zeilen Bash hab ich 30 Zeilen Doku der Regex für meinen Nachfolger.

> Mit den neuen Features von Perl6 kann man RegEx aber vielleicht auch etwas
> mehr Lesbarkeit verschaffen:

Kann Perl6 keine Schleifen, "instr()" "replace()" Operationen? select/case? if/elseif? Typsichere Vergleichsoperationen? Sowas macht Regex normalerweise völlig überflüssig.

fb

[baldur]

freebyte schrieb:
--------------------------------------------------------------------------------
> baldur schrieb:
> ---------------------------------------------------------------------------
> -----
> > Hatte aber bisher eher selten daß ich an nem RegEx noch was ändern
> musste,
> > der einmal funktioniert hatte.
>
> Irgendwie formt sich in meinem Kopf bei Deiner Aussage der unangemessene
> Gedanke "Baldur hat seine Regex mit viel Elan und Liebe zum Detail
> irgendwie so hingefrickelt dass für die Menge im Testcase ihren Dienst
> erfüllt" xD

Ich schreib meine RegEx immer mit viel Liebe ;)

Normal gehts ja nur darum daß ich mir irgendeine Information aus einem Textblock rausfischen muss. Ich will ja auch keine komplette Anwendungslogik mit RegEx programmieren ;)

> Wäre schön wenn es bei mir anders wäre - ich nehme Regex nur dann, wenn es
> in Bash ausufert. Gewonnen habe ich nicht wirklich was - statt 30 Zeilen
> Bash hab ich 30 Zeilen Doku der Regex für meinen Nachfolger.
>
> > Mit den neuen Features von Perl6 kann man RegEx aber vielleicht auch
> etwas
> > mehr Lesbarkeit verschaffen:
>
> Kann Perl6 keine Schleifen, "instr()" "replace()" Operationen? select/case?
> if/elseif? Typsichere Vergleichsoperationen? Sowas macht Regex
> normalerweise völlig überflüssig.

Klar kanns das alles. Deckt aber vollkommen andere Anwendungszwecke ab. Wenn ich z.B. in einem Pfad alle \ durch / ersetze brauch ich auch kein RegEx. Letztendlich sind RegEx auch nur ein Werkzeug wie alles andere auch. Gibt Situationen in denen sie wirklich nützlich sind, gibt Situationen in denen sie es nicht sind.

Was Perl6 an neuen Features für die RegEx hat fand ich vorhin beim drüberlesen zumindest mal interessant. Ein realistisches Einsatzszenario hab ich dafür aber auch noch nicht gefunden :)

> fb

[RipClaw]

Ich setze es sehr oft ein.

Für die Verarbeitung von Daten aus Textdateien ist mir bisher nichts besseres untergekommen und CPAN ist extrem hilfreich in allen Lebenslagen.

[olqs]

Als ich es mal mit \n probiert habe gings irgendwie nicht. War glaub ich irgendwas mit den unterschiedlichen Bash Versionen auf Linux/AIX/Solaris.
Ich habs mir dann so angewöhnt und sichere vorher immer mit OLDIFS=$IFS den Field Separator weg.
So kann ich auch hin und herschalten.

[Vanger]

Komisch. Sicher, dass es eine Bash war und nicht sh? Das Feature nennt sich "quoted string expansion" (http://tldp.org/LDP/abs/html/escapingsection.html#STRQ), wann es eingeführt wurde weiß ich aber leider nicht. Definitiv existiert es seit mind. 5 Jahren, zumindest ist das Konstrukt in Skripten die ich damals für Ubuntu 10.04 geschrieben habe und noch heute verwende (damals war Ubuntu noch gut... Schöne alte Zeiten).

[\pub\bash0r]

freebyte schrieb:
--------------------------------------------------------------------------------
> Dass man 3 völlig unterschiedliche "Beschreibungssprachen" für ein Projekt
> braucht scheint mir eine Erfindung der Neuzeit zu sein - früher hatten wir
> das alles im Code.

You wish. Gerade im (steinalten) Mainframe-Umfeld gibt's ziemliche viele gewachsene Konstrukte. Da hast Du Assembler für das ganz performancekritische Zeug. Dann hast Du "reines" COBOL, dann hast Du irgendwelche eigenen Abwandlungen, die per Präprozessor zu reinem COBOL werden und natürlich als Clue-Code zwischen all dem JCL.

Genauso ist es auch heute nicht unüblich, Teile von Server-Anwendungen in unterschiedlichen Sprachen zu schreiben - und wenn's nur Hilfsskripte in Bash o.ä. sind.

Von daher: im Frontend gibt's halt einen Stack von Sprachen genauso wie's im Backend solche Stacks gibt. "The right tool for the job" und so. Das war schon immer so, und wird wohl auch immer so sein :-)

[freebyte]

\pub\bash0r schrieb:
--------------------------------------------------------------------------------
> You wish. Gerade im (steinalten) Mainframe-Umfeld gibt's ziemliche viele
> gewachsene Konstrukte. Da hast Du Assembler für das ganz
> performancekritische Zeug. Dann hast Du "reines" COBOL, dann hast Du
> irgendwelche eigenen Abwandlungen, die per Präprozessor zu reinem COBOL
> werden und natürlich als Clue-Code zwischen all dem JCL.

Das ist irgendwie "Mit dem Pferd zum Auto aufs Fahrrad mit dem Kanu weiter bis man via Strassenbahn zu Fuss in der Oper landet" - damit hab ich kein Problem.

Aber dieses ständige herumgehopse zwischen völlig unterschiedlichen Welten (HTML, CSS, Javascript und ggf. noch XML-Dateien für irgendwelche Generatoren und Layouts zu konfigurieren ) macht mich ehrlich gesagt auch nach fast 20 Jahren noch völlig kirre - vorallem weil die Ergebnisse nur selten das halten, was die Toolsets versprechen (in Java bin ich schon lange zu einem recht starren x/y Terminal Layout zurückgekehrt und habe alle Designtools in die Tonne gekloppt).

fb