Les Journées Perl, plus que 10 jours pour s'inscrire !

Posté par  . Modéré par Benoît Sibaud.
Étiquettes :
0
5
nov.
2007
Perl
Dernière ligne droite pour l'organisation des Journées Perl 2007 : dans dix jours se tient à Lyon la conférence annuelle des développeurs Perl, qui rassemble les meilleurs spécialistes francophones (mais pas seulement) de ce langage à la flexibilité et aux possibilités infinies. Toujours plus jeune, toujours plus costaud, c'est le Perl d'aujourd'hui et de demain. Venez le découvrir avec nous, avec les auteurs des articles Perl de GNU/Linux magazine et avec quelques grosses pointures européennes de la communauté.

Au programme :
  • Perl 5.10 ;
  • Développement web avec Catalyst, le framework qui monte ;
  • Monts et merveilles avec Parrot, la VM de Perl6 ;
  • Développer plus vite et mieux, outils et méthodes ;
  • « Success stories » ;
  • Rencontres, échanges, gastronomie, etc.
Tarif spécial étudiants (15 Euros), tarif risible pour les autres (30 euros), rien ne devrait vous retenir ! Rejoignez-nous les 16 et 17 novembre à Lyon. Un rappel, une brève étant déjà passée il y a deux mois. La nouveauté c'est que le programme est fait, la liste des présentations vous donnera une idée bien plus précise de qui viendra et des thèmes abordés lors de la conférence.

Aller plus loin

  • # PERL?

    Posté par  . Évalué à -1.

    ... c'est pas ce pseudo langage qui permet aux admins système de se croire programmeur ?
    ok ok je ->[]
  • # gérontophilie

    Posté par  . Évalué à 1.

    Toujours plus jeune

    En général c'est ce qu'on dit de ceux qui ont un pied dans la tombe.

    Développer plus vite et mieux, outils et méthodes

    Je vois : vous encouragez les gens à passer à Python. Bonne idée !
    • [^] # Re: gérontophilie

      Posté par  (site web personnel) . Évalué à 0.

      http://www.ohloh.net/languages?sort=projects&commit=Sort
      perl : 2039 projets
      python: 1700 projets
      • [^] # Re: gérontophilie

        Posté par  . Évalué à 4.

        Et quels sont tes conclusions ?
        C'est relativement proche comme valeurs...S'il on regarde du coté de la progression du nombre de projet Perl semple "plus linéaire" et Python "plus exponentiel".
        • [^] # Re: gérontophilie

          Posté par  (site web personnel) . Évalué à 0.

          Bon aussi, sur les quelques 2000 projets Perl, il n'y a qu'une fraction des 12 400 modules du CPAN. Dans mon cas seuls 3 des 27 modules que je maintiens sont sur Ohloh.

          Et on estime en général que le DarkPAN fait 4 à 10 le CPAN (juste histoire de lancer quelques chiffres de plus ;-)
      • [^] # Re: gérontophilie

        Posté par  (site web personnel) . Évalué à 5.

        En revanche, si tu regardes la tendance générale de l'évolution :

        http://www.ohloh.net/languages/compare?commit=Update&l0=(...)
        http://www.ohloh.net/languages/compare?commit=Update&l0=(...)

        Conclusion : il y a de plus en plus de contributeurs qui font du python et les projets python bougent plus.

        Je pense que perl est en train de perdre la course...

        Pour reboucler avec tes stats, ça veut dire que étalé sur 15 ans, il y a plus de projets perl et plus de contributeurs perl que python, mais que si on prend les dernières années, il y a plus de nouveaux sous python que sous perl.

        Au fait, perl 6, c'est pour avant notre mort ? (gniark gniark)

        Génial ce comparateur ohloh en tout cas. Ca permet enfin de faire des trolls de qualité. Dans les autres trucs sympa à regarder, zsh vs bash. KDE vs Gnome serait génial si il n'y avait pas un gros problème avec le svn de KDE, qui fait que le projet semble commencre en 2006.
        • [^] # Re: gérontophilie

          Posté par  (site web personnel) . Évalué à 1.

          Je pense que perl est en train de perdre la course...

          Parce qu'il y a une course ?

          Au fait, perl 6, c'est pour avant notre mort ?

          Ben on peut déjà en faire en faire tourner une bonne partie avec Pugs, et les règles de compilation de Perl6 sont déjà en grande partie écrite par Larry. Il ne manque pas grand-chose en fait.
          » http://www.pugscode.org/

          C'est vrai que Perl 6 met du temps à venir, mais Perl 5 fonctionne bien, donc il n'y a pas d'urgence.
  • # dubitatif...

    Posté par  (site web personnel, Mastodon) . Évalué à 2.

    c'est rien de dire que je suis dubitatif sur les chiffres de ohloh et sur leur pertinence.
    Je bosse sur un projet Perl, et http://www.ohloh.net/languages/8 donne dans la liste des "Recently active contributors" la bagatelle de 4 de nos contributeurs (positions 7,17,22,24)
    Certes le projet est très actif surtout en ces temps de Release proche. Mais quand même. Nous sommes sur-représentés, ce qui me laisse à penser que l'échantillon n'est pas significatif !

    PS : dire que Perl est un langage qui est proche de la porte de sortie, c'est ignorer tout l'existant. Dans notre cas par exemple, il est impossible de migrer sur autre chose même si on le voulait : Koha est beaucoup trop complet et compliqué pour que ce soit envisageable !
    • [^] # Re: dubitatif...

      Posté par  . Évalué à 4.

      >>PS : dire que Perl est un langage qui est proche de la porte de sortie, c'est ignorer tout l'existant. <<

      Non, si la raison principale pour choisir Perl est le code existant pas les qualités du langage, c'est bien qu'il est "proche de la sortie" (personne n'a dit que la sortie se ferait vite..).

      Après certains aiment Perl pour lui-même (je n'en fais pas partie)..
      • [^] # Re: dubitatif...

        Posté par  (site web personnel) . Évalué à 0.

        Selon http://royal.pingdom.com/?p=173 Perl est utilisé sur 4 des 9 plus gros sites mondiaux, Python sur un seul, Ruby sur aucun. Je pourrais aussi pointer vers les nombreuses entrées de blogs expliquant que "RoR won't go mainstream" ou l'histoire de ce type qui après avoir embauché l'un des core devs de RoR pour convertir son site de PHP à RoR est finalement revenu à PHP, mais en quoi est-ce que cela fera avancer le schmiblick ?

        Python et Ruby ont leurs avantages par rapport à Perl, mais ils ne sont pas parfaits (pensez aux performances), et dans certains cas ne sont pas les outils les plus pertinents. C'est pareil pour Perl, mais l'un des ses gros avantages est encore une fois de disposer du CPAN et de ses très nombreux modules qui couvrent quasiment tous les champs possibles et imaginables.

        Mais l'important c'est de garder un esprit ouvert et de savoir apprendre des autres langages. Après tout, Python et Ruby ont emprunté des trucs à Perl, et c'était une bonne chose, et Perl emprunte des trucs à Python et Ruby, et c'est aussi une bonne chose. Perso, je me suis d'ailleurs acheté le HS de GLMF sur Ruby.
        • [^] # Re: dubitatif...

          Posté par  (site web personnel) . Évalué à 4.

          Ho, chouette un troll Perl / Python / Ruby !

          Ruby n'apparait pas dans le classement, mais je pense que twitter (ruby on rails) fait plus de traffic que plenty of fish. Et les 9 sites les plus gros, je doute que ce soit un échantillon représentatif de quoi que ce soit.

          Pour les blogs, tu sais, ce n'est pas forcément parce que beaucoup de monde le dit que c'est vrai. Quand plein de blogs disent que l'Ipod est le meilleur lecteur mp3, faut pas forcément les croire ;)

          Par contre, je suis d'accord avec toi quand tu dis qu'il faut savoir apprendre de nouveaux langages. Pour moi, le prochain sur la liste, c'est erlang.
        • [^] # Re: dubitatif...

          Posté par  . Évalué à 2.

          (pensez aux performances)

          Ah ben oui pensons-y justement.
          Perl vs. Python :
          http://shootout.alioth.debian.org/gp4sandbox/python.php
          • [^] # Re: dubitatif...

            Posté par  (site web personnel) . Évalué à 1.

            C'est pas faux, sauf que les programmes de benchmark pour Perl ne sont pas forcement optimaux, l'un est manquant et l'autre erroné. Cela montre surtout que personne dans la communauté Perl n'a véritablement passé du temps pour l'écriture et l'optimisation des programmes. Ce site avait été mentionné sur Perl5 Porters, et l'avis général était qu'il faudrait récrire ou compléter ces programmes, mais qu'on manquait de tuits.
            • [^] # Re: dubitatif...

              Posté par  . Évalué à 4.

              Ce site avait été mentionné sur Perl5 Porters, et l'avis général était qu'il faudrait récrire ou compléter ces programmes, mais qu'on manquait de tuits.

              Moi qui pensais qu'un des avantages de Perl était sa communauté nombreuse et active :-)
  • # Perl vs Ruby

    Posté par  . Évalué à 2.

    Quels sont les avantages de Perl par rapport à Ruby ?

    N'ayant pas trop touché Perl, j'aimerais savoir si ce langage possède vraiment des atouts par rapport à Ruby (qui reprend apparement certaines chose de Perl) notamment pour faire des scripts.

    Il s'est bonnifié avec l'âge, ou s'est plutôt gâté ?
    • [^] # Re: Perl vs Ruby

      Posté par  (site web personnel) . Évalué à 4.

      Pour les avantages de Perl, par rapport a Ruby ou un autre :
      - des centaines de milliers de modules existants qui font des tas de trucs facon grosse bidouille
      - vraiment bien oriente je crache un script en une minute pour faire des manipulations texte un peu chiadees. C'est le champion de la moulinette.

      Pour les inconvenients :
      - du code write-only == illisible deux jours plus tard, meme par celui qui l'a ecrit

      En fait c'est dur de developper mais globalement, perl est un langage qui permet de sortir facilement des moulinettes textes, mais qui a l'inconvenient de ne pas du tout encourager des pratiques de programmation moderne tournees vers la qualite logicielle (re-utilisabilite, maintabilite, lisibilte, ...). Des que tu depasses le stade de la moulinette, le langage te fait perdre du temps par son manque de lisibilite.
      • [^] # Re: Perl vs Ruby

        Posté par  (site web personnel) . Évalué à 1.

        mouai...
        Perso, j'ai toujours écrit du perl lisible. Et pour voir j'ai repris un code (une sorte de compilateur assembleur que j'avais fait en perl) d'il y a 4 ans en gros ... ben je le comprend toujours.

        Alors oui, perl n'oblige pas du tout à écrire correctement, à faire du code maintenable, etc. Mais si le programmeur se donne la peine de coder proprement, en ayant ses propres lignes de conduite alors il n'y a aucune raison que perl soit moins lisible que du ruby, perl, c, <placer ici n'importe quel langage>

        Et j'ajouterais que si perl était si illisible, alors il n'existerait pas cpan ou tous les modules qui font son intérêt.

        Par contre oui, il est génial pour écrire en qq minutes un parser, un robot pour surfer, ...

        Des que tu depasses le stade de la moulinette, le langage te fait perdre du temps par son manque de lisibilite.

        Honnêtement c'est faux. Le truc c'est que perl est un langage plus "complet" que beaucoup d'autres. Ce n'est pas le bon terme mais ce que je veux dire c'est qu'il existe beaucoup de variables très courtes (souvent en $, $$, $!, ...) ainsi que des variables implicites.
        En clair, les personnes trouvant que perl est illisible le trouve souvent car ils ne comprènent pas comment marche perl. En gros parce qu'elles n'ont pas appris perl et veulent souvent programmer en perl comme elles programmes en C...
        Et au contraire, les variables implicites peuvent par exemple faire gagner pas mal de temps, sans perdre la lisibilité du programme :

        open(FILE, ">file.plop") or die $!
        while(<FILE>) {
        print if /blrup/;
        }



        maintenant, pour en revenir à la question initiale, après avoir programmé en perl (pour les scripts) j'utilise de plus en plus ruby. C'est un langage que je trouve beau (qualité très importante pour moi), bien foutu et très cohérent. En plus il est réellement totalement objet et amène une autre manière de penser qu'en C et tous les langages y ressemblant.
        Par exemple :

        10.times {
        // actions
        }

        qui est beaucoup plus logique que :

        for(var i = 0; i < 10; i++) {
        // actions n'utilisant pas i...
        }


        Ruby est aussi intéressant si regarde le fonctionnement des accesseurs aux membres par exemple.

        Donc pour moi, ruby est en train de prendre la place de perl (et ce n'est pas python qui le remplacera, ne serait-ce que par le nombre de '_' se trouvant dans le moindre fichier python et me donnant envie de gerber tellement c'est moche...)
        • [^] # Re: Perl vs Ruby

          Posté par  (site web personnel) . Évalué à 3.

          maintenant, pour en revenir à la question initiale, après avoir programmé en perl (pour les scripts) j'utilise de plus en plus ruby

          J'ai toujours pensé que ruby était ce que certains auraient aimé pour être perl6
          • [^] # Re: Perl vs Ruby

            Posté par  (site web personnel) . Évalué à 1.

            Larry Wall avait dit il y a quelques années que s'il avait dû refaire Perl 5, il aurait alors ressemblé à Ruby. C'est d'ailleurs pour ça que Perl 6 emprunte des fonctionnalités de Ruby, mais aussi aux langages fonctionnels comme OCaml et Haskell.
      • [^] # Re: Perl vs Ruby

        Posté par  (site web personnel) . Évalué à 1.

        code write-only

        Ce troll est tellement usé qu'il a perdu tous ses poils le pauvre pitchoun.

        Bien sûr qu'on peut écrire salement, mais on peut aussi écrire salement en C, en Java, en PHP, et même en Python et en Ruby. Le langage peut plus ou moins aider, mais c'est une question principalement liée au développeur.

        En Perl, on dispose maintenant d'outils comme Perl::Critic pour automatiser l'application de règles d'écritures telles que conseillées par Perl Best Practices (http://www.oreilly.fr/catalogue/2841773698)
        • [^] # Re: Perl vs Ruby

          Posté par  . Évalué à 3.

          c'est pas parce qu'il existe de tels outils ou de bonnes façons d'écrire proprement que le mec qui est passé devant toi l'aura fait
      • [^] # Re: Perl vs Ruby

        Posté par  (site web personnel) . Évalué à 2.

        Pour le nombre de modules, la différence avec ruby n'est plus un argument. Perl a plus de modules que Ruby, mais ca reste du même ordre de grandeur.

        Hop, une référence pour faire sérieux : http://www.oreillynet.com/ruby/blog/2007/09/rubyforge_vs_cpa(...)
        • [^] # Re: Perl vs Ruby

          Posté par  (site web personnel) . Évalué à 1.

          Ah ça c'est intéressant, je ne savais pas que RubyForge se portait aussi bien mais c'est une bonne chose à savoir. Par contre l'auteur du blog reste quand même biaisé car si je suis d'accord qu'il y a des doublons et des saletés sur le CPAN, je pense que, les développeurs étant les mêmes quel que soit le langage, il doit y en avoir aussi sur RubyForge.

          (tentatives de recherches sur RubyForge)

          Beuh, le moteur de recherche est tout pourri : il n'est même pas capable de faire une recherche sur deux mots. Ca n'utiliserait pas encore le vieux truc de GForge ? Il faudrait le remplacer par Namazu, ça fonctionnerait mieux.
      • [^] # Re: Perl vs Ruby

        Posté par  . Évalué à 4.

        du code write-only == illisible deux jours plus tard

        Attention : "==" ou bien "eq" ?
    • [^] # Re: Perl vs Ruby

      Posté par  . Évalué à 2.

      Perl a nettement un avantage côté perfs, pour le reste je vois pas.
      • [^] # Re: Perl vs Ruby

        Posté par  (Mastodon) . Évalué à 2.

        l'avantage c'est qu'il est fourni avec pratiquements tous les unixes, dans la distribution "officielle" j'entends...

        Mine de rien quand il s'agit de machines de prods, on évite d'installer x langages, donc si perl y est déja installé, l'installation d'un ruby, python ou autre ne sera que très rarement justifiée/authorisée.

        perl c'est un peu le MSN Messenger des unix, un monopole de fait. C'est drôle parce que ce n'est même pas le cas pour les shells.

        Donc ça reste très utile de le connaitre et de le maitriser.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.