Le vendredi 24 et le samedi 25 juin 2011, les Mongueurs de Perl organisent la huitième conférence « Les Journées Perl ». Cet événement rassemblera à la Cité des Sciences à Paris tous les utilisateurs de Perl, du débutant à l’expert. Ce sera l’occasion de rencontrer de nombreux grands noms de la communauté Perl francophone.
Appel à présentation
Pour être un succès, cette conférence a besoin d’orateurs et de présentations. Le français est préféré, mais l’anglais est admis. Certains conférenciers déjà inscrits sont anglophones. Cette année le thème principal de la conférence est « le Perl Moderne ». Vous êtes un expert de Moose, DBIx::Class, Catalyst, Dancer ? Venez présenter ces modules !
Perl en entreprise
Vous utilisez Perl dans votre entreprise ? Il est un élément central de votre architecture ? Il vous aide au quotidien à faire les tâches répétitives et rébarbatives ? Venez en parler, et partager votre expérience de professionnel avec nous !
Formation Perl
Cette année les Mongueurs souhaitent également proposer une formation à Perl. Comme le sujet peut être vaste, une page sur le wiki de la conférence a été créée pour vous laisser suggérer des sujets et vous inscrire, afin de mieux comprendre vos attentes d’une telle formation.
Faites circuler l’information !
Les Journées Perl 2011 ont besoin d’orateurs… et bien sûr, de public. Transmettez l’information à vos collègues, à vos amis, à votre service des ressources humaines, si vous pensez qu’ils peuvent être intéressés. Nous espérons vous accueillir nombreux à la Cité des Sciences.
Aller plus loin
- Les Journées Perl 2011 (179 clics)
- Formation Perl aux Journées Perl (84 clics)
- Actualité des Mongueurs (72 clics)
# C'est quoi Perl?
Posté par zaurus (site web personnel) . Évalué à -7.
C'est pour encrypter des algorithmes? ;)
# Pas trop de clichés SVP
Posté par rogo . Évalué à 4.
Pour ceux qui ne connaissent pas ou qui en sont resté au langage d'il y a 10 ans, il y a beaucoup de clichés attachés à Perl. Quelques précisions en vrac :
On n'est pas obligé d'apprécier le principe TIMTOWTDI (There Is More Than One Way To Do It), mais rien n'oblige à écrire du code sale en Perl, pas plus qu'en C ou en Haskell.
Comme toujours, il faut choisir un langage selon le contexte (projet, goûts personnels, documentation, bibliothèques...). Il m'arrive de pester contre Perl (c'est gonflant, ces déréférencements avec accolades), mais pas plus qu'en Ruby (REXML, c'est de la daube), en PHP (qui m'a pondu une cochonnerie pareille ?), en C++ (oh, la jolie fuite mémoire) ou en Python (pourquoi mon code plante à chaque mise à jour majeure de Python ?). Et je ne parle même pas de Java, car je n'aime pas programmer en XML.
[^] # Re: Pas trop de clichés SVP
Posté par Bruno Michel (site web personnel) . Évalué à 2.
Certes, mais tant qu'à faire, si le langage encourage à « penser bien », ce n'est pas de refus ;-)
Pour le reste, je ne connais pas le Perl moderne, mais ce que l'on m'en a dit va dans ce sens : ça n'a plus grand chose à voir avec le Perl que j'ai connu et on peut écrire du code propre et lisible avec (quand il est bien écrit).
Heureusement, qu'il y a Nokogiri.
[^] # Re: Pas trop de clichés SVP
Posté par Sébastien Aperghis-Tramoni (site web personnel) . Évalué à 2.
C'est aussi et surtout que, comme avec tout langage de programmation, cela dépend de la compétence, de l'expérience. Personnellement, il y a assez peu de différences, au niveau présentation, entre le code que j'ai écrit il y a plus de 10 ans et celui que je fais aujourd'hui.
Le mouvement "Moderne Perl", c'est surtout l'ajout de fonctionnalités très avancées comme le support objet avancé avec Møøse (traits, rôles, et autre introspection complète via le protocole méta-objet), l'ajout de nouveaux mots-clés comme
class,methodou ceux qu'on décide avec Devel::Declare qui donne le sous-mouvement des syntaxes déclaratives.. À plus haut niveau, ce sont les frameworks web Catalyst](http://www.catalystframework.org/) (framework complet) et Dancer (µframework).Et la grande force de Perl est que tout cela fonctionne aussi bien sur les versions de Perl en production (5.8, 5.10) que sur celle qui va sortir (5.14).
[^] # Re: Pas trop de clichés SVP
Posté par tyoup . Évalué à 1.
Perl 6 ?
Pardon je vais me cacher...
[^] # Re: Pas trop de clichés SVP
Posté par Sébastien Aperghis-Tramoni (site web personnel) . Évalué à 0.
Rakudo, un interpréteur Perl 6 au dessus de Parrot, est disponible en béta (Rakudo Star) depuis l'an dernier.
[^] # Re: Pas trop de clichés SVP
Posté par Antoine . Évalué à 3.
Parce qu'il est très très mal écrit ? :)
(ou parce que tu n'as pas de chance; mais si tu donnes un exemple ça peut être intéressant)
[^] # Re: Pas trop de clichés SVP
Posté par Victor STINNER (site web personnel) . Évalué à 4.
Python (pourquoi mon code plante à chaque mise à jour majeure de Python ?
Si tu parles de Python 2 vers Python 3, il y a des outils et beaucoup de documentations pour migrer vers Python 3.
Mais je pense que tu veux dire version 2.n vers 2.n+1. Or je n'ai jamais eu de soucis dans ce sens. Je joue plutôt à essayer de rendre compatible Python 2.n-1 un code écrit pour 2.n, et il y a pas mal d'effort dans ce sens (ex: multiprocessing existe pour Python 2.4 et 2.5). Je lis souvent que Python casse la compatibilité, or j'ai souvent vu du code Python 2.4 tourner avec Python 2.5, 2.6 et 2.7, mais jamais de code qui ne passe pas.
Parfois, Python fait des blagues : genre le module md5 est marqué comme désuet dans Python 2.6 puis finalement n'est pas supprimé dans 2.7. Le seul changement incompatible que je connaisse est struct.pack() qui lance une struct.error avec Python 2.7, alors qu'avant ça n'affichait qu'un DeprecationWarning. L'avertissement était déjà affiché dans Python 2.5, alors y'avait quand même le temps de préparer la migration.
Selon moi, l'API Python est trop stable, ça serait sympa de parfois faire table rase pour nettoyer les erreurs du passé. Ça a été fait en profondeur dans Python 3, mais ça serait pratique de pouvoir le faire petit à petit. En pratique, dans Python 2, quand l'API évolue, l'ancienne est conservée. Exemple : le module threading a plein de fonctions et méthodes avec des noms en double (ancienne / nouvelle convention).
Maintenant, comme l'a écrit Antoine : je serai intéressé d'avoir un exemple d'incompatibilité entre des versions N et N+1.
[^] # Re: Pas trop de clichés SVP
Posté par Sébastien Aperghis-Tramoni (site web personnel) . Évalué à 2.
Sauf que chez moi, la version de Python en production est la 2.4. Et je ne sais même pas si la future version en production sera 2.5 ou 2.6.
La stabilité de Perl sur le long terme n'est pas là par hasard..
[^] # Re: Pas trop de clichés SVP
Posté par claudex . Évalué à 2.
Donc, tu ne seras pas impacté par le problème.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pas trop de clichés SVP
Posté par Victor STINNER (site web personnel) . Évalué à 4.
Le seul changement incompatible que je connaisse est struct.pack() qui lance une struct.error avec Python 2.7, alors qu'avant ça n'affichait qu'un DeprecationWarning. L'avertissement était déjà affiché dans Python 2.5, alors y'avait quand même le temps de préparer la migration.
Oh, j'ai été un peu trop vague : pack() sert à sérialiser des données (encoder en octets). Jusqu'à Python 2.6, l'encodage de nombres non signés (formats B, H, I, L, ...) tolérait les nombres négatifs en les convertissant en nombres non signés (ex: -1 devient 0xFF avec le format B). unpack(pack(...)) n'est donc plus bijectif : on ne récupère pas exactement ce qu'on a rentré (-1 devient 255). L'ancien comportement peut être surprenant et causer problème. Maintenant, il est aussi possible que des programmes reposent sur ce comportement, et vont donc arrêter de fonctionner avec Python 2.7. La code est plutôt simple à adapter pour garder le même comportement (ex: x & 0xFF pour le format B) et sera encore compatible Python < 2.7. Sur ce cas précis, effectivement Python a cassé la compatibilité ascendante.
D'ailleurs, as-tu essayé de lancer ton projet avec Python 2.7 pour voir si Python a cassé la compatibilité ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.