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.
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...
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.
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.
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.
...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.
Das ist nichtmal der wirklich schlimme Teil.
Was mich wirklich erschreckt hat, sind die ganzen Workarounds für verschiedene Unterversionen von GTK.
Was aber nicht der Fehler von Perl ist. Gtk2 entwickelt sich halt und Fehler gibt es überall. Ähnliche Probleme hättest du auch mit anderen Sprachen.
Das ist bei anderen Scriptsprachen und Toolkits auch nicht viel besser. Da irgendwer mal was rangeflanscht und dann wird es nicht mehr weitergepflegt.
stetige pflege ist das grosse besuch in open source :)
naja ich hab halt meine ecken wo ich versuche es durchzuziehen, nur so klappts
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...
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.
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.
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.