Warum Perl? Warum nicht?

[hotti]

hi,

Frage an die Perler, hinsichtlich Webanwendungen: Was spricht für Perl, was spricht dagegen? Natürlich freue ich mich auch über Antworten von Nicht-Perlern und auch witzige Antworten sind willkommen.

Viele Grüße,
Horst Perlhuhn (Vetter von Haselhuhn)

[Matti Mäkitalo]

Hi,

Frage an die Perler, hinsichtlich Webanwendungen: Was spricht für Perl, was spricht dagegen? Natürlich freue ich mich auch über Antworten von Nicht-Perlern und auch witzige Antworten sind willkommen.

Ich habe lange Jahre Webanwendungen mit perl entwickelt, bin da aber seit einiger Zeit draußen.

Zu den Gründen, perl nicht einzusetzen, zählt:
 - Verfügbarkeit von Entwicklern
Entwickler für andere Sprachen sind IMHO leichter zu finden. Bei Applikationen, welcher von mehr als einer Person entwickelt werden, muss man ja schon schauen, wen man da so findet. Und da sind PHP und Java Entwickler leichter zu haben.

- Web-Frameworks
Ich habe damals einige Zeit (so etwa 2 Jahre) mit HTML::Mason entwickelt, um eine Trennung von Darstellung und Logik zu erreichen.
Im Prinzip verfolgt Mason den gleichen Ansatz wie etwa PHP, JSP oder tntnet, nur eben mit perl.
Leider hat es sich damals in der Fläche nicht durchgesetzt.

- Sprache
Man kennt die (Vor-)Urteile: perl Code ist unlesbar, ...
Und obwohl die Einwendung richtig ist, dass es
 a) in allen Sprachen möglich ist, unlesbaren Code zu produzieren und
 b) es in perl möglich ist, lesbaren Code zu entwickeln,
so ist es doch so, dass gerade bei den Entscheidern, welche Sprache eingesetzt wird, das Vorurteil im Hinterkopf ist.

Für den Einsatz spricht, dass perl eigentlich eine sehr schöne Sprache ist. Mit schön meine ich in diesem Zusammenhang, dass perl Sprachkonstrukte es erleichtern, komplizierten Code auf das Wesentliche zu reduzieren.
Als Beispiel finde ich die map {} und grep {} Aufrufe sehr nett, diese vermisse ich doch in anderen Sprachen.
(z.B. ist PHP IMHO vollkommen häßlich. Man merkt dieser Sprache einfach an, wie sie entwickelt wurde).

CPAN ist eine hochwertige Modulbibliothek, aber da schließen andere Sprachen durchaus auf.

Das waren meine 5 Cent, aber ich bin schon einige Jahre "draußen" aus der perl-Entwicklung und habe mich auf CLI-Skripte beschränkt.

Bis die Tage,
Matti

[hotti]

hi,

Das waren meine 5 Cent,

ein Haufen Geld, danke Dir!!!!!

Meine 4.99 Cent: Ich beschreibe z.Z. ganz neue Wege, was meine Entwicklungen von CGIs betrifft, insbesondere hinsichtlich der Option, Ajax draufzusetzen. So wird bei mir nun aus jeder Benutzereingabe ein Ausgabeobjekt erzeugt, das kann innendrinne auch eine Sammlung mehrerer Objekte sein. Die dazugehörige "package Out;" ist mit Perl schnell geschrieben, ggf. steht schon eine Klasse zur Verfügung, die alle Berechnungen erledigt, von der meine "package Out" erben kann. Meine "package Out" bringt nun das Basis-Objekt (*) so in Form, dass a) damit HTML erzeugt werden kann oder dass es b) als Ajaxresponse gesendet werden kann, Inhalt und Darstellung sind getrennte Dinge. Fehlerhafte Benutzereingaben sind im $out-Objekt ggf. eingebaut, so dass die an der richtigen Stelle angezeigt werden und sich so die Ausgabe einer gesonderten Fehlerseite erübrigt.

(*) ggf. sind Atributnamen umzubenennen oder zu Löschen, oder neue Atribute einzubauen.

Sicher ist sowas auch mit anderen Sprachen zu machen, aber wenn das mit Perl einen Code erzeugt, der schlecht lesbar ist, also ich weiß ja nicht: Der Code wird dermaßen kurz und überschaubar, dass einer, der son Script in die Hand bekommt, mühelos die Pflege übernehmen kann.

Zum Vorurteil unlesbarer Code: Da ist was dran, was Module aus zweiter Hand betrifft. I.d.R werden jedoch nicht die Module "gepflegt" sondern die Scripts, die damit arbeiten.

Hotti

[Alexander (HH)]

Moin Moin!

Zum Vorurteil unlesbarer Code: Da ist was dran, was Module aus zweiter Hand betrifft. I.d.R werden jedoch nicht die Module "gepflegt" sondern die Scripts, die damit arbeiten.

Wer mir was von unlesbarem Perl-Code vorjammert, den verweise ich seit neuestem auf MUMPS (die Computer-Krankheit, nicht die Kinderkrankheit). Wie immer ist die englische Wikipedia besser, man beachte dort das zweite Beispiel. Das ist Realität in MUMPS, das erste Beispiel ist nur die aufgehübschte Version für den Fall, dass mal jemand glaubt, für oder gegen MUMPS entscheiden zu müssen. Ein bald 50 Jahre altes Schwein wird auch mit einem Faß Schminke nicht mehr hübsch.

Alte unleserliche Perl-Scripte kann man mit perltidy wieder "geradebügeln", und notfalls vorsichtig mit Hilfe von perlcritic grobe Patzer beseitigen.

Und wer bei neuem Perl-Code hartnäckig meint, möglichst ohne Whitespace und Buchstaben auskommen zu müssen, der wird mal kurz in die hinterste Ecke des EDV-Lagers geführt und bekommt dort eine "Einführung" in die Kunst, lesbaren Code zu schreiben. ;-)

Im Web-Umfeld ist Perl mittlerweile ziemlich unterschätzt, nicht zuletzt, weil das "Visual Basic des WWW" (Zitat eines Kollegen) namens PHP eben sehr schnell zu Ergebnissen führt. Ob die dann sauber und wartbar sind, oder auch nur stabil und sicher, ist eine völlig andere Frage. Da sehe ich gerade bei PHP riesige Probleme. ASP schätze ich ähnlich ein, eben der MS-lastig und mit allen Nachteilen, die eine MS-Umgebung so mitbringt. Und Java hat, mittlerweile dank deutlich schnellerer CPUs teilweise zu unrecht, immer noch den Ruf, grausam langsam zu sein. Viele Java-Entwickler haben aber nicht verstanden, wie das WWW funktioniert. Typisches Symptom von Java-Web-Anwendungen: Nie den Back-Button anklicken, sonst explodiert alles. Ruby und Rails machen Perl viel Druck, haben aber auch viel von Perl kopiert. Auch da gilt: Schnelle Ergebnisse mit fraglicher Sicherheit und Wartbarkeit. Allerdings sind Ruby und Rails bei den Massenhostern noch nicht angekommen.

Dort findet man PHP und meistens noch ein völlig antikes Perl, typischerweise 5.5 oder 5.6, selten auch mal 5.8. Mittlerweile sind wir bei 5.12, was viele Dinge wesentlich besser / eleganter / schneller erledigen kann als 5.5/5.6, und z.B. auch ordentlich mit Unicode umgehen kann.

Ein klarer Nachteil von Perl ist die Kompatibilität zu altem Code, bis hin zu Perl 1.0, die dazu zwingt, in jeder Datei erst einmal sinnvolle Einstellungen vorzunehmen (#!perl -T, use strict; use warnings; use 5.010;). Und vielen Leuten muß man mit PBP die alte Perl4-Syntax aus der Rübe klopfen ...

Alexander

[hotti]

Moin Moin!

vielen Dank für Dein Feedback!

Wer mir was von unlesbarem Perl-Code vorjammert, den verweise ich seit neuestem auf MUMPS (die Computer-Krankheit,

Echt krank, so ein Mumpitz ;-)

Hier mal ein "schönes" (leserliches) Perl, wo ich gerade dran bin, die Kontrollstruktur in einem CGI:

  
my $u = PicoBello->new;  
my $out = Out->new('192.168.0.0/16', 17); # Vorbelegung mit Beispiel  
  
if($u->param){  
	$out = Out->new($u->param('cidr'), $u->param('newmask')); # Benutzereingabe  
	if($u->param('calc')){  
		# CGI Response  
		print $u->header, $u->start_html, $u->menu, front(), $u->end_html;  
	}  
	elsif($u->param('x_calc')){  
		# Ajax Response erzeugen  
		# wird morgen zwischen Zähneputzen und Pinkeln fertig  
	}  
	else{  
		# unbekannte Parameter  
		print $u->redirect($ENV{SCRIPT_NAME});  
	}  
}  
else{  
	print $u->header, $u->start_html, $u->menu, front(), $u->end_html;  
}  

und ein Blick in das Objekt $out:

  
bless({  
  1 => {  
        Broadcastadresse => "192.168.255.255",  
        HEADLINE         => "Basisnetz 192.168.0.0/16",  
        Hosts            => 65_534,  
        MASKLEN          => 16,  
        Netzadresse      => "192.168.0.0",  
        Netzmaske        => "255.255.0.0",  
        Teilbarkeit      => "Ja",  
      },  
  2 => {  
        Broadcastadresse => "192.168.127.255",  
        HEADLINE         => "Erstes Subnetz 192.168.0.0/17",  
        Hosts            => 32_766,  
        MASKLEN          => 17,  
        Netzadresse      => "192.168.0.0",  
        Netzmaske        => "255.255.128.0",  
        Teilbarkeit      => "Ja",  
      },  
  3 => {  
        Broadcastadresse => "192.168.255.255",  
        HEADLINE         => "Letztes Subnetz 192.168.128.0/17",  
        Hosts            => 32_766,  
        MASKLEN          => 17,  
        Netzadresse      => "192.168.128.0",  
        Netzmaske        => "255.255.128.0",  
        Teilbarkeit      => "Ja",  
      },  
  NANZ => 2,  
  NM => 17,  
}, "Out")  

$out wird aus der Benutzereingabe zusammengebaut, da ist alles drin, was für eine CGI-Response oder eine Ajax-Response gebraucht wird. HTML wird über $u->PicoBello erzeugt und die Funktion front() bringt das Forumular sowie die Netztabellen in den Browser. Für eine Ajax-Response wird $out einfach nur serialisiert (nach meiner "Art Hottentott" *G*).

Isset net schie? Ich mach jetzt Pfeierabend :P

Grüße an Alle,
Hotti

PS: Was mich an Perl nervt, ist das # weils nur in einer Zeile güllt...
Java: Mein Gott, tausende Zeilen try/catch, damit endlich mal was geht.
PHP: das Objekt-Zeugs guck ich mir mal an, versprochen ;-)
c: Ich liebe struct
Perl: Ich empfehle strict, eine Zeile, große Wirkung
Delphi, Pascal: Grüß mir den Nicolaus (Wirth)

[hotti]

Moin Moin!

  

> 	elsif($u->param('x_calc')){  
> 		# Ajax Response erzeugen  
> 		# wird morgen zwischen Zähneputzen und Pinkeln fertig  

Rockt wie die Sau:

  
	elsif($u->param('x_calc')){  
		# Ajax Response erzeugen  
		print $u->header, $out->serialize;  
	}  

Siehe: Habe fertig Anwendung (Mit|Ohne JavaScript)

Nochn Wort zur Lesbarkeit und Pflege: Fast ein halbes Jahr lang habe ich kein Stück Perl-Code geschrieben, mit OOPerl bin ich jedoch sehr schnell wieder reingekommen. Ein Perl-Object (PO) ist nichts weiter als eine Hash-Referenz. Mit einem PO lassen sich Darstellung und Inhalte klar voneinander trennen, was zu einem überschaubaren Code führt, der auch mal aus der Hand gegeben werden oder nach längerer Pause wiederaufgenommen werden kann. OOP mit Perl ist simple, in PO's sehe ich jedoch nicht nur die üblichen OOP-Phrasen (Polymorphie, Vererbung...) sondern mehr Möglichkeiten zur Nutzung, was das Beispiel zeigt.

Schönen Sonntag!
Horst Sonnenschein

[hotti]

hi,

Siehe: Habe fertig Anwendung (Mit|Ohne JavaScript)

Und, weils so schön geht: So wirds gemacht

Horst Brennholz

[Alexander (HH)]

Moin Moin!

PS: Was mich an Perl nervt, ist das # weils nur in einer Zeile güllt...

  
#!/usr/bin/perl -w  
use strict;  
  
my $x=1;  
  
=begin comment  
  
$x=42; # ganz blöde Idee, killt die ganze Platte  
$x=0815; # öm, schonmal was von oktal gehört?  
$x=4711; # autsch!  
  
=end comment  
  
=cut  
  
print $x;  

Wahlweise auch "=for comment", das gilt aber nur für einen Absatz (sprich: bis zur ersten komplett leeren Zeile nach =for), danach landet der Rest bis zum "=cut" in der Doku. Siehe perlpod und perlfaq7.

Alexander

[hotti]

Moin Moin!

PS: Was mich an Perl nervt, ist das # weils nur in einer Zeile güllt...

=begin comment
=end comment

>   
  
Jow, Pod, is klar, geht, danke für den Hinweis.  
  
Hotti  
  
PS: Aber so richtig konnte ich mich damit auch noch nicht anfreunden ;-)

[Alexander (HH)]

Moin Moin!

PS: Was mich an Perl nervt, ist das # weils nur in einer Zeile güllt...

=begin comment
=end comment

>   
> Jow, Pod, is klar, geht, danke für den Hinweis.  
  

> PS: Aber so richtig konnte ich mich damit auch noch nicht anfreunden ;-)  
  
Da bist Du nicht alleine. Aber mit einem guten Editor ist das "#" kein wirkliches Problem, mit ein oder zwei Tastatur-Shortcuts ist ein Block schnell hinter "#" versteckt oder wieder hervorgeholt.  
  
Alexander

-- 
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".

[hotti]

hi,

PS: Aber so richtig konnte ich mich damit auch noch nicht anfreunden ;-)

Da bist Du nicht alleine. Aber mit einem guten Editor ist das "#" kein wirkliches Problem, mit ein oder zwei Tastatur-Shortcuts ist ein Block schnell hinter "#" versteckt oder wieder hervorgeholt.

Wo wir grad beim Editor sind: In meinem habe ich [Strg][1] als Shortcut zum ausführen der geladenen Datei als Perlscript, die Ausgabe erfolgt im "Programmausgabefenster". [Strg][2] ist die perldoc. Und jetzt der Hack: [Strg][3] => PHP ;-)

[Strg][4] wiederum lädt die Datei zum Webserver hoch...

Hotti

[Beat]

Zu den Gründen, perl nicht einzusetzen, zählt:

• Verfügbarkeit von Entwicklern
  Entwickler für andere Sprachen sind IMHO leichter zu finden. Bei Applikationen, welcher von mehr als einer Person entwickelt werden, muss man ja schon schauen, wen man da so findet. Und da sind PHP und Java Entwickler leichter zu haben.

Da frage ich mich, ob ich mich nicht gerade als Perl-Entwickler bei Buden bewerben soll. Viele haben ja noch legacy-Code rumliegen.

Allerdings scheint mir, dass heute allgemein die Technologie-Alternativen grösser geworden sind. PHP ist nur noch bei kleinen Webpages der Platzhirsch.
Da kommen Tools wie less (css), und die setzen auf ruby (ohne dass man das als Anwender jetzt aber verstehen muss).

mfg Beat

[Tim Tepaße]

Als Beispiel finde ich die map {} und grep {} Aufrufe sehr nett, diese vermisse ich doch in anderen Sprachen.

Ähm, vermisst Du nur die bequeme Syntax? Weil ... map, filter, reduce und Verwandte findet man doch in den allermeisten aktuellen Sprachen?

[Matti Mäkitalo]

Hi,

Als Beispiel finde ich die map {} und grep {} Aufrufe sehr nett, diese vermisse ich doch in anderen Sprachen.

Ähm, vermisst Du nur die bequeme Syntax? Weil ... map, filter, reduce und Verwandte findet man doch in den allermeisten aktuellen Sprachen?

Ich vergleiche einfach mal mit PHP:
für ein ordentliches map (array_map) braucht man PHP 5.3 (mit Closures), kam lt. Wikipedia am 30. Juni 2009 raus. Dadurch, dass ich meist auf die Enterprise-Linux-Distributionen eingeschränkt bin (RHEL, SLES), habe ich nur PHP 5.1 zur Verfügung, daher fällt es raus.
Aber ansonsten ist die Perl-Schreibweise "Zucker" im Vergleich zu dem Gedöns mit Closures.

Aber du hast recht, mit Closures ist das ganze dann in den meisten Sprachen doch deutlich bequemer.

Bis die Tage,
Matti

[hotti]

hi,

Aber ansonsten ist die Perl-Schreibweise "Zucker" im Vergleich zu dem Gedöns mit Closures.

Closures in Perl? Bei mir selten.

Da bietet doch gerade Perl ganz andere, produktivere und elegantere Ansätze, ich denke da z.B. an tie(). Und überhaupt sind (zumindest meine) Perlscripts bei weitem nicht so abhängig von der Interpreter-Version, wie das in PHP schon bei den einfachsten Dingen passiert, laufend musste da mit phpinfo() gucken, ob was überhaupt auf der jeweiligen Plattform/Provider geht und da ist alles komplett anders als zuhause im stillen Kämmerlein ;-)

Aber du hast recht, mit Closures ist das ganze dann in den meisten Sprachen doch deutlich bequemer.

Oder auch mal 'static' variablen in c-Subroutinen, was ich gelegentlich in Perl vermisse.

Hotti

[Robert B.]

Moin,

Frage an die Perler, hinsichtlich Webanwendungen:

Ich nehme mit meiner unqualifizierten Meinung (vorherige Webhoster boten leider kein Perl) auch mal teil.

Was spricht für Perl,

Neben Perl an sich z.B. das Template-Toolkit.

was spricht dagegen?

Die Verbreitung bei Hostern und damit ein Fehlen an „Killeranwendungen“. Für mich persönlich, der sich noch nicht so mit dem Apache2-Modul beschäftigt hat, könnte dessen Dokumentation auch besser sein, denn der Einstieg passte schon irgendwie nicht zu dem, was ich auf dem Server vorfand.

Schönen Sonntag,
Robert

[Jean-Max]

Bounjoun hotti,

Frage an die Perler, hinsichtlich Webanwendungen: Was spricht für Perl, was spricht dagegen? Natürlich freue ich mich auch über Antworten von Nicht-Perlern und auch witzige Antworten sind willkommen.

In meinem speziellen Fall war die Entscheidung für Perl einfach: als ich Mitte 1998 anfing, meine ersten, zaghaften Schritte Richtung Webpublizierens unternahm, strampelte PHP noch im Babyanzug. CGIs wurden in Perl geschrieben, das SELFHTML-Forum hatte noch keine PHP-Kategorie. Fluch oder Segen, es gab auch die Skriptsammlung von Matt Wright (aus deren wwwboard.pl Stefan Münz das erste Skript für's Forum bastelte, und auch für meine erste Version der SELF-Visitenkarten herhalten musste).

Tja, und mit der Zeit lernt man die Sprache kennen und schätzen, warum also zu einer anderen wechseln?

Adiou.

[hotti]

Bonjour,

In meinem speziellen Fall war die Entscheidung für Perl einfach: als ich Mitte 1998 anfing, [..]

Jes, those where the days.... 1998 habe ich auch mit dem Quatsch angefangen.

Tja, und mit der Zeit lernt man die Sprache kennen und schätzen, warum also zu einer anderen wechseln?

Das ist so eine richtig gute Antwort auf französische Art ;-)

Viele Grüße,
Horst Hackebeil

PS: Hab heute auf der A3, A67 und A66 den Großraum FFM gestreift und am hessischen Rheinufer in Mainz einen kleinen Spaziergang unternommen, tat gut!

[jobo]

Hallo,

Frage an die Perler, hinsichtlich Webanwendungen: Was spricht für Perl, was spricht dagegen? Natürlich freue ich mich auch über Antworten von Nicht-Perlern und auch witzige Antworten sind willkommen.

Zend Framework und alternative Syntax. Und Tiobe. Hatten wir das nicht grade hier im Forum vor kurzem?

Gruß

jobo