XML-RPC !

Rien à voir, quoique

• [^]Re: Rien à voir, quoique

  Posté par j (page perso, ) le 10/05/2007 à 21:37. (lien). Évalué à 1.

  en 2000 https://linuxfr.org/2000/11/02/794.html

  • [^]Re: Rien à voir, quoique

    Posté par Sytoka Modon (page perso, ) le 10/05/2007 à 21:44. (lien). Évalué à 1.

    Cela doit être la phrase fétiche
    
    http://linuxfr.org/~Nyco/comments,139.html

    • [^]Re: Rien à voir, quoique

      Posté par j (page perso, ) le 10/05/2007 à 22:18. (lien). Évalué à 0.

      c'est le même commentaire, il y a un problème de datation
      d'ailleurs en 1999 DLFP était motorisé par DaCode

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.

Interêt de GPL + LGPL?

• [^]Re: Interêt de GPL + LGPL?

  Posté par CrEv (page perso, ) le 14/05/2007 à 15:19. (lien). Évalué à 3.

  c'est, je pense, surtout que si quelqu'un fait un dérivé de bugzilla, modifie quelques lignes ou autre, tout en choisissant la GPL, alors on ne peut plus passer cette version en LGPL.

• [^]Re: Interêt de GPL + LGPL?

  Posté par imalip (page perso, ) le 14/05/2007 à 22:01. (lien). Évalué à 2.

  surtout que la LGPL permet explicitement la redistribution sous GPL :
  

  3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices.

  
  Donc effectivement, ca fait doublon, vu que la LGPL est d'office une double licence GPL/LGPL.

  --
  "While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal