Les Journées Perl sont l'occasion de se rencontrer et parler de Perl en français. Y seront réunis des gens qui ont mené des projets en Perl, qui travaillent sur le langage lui-même, qui utilisent ce langage tous les jours et qui veulent en apprendre plus. Quelques-uns des meilleurs auteurs et développeurs Perl francophones seront présents pour discuter de leur travail, de leurs projets, pour les mettre aux niveaux de tous, débutants et confirmés.
Rejoignez nous à Marseille pendant ces deux jours pour parler et entendre parler de Perl dans le cadre de la Faculté des Sciences de Luminy, au milieu des calanques, de la lavande et des cigales. Frais d'inscription à la conférence : 25 ¤ (tarif réduit 15 ¤).
Les Mongueurs de Perl est une association française à but non lucratif, qui promeut l'utilisation de Perl et les groupes d'utilisateurs de Perl en France.
Aller plus loin
- Site de la conférence (1 clic)
- Inscription à la conférence (1 clic)
- Appel à présentations (1 clic)
- Les Mongueurs de Perl (1 clic)
# Sacré langage!
Posté par Stéphane Traumat (site web personnel) . Évalué à 3.
http://about.me/straumat
[^] # Re: Sacré langage!
Posté par Nicolas (site web personnel) . Évalué à 3.
[^] # Re: Sacré langage!
Posté par Stéphane Traumat (site web personnel) . Évalué à 4.
http://about.me/straumat
[^] # Re: Sacré langage!
Posté par Matthieu Moy (site web personnel) . Évalué à 7.
C'est très facile de parser du texte (y'a des expressions régulières partout), c'est faiblement typé, ce qui a mon gout est un avantage pour du code simple en non critique, mais inacceptable pour une grosse applie.
Ce que je trouve assez impressionnant, c'est ce qu'on peut faire en une ligne (les fameux "one liners" a tapper sur une ligne de commande).
Bon, ceci dit, il y a aussi des gens qui utilisent perl pour des assez grosses applies et qui en sont contents.
[^] # Re: Sacré langage!
Posté par Arthur Accroc . Évalué à 2.
L'administration système.
Pour ça :
- des fonctions de manipulation de fichiers directement intégrées au langage;
- pareil pour les fonctions de traitement (au sens traitement automatisé) de texte (expressions rationnelles, ensemble de possibilités équivalentes à celles d'awk, etc.); et les fichiers de configuration, de logs, etc. sont pratiquement tous des fichiers texte... à part sous Windows;
- des fonctions intégrées proches du système;
- probablement la plus grosse base de modules tous langages confondus ( http://www.cpan.org/(...) ), contenant, entre autres, tout ce dont on peut rêver pour l'administration système (j'ai déjà eu besoin de trucs pointus);
- possibilité de faire des unilignes plus courts et plus puissants qu'avec uniquement le shell (et les unilignes, c'est bien pratique pour faire rapidement et de manière automatisée un traitement lourd et/ou complexe sur des fichiers; voir http://www-106.ibm.com/developerworks/linux/library/l-p101/(...) et http://www-106.ibm.com/developerworks/linux/library/l-p102.html(...) );
- possibilité assez facile d'interface aussi bien texte, que graphique ou web (pratique pour réutiliser du code d'un script d'administration pour une interface qu'on fournit aux utilisateurs);
- disponible sur les principales plateformes et souvent déjà installé sur les systèmes de type Unix (on est parfois amené à intervenir sur des systèmes qu'on n'a pas installé soi-même)...
Qui plus est, même s'il est souvent considéré comme pas très lisible, Perl est toutefois un langage de haut niveau.
La dernière fois que j'ai dû regarder du code C, j'ai passé un certain temps à analyser ce que faisaient plusieurs dizaines de lignes... en fait un traitement de chaînes de caractères assez trivial, qui tient en quelques lignes de Perl (le but était justement de le refaire en Perl), mais fait en C "à la main" avec des pointeurs sur chaînes de caractères, des boucles qui les incrémentent, tout un tas de tests, c'est tout de suite une entreprise de grande ampleur... Au final, je trouve la version Perl bien plus lisible !
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Sacré langage!
Posté par applex . Évalué à 4.
Il y a aussi ceux qui ont appris le perl et à qui cela leur convient (ils n'ont donc pas besoin de changer).
[^] # Re: Sacré langage!
Posté par HSimpson . Évalué à -1.
Il y a aussi ceux qui ont appris le windows et à qui cela leur convient (ils n'ont donc pas besoin de changer).
[^] # Re: Sacré langage!
Posté par Emmanuel Seyman . Évalué à 6.
Au bout du compte, il n'y a presque jamais de raisons générales pour utiliser un langage de programmation plutôt qu'un autre parce que les différences entre deux langages sont souvent de l'ordre des gouts et des couleurs (donc des préférences individuelles).
Pourquoi Perl :
- C'est portable
- C'est puissant
- C'est un langage de haut niveau, donc pas de géstion de la mémoire comme en C
- Tout plein de modules sur www.cpan.org
- La syntaxe est un melange de shell et de C, ce qui fait qu'il est facile de commencer a programmer en Perl
- Une fois qu'on a acquis les bases, on peut utiliser les variables systèmes ($_, $!, $@, ...) pour alléger la syntaxe
Pour les gens qui veulent voir ce qui ca donne, je recommande de lire l'Introduction a Perl de Sylvain Lhullier qui était paru dans Linux Magazine France.
http://sylvain.lhullier.org/publications/intro_perl/index.html(...)
[^] # Re: Sacré langage!
Posté par Pierre Mallard . Évalué à 2.
Et surtout du temps de gagné pour le developpement par rapport a des langages un peu plus lourds comme le C.
Par contre je ne suis pas sur que Perl soit aussi facile a gerer dans des contextes exigeant en terme de rapidite d'execution que le C justement ?
[^] # Re: Sacré langage!
Posté par salvaire . Évalué à 5.
Le problème se fait sentir quand tu programme en Perl oo et en utilisant massivement les tables hachages pour les paramètres d'appels (ParamsValidate) et pour les classes. Pour des petits codes rapide ça va, au delà sa commence à ramer. Espérons que Perl 6, va améliorer la chose. En faîte, il faut coder les parties critiques en C ou C++, puis wrapper avec SWIG. À part ça les regexp tiennent le coups, même sur des fichiers de plusieurs dizaines Mo.
[^] # Re: Sacré langage!
Posté par lasher . Évalué à 1.
J'avais fait une appli en Perl qui devait parser des mails, générer un fichier XML décrivant ces mails, contacter une base MySQL, utiliser Image Magick pour déterminer les dimensions d'une image .... Bref, faire des trucs assez complexes. Avec une contrainte : mon appli plus les traitements des autres applis (programmées en Perl elles aussi) ne devait pas dépasser 8 secondes de délai entre réception du mail et émission du SMS de confirmation...
Mon petit parser de mail effectuait son boulot en moins de 0.5 seconde. Les autres applis en Perl faisaient à peu près pareil (avec en plus de l'analyse XML, des écritures dans la base, etc). Bref, Perl est rapide.
En C, ça aurait sans doute pris moins de temps à l'exécution. Maintenant, les quelques millièmes de secondes gagnés par le programme en C sont négligeables devant les quelques semaines de dév gagnées grâce à Perl.
[^] # Re: Sacré langage!
Posté par Pierre Mallard . Évalué à 1.
[^] # Re: Sacré langage!
Posté par lasher . Évalué à 0.
En apparté, pour ce qui est de la rapidité d'exécution/de la performance d'un code, je te renvoie à Abrash (Black book of programming, dispo gratuitement sur le net), au tout premier chapitre. En résumé : il démontre qu'à moins de maîtriser parfaitement l'assembleur (et donc la machine sur laquelle on programme, quelque part), la différence de performance entre un code écrit en c et d'un autre en ASM est négligeable. Et il écrivait ça il y a plus de 10 ans (à une époque où l'optimisation des compilateurs n'était pas ce qu'elle est maintenant), à l'époque des 486...
[^] # Re: Sacré langage!
Posté par Yves Agostini (site web personnel) . Évalué à 2.
- par défaut sur tous les systèmes Unix, même anciens, beaucoup de scripts de démarrage sont en perl : outil indispensable de l'administrateur système.
Sinon, autres exemples :
http://www.crium.univ-metz.fr/docs/devel/cleanperl/(...)
[^] # Re: Sacré langage!
Posté par totof2000 . Évalué à 3.
?????
C pas le cas ous aix
c pas le cas sous solaris, a ma connaissance, jusqu'a Solaris 9.
C pas le cas il me semble sous HP.
C pas le cas sous Netbsd: Perl est un package qui ne fait pas partie du systeme de base.
[^] # Re: Sacré langage!
Posté par Yves Agostini (site web personnel) . Évalué à 2.
- mod_perl : le "méchanisme" le plus complet et le plus performant pour agir sur le cycle de vie d'une requête apache. Ce qui permet de développer ses propres redirection dynamiques, authentification, autorisations, ....
http://perl.apache.org/docs/tutorials/index.html(...)
[^] # Re: Sacré langage!
Posté par M . Évalué à 2.
[^] # Re: Sacré langage!
Posté par reno . Évalué à 3.
Dans ce domaine, il rentre en concurrence avec Ruby et Python, mais étant plus ancien, plus de programmeurs connaissent Perl et la libraire CPAN est plus fournie.
Par contre, et la c'est mon avis personnel, Perl est tres "crade" comme language: les débutants font du code inmaintenable et les expérimentés se font plaisir en utilisant du code incompréhensible , une des conséquence de la philosophie TMWTDI..
(ma vie) appelé au secours pour la reprise d'un script (le repreneur ayant jeté l'éponge), il m'a fallu 1/2h de recherches pour remplacer *2 lignes* imbitables par 2 lignes qu'un débutant en Perl peut comprendre, 15min par ligne, ce n'est pas très rentable! (/ma vie), Ruby ou Python sont tous les deux bien plus propre..
Le seul problème avec Ruby et Python, c'est qu'ils sont tellement semblables l'un à l'autre, qu'il est très difficile de choisir entre les deux! Petite préférence personelle pour Ruby quand même..
[^] # Re: Sacré langage!
Posté par Zakath (site web personnel) . Évalué à 4.
En ce qui me concerne, je considère Perl comme le langage qui laisse le plus de liberté au programmeur (juste devant Common Lisp et à mille lieux de Java). Corollaire 1 : c'est puissant et on peut se lâcher. Corollaire 2 : on peut faire des choses TRES crades et impossibles à maintenir.
[^] # Re: Sacré langage!
Posté par pifou . Évalué à 1.
Si ces 2 langages étaient tellement semblables, l'un des deux n'existerait surement pas/plus. Ils jouent effectivement dans la même cours, ils ont les mêmes contraintes (langage de script orienté objet), le même type de licence libre mais la philosophie de chacun de ces langages est bien différente, ce qui fait qu'ils coexistent et qu'ils garderont leur communauté d'adeptes.
Pour le choix, c'est avant tout une histoire de goût, de besoin et d'expériences passées des développeurs.
Ma préférence va aussi vers Ruby qui correspond mieux à mes gouts et connaissances en développement informatique (càd. la programmation full-oo à la SmallTalk).
[^] # Re: Sacré langage!
Posté par reno . Évalué à 2.
Ah? Alors pourquoi existe-t'il des dizaines de variantes de Lisp? de language fonctionnels? de language au-dessus de Java (je connais moins la: groovy, pyke, il me semble)?
Python était légèrement moins OO que Ruby, mais il a rattrapé son "retard": c'est amusant c'est que les discussions entre Pythoniste et Rubyiste, ça ressemble à ça: "il est pas mal votre language, mais il n'a pas la feature XXX", les tenants de l'autre language répondant, "tu retardes, ça a été incorporté en version x.y"..
Bref honnetement blanc bonnet et bonnet blanc, les deux seules grosses différences: le self très laid de python (mais qui permet de mapper élégamment une fonction sur une liste), et la gestion des espaces qui a ses farouches supporters/détracteurs, ça ne fait pas lourd..
[^] # Re: Sacré langage!
Posté par Anonyme . Évalué à 3.
Que peut-on faire avec Perl ? Exemples et promotion du langage.
Support de ma conférence sur le sujet :
http://sylvain.lhullier.org/confs/perl-pour-quoi-faire.html(...)
[^] # Re: Sacré langage!
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
J'en sais plus sur perl désormais !
merci
http://about.me/straumat
[^] # Re: Sacré langage! ou langage sacré ? ;-)
Posté par R4f . Évalué à 2.
J'ai déjà utilisé ce support pour donner un cours express sur 2 jours, à Canon (à Cesson Sévigné près de Rennes), et son support est très bien fait !
Sinon, le grand avantage de Perl : plus qu'un langage, c'est une culture, notamment de la réutilisabilité. Le CPAN est une fonctionnalité non pas technique mais culturelle de Perl, que je regrette dans la plupart des autres langages (rien à voir avec le PEAR de PHP).
<ma vie>Grâce au CPAN, j'ai pu faire ce que je n'aurais jamais osé espérer faire autement. Exemple : faire un script qui :
- fait une requète dans une base de données SQL (PostgreSQL) --modules DBI et DBD::PostgreSQL--
- et qui stocke le résultat dans un fichier au format Excel -- module Spreadsheet::WriteExcel.
- Ensuite expédie le fichier Excel en fichier joint dans un e-mail --module MIME::Lite--
- en ayant chiffré cet e-mail avec GnuPG --module Crypt::GPG.
</ma vie>
Merci Larry Wall, merci Sylain et merci aux mainteneurs de modules Perl (ainsi qu'aux CPAN-testers) !
Un reproche souvent fait à Perl est que c'est un lange write-only, mais j'aurais envie de faire ce reproche à n'importe quel langage de programmation. Ce n'est justement pas le langage qui fait la propreté d'écriture, mais la culture.
Pour Perl en particulier, la problème vient (à mon avis) du fait que les gens programment en PERL sans savoir en tirer parti. Ils font du Perl avec des constructions proches de celles du C. Résultat : ils écrivent des choses qui marchent par hasard, et ne savent pas pourquoi en changeant une ligne tout part en saucisse... Second effet : pour ajouter des fonctionnalités, ils font des verrues à leur code déjà pas clean, et là ça devient la cata !
Résultat : lorsqu'il faut encore ajouter des trucs, ou intégrer à nouveau le code dans un projet plus vaste, on a mieux fait de tout récrire from scratch... Plus qu'un problème de langage, c'est un problème d'humains, et des ressources qu'ils ont pour réaliser leur travail.
[^] # Re: Sacré langage!
Posté par Pascal . Évalué à 2.
Pour le parsage de logs: il est fait pour ca.
Pour des CGI et sites Web dynamiques: il est excellent
Pour des applications en tout genre (notamment graphiques).
Pour des jeux, ca marche très bien: FrozenBubble est programmé en Perl et marche ma foi très bien.
[^] # Re: Sacré langage!
Posté par Stéphane Traumat (site web personnel) . Évalué à -1.
http://about.me/straumat
[^] # Re: Sacré langage!
Posté par totof2000 . Évalué à 1.
[^] # Re: Sacré langage!
Posté par lasher . Évalué à 0.
Il faudrait que tu précises alors. Parce que du Web dynamique en Perl, j'en ai fait, et ça se passe plutôt très bien.
Au pire (et pour répondre à un message plus bas) il existe l'équivalent de php avec perl (avec les mêmes inconvénients aussi).
L'overhead de Perl lorsqu'il est utilisé pour faire du cgi est extrêmement réduit dans le cas d'Apache, et ce grâce à mod_perl.
Pour ceux qui parleraient (encore) de l'illisibilité de Perl vis à vis des autres langages, je ne vois pas trop quel est le problème.
PHP est un langage qui peut lui aussi être très crade (car le code est embarqué au milieu du code HTML... Alors oui, on peut toujours faire des include, tout ça... Mais c'est quand même pas génial, ça force quand même à insérer du "<?php $maVar ?>" de temps à autres ...
... De même que le C ou le C++, pour ne prendre que ces langages comme exemple. Franchement, entre
#include <stdio.h> #include <stdlib.h> #include <errno.h> int main(void) { FILE *f = NULL; char buffer[81]; f = fopen("fichier.txt","r"); while (fread(buffer, sizeof(buffer), f) != NULL) printf("%s\n", buffer); if (ferror(f)) { perror("fread"); exit(errno); } if (fclose(f) != 0) { perror("fclose"); exit(errno); } return EXIT_SUCCESS; }Je me demande vraiment quel est le langage le plus illisible (et pourtant tous les deux peuvent être considérés comme lisibles je pense, sur un exemple aussi simple).
Tout ça pour revenir à la même rengaine : c'est la conception qui compte plus que tout ...
En Perl, c'est plus ou moins pareil, mais à l'envers : il faut insérer du code HTML dans du code Perl - et là on est heureux d'avoir des emprunts au shell du type :
En Java, il y a Struts ou JSF (qui ont le bon goût de masquer le code Java en utilisant des balises - JSTL + Struts tags par exemple - ce qui permet de ne plus avoir de code Java dans 99% des cas à l'intérieur du JSP), voire d'utiliser XML+XSLT pour le rendu...
... Mais mon petit doigt me dit qu'il existe des choses équivalentes en Perl :-)
[^] # Re: Sacré langage!
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
http://www.axkit.org/
C'est un environnement XML en Perl "à la cocoon" (Java). Tu peux mélanger le code Perl et le xhtml mais en général, il y a une complète séparation des deux. Même avec du code Perl embarqué, le xml reste valide !
[^] # Re: Sacré langage!
Posté par R4f . Évalué à 2.
Sinon, pour ceux qui seraient désireux de faire du Perl comme on fait du PHP (ou, je crois, de l'ASP), c'est à dire en incluant les scripts à l'intérieur de pages web, il y a de quoi faire avec Apache::ASP :
http://www.apache-asp.org/
Ca donne des trucs comme :
<!-- sample here -->
<html>
<body>
For loop incrementing font size: <p>
<% for(1..5) { %>
<!-- iterated html text -->
<font size="<%=$_%>" > Size = <%=$_%> </font> <br>
<% } %>
</body>
</html>
<!-- end sample here -->
Pour être honnête, je trouve ça marrant, et sûrement rassurant pour le débutant qui retrouve sa page HTML d'origine avec des petits bouts dynamiques dedans, mais à terme, dès qu'on fait des trucs réutilisables, des tempplates réutilisables et de l'internationalisation (i18n), on sépare vite fait son code de son HTML... Donc l'effet rassurant-car-mon-code-est-dans-mon-HTML ne marche plus.
[^] # Re: Sacré langage!
Posté par Sytoka Modon (site web personnel) . Évalué à 1.
Sinon, il faut un peu de temps pour rentrer dans AxKit mais après c'est formidable. Il est très facile de faire des formulaires. Je me suis fait par exemple ma propre extension qui charge le code perl d'une page html si un fichier du même nom existe (dans une arborescence parallèle (faut pas être fou)). Ca parait bête mais la complète dissociation code Perl / code HTML permet de ré-utiliser le code source bien plus facilement.
Il y a un peu trop de variables globales à mon humble avis dans AxKit et c'est parfois pas assez objet. Par exemple, le coup des formulaires, l'idéal aurait été de définir une classe comme nom du formulaire et de simplement connecter les méthodes de la classe au champ du formulaire... Je vais peut être le faire, ca me simplifierai grandement mon code.
[^] # Re: Sacré langage!
Posté par Alexandre Beraud . Évalué à 1.
# meuh
Posté par gc (site web personnel) . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.