No more perl

• [^]Re: No more perl

  Posté par pomperoi (page perso, ) le 11/05/2007 à 08:25. (lien). Évalué à 4.

  Voilà un lien où l'auteur du blog en question s'exprime et nuance son opinion : http://use.perl.org/~chromatic/journal/33191

  [^]Re: No more perl

  Posté par Gonéri Le Bouder (Jabber id, page perso, ) le 11/05/2007 à 09:17. (lien). Évalué à 5.

  Je suis un peu perplexe quand je vois qu'ils critiquent les performances de mod_perl et qu'ils veulent utiliser Python ou Ruby à la place. Si il est bien utilisé mod_perl offre des performances du même niveau que mod_php tout en offrant beaucoup plus de libertés. On peut par exemple ajouter du code a différents endroits directement dans Apache grâce aux Handlers.
  http://perl.apache.org/docs/2.0/user/handlers/intro.html
  
  

  
  - pas de design par contract
  

  
  C'est quoi exactement ?
  
  Pour les exceptions, c'est prévu dans Perl6.
  
  Enfin, par rapport aux critiques récurantes par rapport à la lisibilité du code, je pense que c'est un faux argument. C'est, a mon avis, d'avantage un problème de norme de codage au sein du projet.

  --
  apt-get moo

  • [^]Re: No more perl

    Posté par reno () le 11/05/2007 à 12:11. (lien). Évalué à 1.

    >> - pas de design par contract
    > C'est quoi exactement ?
    
    http://fr.wikipedia.org/wiki/Programmation_par_contrat
    
    Sinon, personnellement je pense le contraire pour la lisibilité: je trouve Perl très mauvais de ce point de vue (et Perl6 a part être plus baroque ne changera pas grand chose de ce point de vue).
    Ruby ou Python sont bien meilleur sur ce point la..

    • [^]Re: No more perl

      Posté par pomperoi (page perso, ) le 11/05/2007 à 12:26. (lien). Évalué à 2.

      Je ne suis pas d'accord. Perl a été conçu pour être lisible, avec en tête beaucoup de concepts qui viennent des langages naturels. Du code perl propre, respectant des standards de codage, est souvent très clair. Ruby et Python ont eux aussi plus que leur part de constructions obscures et d'idiosyncrasies bizarroïdes.
      
      D'autre part, Perl 6 sera au contraire beaucoup moins baroque que Perl 5. Tout ce qui rend Perl 5 difficile à manier -- à savoir le nombre important d'exceptions et de cas particuliers dans les syntaxes -- a été éliminé au profit de règles plus simples, et générales, donnant ainsi plus d'homogénéité au langage.

      • [^]Re: No more perl

        Posté par Bozo le Clown () le 11/05/2007 à 16:32. (lien). Évalué à 9.

        Perl a été conçu pour être lisible, avec en tête beaucoup de concepts qui viennent des langages naturels. http://open-site.org/Computers/Programming/Contests/Obfuscat(...)

        #!/usr/bin/perl
        
        $;="@{'`|;{'^'!.|-'}";$.++;$.++;$.++;$_="(.)?";/((?{$_.=$_}).)+$/;@_='~!@#$%^&*(
        )_+`-=[]\\{}|;\':",./<>? '=~/$_/;@_ _=$;=~/$_/;$_="(.)*?";/((?{$_.=$_}).)+$/;$Z-=
        $Z;"$.$."-$Z;/((?{$_ _[$z]&&!("${_[$x]}"^"${_[$y]}"^"${_ _[$z]}"^"$Z")&&($a.=$_[$x
        ],$b.=$_[$y],$z++);$x++;$y+=!($x%="$.$.");$y%="$.$.";}).)+/;$_="^"^"^";$_ _=".>.\
        '$_ _ _$b')".".('!\@/\"'^'}.')".']}`'; 
        

        De quel nationalité es tu ? :)

        • [^]Re: No more perl

          Posté par CrEv (page perso, ) le 12/05/2007 à 19:38. (lien). Évalué à 4.

          prendre un exemple du "Obfuscated perl contest" c'est quand même un peu de la mauvaise fois... ;-)
          
          A quand un Obfuscated C contest ? y'a quand même moyen de faire des choses bien bien crade aussi, surtout avec les pointeurs... ;-)

          • [^]Re: No more perl

            Posté par Moonz () le 13/05/2007 à 12:28. (lien). Évalué à 4.

            http://www.ioccc.org/

      [^]Re: No more perl

      Posté par Gonéri Le Bouder (Jabber id, page perso, ) le 11/05/2007 à 12:32. (lien). Évalué à 1.

      Oui naturellement, ces languages imposent d'avantage de rigueur et de normalisation dans la façon de coder.

      --
      apt-get moo

      • [^]Re: No more perl

        Posté par pomperoi (page perso, ) le 11/05/2007 à 12:57. (lien). Évalué à 5.

        C'est faux. La normalisation n'est pas imposée par un langage, mais par ensemble de règles (appelée "standard de codage" en général) adoptées par l'ensemble des développeurs sur un meme projet. Ces règles existent en perl; la version courte est dans la page de manuel perlstyle; pour la version longue, je renvoie à l'excellent bouquin de Damian Conway, Perl Best Practices.
        
        Quant à la rigueur, c'est bien plus du côté du cerveau du développeur que ça se passe. Aucun langage n'a jamais empêché des programmeurs inexpérimentés de commettre des plats de spaghetti que je sache. Il est vrai que les langages fortement typés à la Ada ou C++ ont des compilateurs qui imposent bien plus de contraintes. D'autre part, les langages à inférence de type à la Haskell permettent au programmeur de se reposer sur l'intelligence du compilateur. Cependant, Perl, Ruby et Python sont exactement similaires sur ce point, car ils partagent les mêmes caractéristiques: typage dynamique, et possibilité de modifier le programme à l'execution, notamment. Le reste est une pure question de goût.

        • [^]Re: No more perl

          Posté par Sytoka Modon (page perso, ) le 11/05/2007 à 13:23. (lien). Évalué à 5.

          Je suis assez d'accord. Je ne comprends rien au python et je ne le trouve pas propre du tout avec ces __MACHIN__
          
          Un truc super en perl c'est qu'une variable scalaire commence par un $. Cela, c'est vachement bien de séparer les variables des mots clefs.
          
          Comme il a été dis, en perl6, ils ont éliminé pas mal de truc pas propre mais il est possible déjà de faire propre en perl5. Il suffit d'utiliser les bons modules.
          
          Enfin, un gros avantages du perl, les programmes que j'ai fait il y a 10 ans en perl5_004 marche toujours tel quel !
          
          Bref, il est de bon ton de critiquer perl de nos jours, surtout sur dlfp, notamment pour pousser vers python. Quand je vois dans une debian le nombre de version de python et les incompatibilités entre elles, personnellement, je n'ai pas envie d'en faire.

          [^]Re: No more perl

          Posté par Matthieu Moy (page perso, ) le 11/05/2007 à 13:35. (lien). Évalué à 1.

          >>> Ruby ou Python sont bien meilleur sur ce point la..
          >> ces languages imposent d'avantage de rigueur et de normalisation dans la façon de coder.
          > C'est faux. La normalisation n'est pas imposée par un langage, mais par ensemble de règles
          
          Je ne sais pas pour ruby, mais essayes de faire du code mal indenté en Python, et reviens discuter après si tu penses toujours que la normalisation n'est pas imposée par le language dans ce cas ...

          • [^]Re: No more perl

            Posté par pomperoi (page perso, ) le 11/05/2007 à 13:49. (lien). Évalué à 1.

            Si pour toi, la normalisation c'est l'indentation, tu as encore beaucoup à apprendre, jeune padawan... Identifiants obscurs, classes fourre-tout avec 60 méthodes, variables globales non documentées, codes à effets de bord obscurs, tout cela nécéssite d'être prévenu par des règles, qui ne peuvent pas être intégrées à la syntaxe d'un langage sans le rendre inutilisable.

            • [^]Re: No more perl

              Posté par Matthieu Moy (page perso, ) le 11/05/2007 à 14:15. (lien). Évalué à 1.

              Le langage python impose des règles de codage :
              [ ] vrai
              [ ] faux
              ?

              • [^]Re: No more perl

                Posté par Moonz () le 11/05/2007 à 14:27. (lien). Évalué à 3.

                Ça dépend de ce que tu entends pas "impose" et "règle de codage".
                Par exemple, si tu prends l'indentation comme étant une règle de codage et impose "il faut le faire" (parce qu'on pourrait aussi imposer de ne pas le faire, imposer une tabulation, imposer deux espaces,... ce que python n'impose pas), oui
                Maintenant, je te donne une nouvelle règle: "il faut délimiter le code d'une fonction par des accolades" ou "toute instruction se termine d'un point virgule". Alors:
                Le langage C impose des règles de codage:
                [ ] vrai
                [ ] faux

  [^]Re: No more perl

  Posté par Guillaume Rousse (page perso, ) le 11/05/2007 à 16:51. (lien). Évalué à 1.

  Pas _les_ auteurs, mais un seul. Et qui jette un peu vite la pierre sur le language plutot qu'explorer les solutions proposées par la communauté Perl. Ce qui est assez symptomatique de la façon dont le soft est developpé.

  [^]Re: No more perl

  Posté par Sebastien Tanguy (page perso, ) le 11/05/2007 à 16:52. (lien). Évalué à 3.

  > - du code en perl est plus difficile à revoir et à maintenir, du fait qu'il y a "plusieurs façon de faire la même chose",
  
  C'est ce qui se dit, mais au final, on peut faire du code crade quelque soit le langage (et c'est d'autant plus ironique si quelqu'un souhaite vendre du PHP sur cet argument).
  
  > - pas de design par contract
  
  Quelle vaste blague! Rares sont les langages implémentant réellement du DbC. Non, du typage fort n'est pas suffisant pour se dire DbC. Non, avoir une macro "assert" n'est pas suffisant pour se dire DbC.
  
  > - pas de vrai système d'exceptions
  
  Les exceptions sont un modèle de gestion des erreurs. Se baser là-dessus pour juger un langage ou environnement est naïf. Java sait gérer les exceptions, mais ça n'empêche pas celles-ci d'arriver à l'utilisateur ou d'en dégoûter plus d'un avec une stacktrace énorme.
  
  > - gourmandise de mod_perl en terme de ressource
  
  Le principal problème est que mod_perl n'est pas mutualisable. Pour le reste, il apporte des avantages dont il faut profiter et des contraintes dont il faut tenir compte.
  
  > - erreurs du compilateur perl souvent peu explicites
  
  C'est le cas de bien des langages. Jusqu'à présent, le seul qui me fasse dire le contraire, pour le peu que je l'ai pratiqué, c'est Ada.