Sébastien Aperghis-Tramoni a écrit 27 commentaires

  • # Autres : Perl

    Posté par  (site web personnel) . En réponse au sondage Quel langage utilisez-vous sur vos serveurs pour vos applications web ?. Évalué à 6.

    Catalyst pour les applis avec interface, CGI::Fast pour des trucs basiques.

  • [^] # Re: Code

    Posté par  (site web personnel) . En réponse au journal Le retour du BBS. Évalué à 0.

    Pour donner un petit historique, ce code avait été principalement écrit par Vdb en 1997, alors qu'il était à Uppsala. Comme il le disait lui-même l'année suivante, quand il est revenu en France et qu'on a commencé a reprendre son code (qu'il avait parfois du mal à comprendre), le problème est qu'il l'avait écrit alors qu'il rentrait "bourré à la vodka, à 4h du matin".

    Ajoutez à cela ses habitudes de l'époque d'utiliser des noms de variables comme pipo, hin, ki, koi et autres noms très expressifs, et vous avez le code que la nouvelle équipe a dû se frapper depuis plusieurs mois..

    Donc, respect, parce que ce n'est vraiment pas le code qui donne le plus envie.

  • # connexion depuis un BSD / OSX

    Posté par  (site web personnel) . En réponse au journal Le retour du BBS. Évalué à 0.

    Pour ceux qui se connectent depuis un système BSD (y compris OSX), il faut penser à passer l'option -8 à telnet si on se sert de ce protocole, sinon les caractères sont tronqués à 7 bits.
    Ou sinon, utiliser ssh, qui par défaut transmet en binaire.

  • [^] # Re: Pas trop de clichés SVP

    Posté par  (site web personnel) . En réponse à la dépêche Les journées Perl 2011. Évalué à 0.

    Perl 6 ?
    Pardon je vais me cacher...

    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  (site web personnel) . En réponse à la dépêche Les journées Perl 2011. Évalué à 2.

    L'avertissement était déjà affiché dans Python 2.5, alors y'avait quand
    même le temps de préparer la migration.

    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  (site web personnel) . En réponse à la dépêche Les journées Perl 2011. Évalué à 2.

    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).

    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, method ou 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: Et Perl6 alors ?

    Posté par  (site web personnel) . En réponse à la dépêche Perl 5.12 - une constante jeunesse. Évalué à 4.

    Il faut réaliser que Perl 6 n'est pas juste la version suivante du langage, mais que c'est véritablement un nouveau langage. Même quand Perl 6 v1.0.0 sera disponible, Perl 5 continuera d'être développé et maintenu, parce qu'il existe bien trop de code Perl 5 en production pour laisser tomber cet interpréteur.

    Comme cela a été dit ailleurs, on peut voir Perl 5 et Perl 6 comme des langages appartenant à une même famille « Perl », un peu de la même manière que C, C++ et Objective-C appartiennent à la même famille « C ».
  • [^] # Re: Perl vs Ruby

    Posté par  (site web personnel) . En réponse à la dépêche Les Journées Perl, plus que 10 jours pour s'inscrire !. É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: dubitatif...

    Posté par  (site web personnel) . En réponse à la dépêche Les Journées Perl, plus que 10 jours pour s'inscrire !. É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: Perl vs Ruby

    Posté par  (site web personnel) . En réponse à la dépêche Les Journées Perl, plus que 10 jours pour s'inscrire !. É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  (site web personnel) . En réponse à la dépêche Les Journées Perl, plus que 10 jours pour s'inscrire !. É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: dubitatif...

    Posté par  (site web personnel) . En réponse à la dépêche Les Journées Perl, plus que 10 jours pour s'inscrire !. É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: gérontophilie

    Posté par  (site web personnel) . En réponse à la dépêche Les Journées Perl, plus que 10 jours pour s'inscrire !. É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.
  • [^] # Re: gérontophilie

    Posté par  (site web personnel) . En réponse à la dépêche Les Journées Perl, plus que 10 jours pour s'inscrire !. É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: Oignon

    Posté par  (site web personnel) . En réponse à la dépêche Les Journées Perl 2007, 16-17 novembre à Lyon. Évalué à 1.


    Ah ca c'est sûr tous les débutants qui ont digéré "Programming Perl", ses références mystiques, son exposé exhaustif des exceptions à la règle à vous dégoutter, peuvent en attester.

    C'est pas faux (tm).
    Même si personnellement, ça ne m'avait pas gêné.
    Mais d'un autre côté, les vrais débutants doivent plutôt commencer par Learning Perl[1] de Randal Schwartz, Programming Perl étant surtout le livre de référence (plus ou moins) exhaustif du langage. Le cours de Sylvain est aussi en effet un bon point de départ. Pour les articles, je pense ne surprendre personne si je dis que le prochain sera aussi sur Parrot :-)

    [1] http://www.oreilly.com/catalog/learnperl4/
  • [^] # Re: Oignon

    Posté par  (site web personnel) . En réponse à la dépêche Les Journées Perl 2007, 16-17 novembre à Lyon. Évalué à 4.

    Juste pour l'histoire (et pour ceux qui se poseraient la question), l'oignon est devenu le logo officiel de Perl pour deux raisons.

    La première est que le camel (le dromadaire) illustrant la couverture[1] des livres O'Reilly et devenu le symbole de Perl est la propriété des éditions O'Reilly. Et O'Reilly n'a autorisé que l'utilisation non comerciale[2] de cette image (ce qui peut se comprendre). La communauté Perl, et surtout la Perl Foundation[3] avaient donc besoin d'un logo pour en faire des produits dérivés (par exemple sur des t-shirts[4] et des mugs[5]).

    La seconde raison, et celle qui a fait choisir l'oignon comme logo, c'est que Larry Wall a utilisé l'image de l'oignon depuis longtemps pour décrire la communauté Perl : les couches les plus externes correspondent aux débutants, nombreux ; ceux-ci vont apprendre au contact des programmeurs aguerris de la couche en-dessous, qui sont un peu moins nombreux ; eux-mêmes vont discuter avec les auteurs de modules CPAN[6] de la couche encore en-dessous ; ces auteurs dialoguent avec les programmeurs les plus exéprimentés de la couche suivante, qui eux-mêmes maintiennent des échanges les Perl 5 porters (ceux qui maintiennent le code de l'interpréteur Perl et des modules standards) ; et au coeur on trouve Larry Wall, qui prend(*) les décisions concernant le langage. Cette image reflète aussi la modestie naturelle de Larry Wall, qui n'aime pas se mettre en avant : ici, il considère justement que les personnes les plus à même pour expliquer le langage aux débutants (et donc qui sont le plus visibles) ne sont pas forcément celles qui en connaissent ses entrailles.

    (*) "qui prenait" serait plus exact puisqu'il ne s'occupe plus de Perl 5 depuis un moment, étant donné qu'il travaille sur Perl 6.

    [1] http://www.oreilly.com/catalog/pperl3/
    [2] http://www.oreillynet.com/pub/a/oreilly/perl/usage/faq.html
    [3] http://www.perlfoundation.org/
    [4] http://www.cafepress.com/perlfoundation.12283060
    [5] http://www.cafepress.com/perlfoundation.12403719
    [6] http://www.cpan.org/
  • # Quelques précisions

    Posté par  (site web personnel) . En réponse à la dépêche YAPC::Europe à Braga, c'est parti. Évalué à 1.

    Malheureusement, il n'y aura pas de feed vidéo ou audio cette année

    En fait, je crois que les organisateurs avaient mis en place des streamings, mais n'en ont pas fait la publicité. En tout cas, l'ensemble de la conférence a été enregistrée.

    On pourra également se rendre sur le canal IRC #yapc sur irc.perl.org où on trouvera à n'en pas douter de nombreux participants (voire conférenciers ?).

    Ceux qui sont venus sur ce chan ont pu lire les commentaires enthousiastes ou acides des personnes qui assistaient aux présentations.

    La vente de charité, particulièrement amusante cette année, y fut aussi commentée.

    Pour ceux qui n'ont pu venir ni assister à distance un compte-rendu sera prochainement publié dans Linux Magazine.
  • [^] # Re: Le truc qui m'"emmerde" un peu depusi quelques temps

    Posté par  (site web personnel) . En réponse au journal Linuxmag. Évalué à 1.

    Le problème des comptes-rendus, c'est qu'il y a beaucoup de présentations dont on voudrait parler, mais pas assez de place. Ainsi la différence est très nette entre mon compte-rendu sur les Journées Perl 2004[1] et celui sur YAPC::Europe 2004[2]. Le premier n'expose que très brièvement le sujet de chaque présentation et parle de l'ambiance gloable, alors que le second décrit un peu plus en détails chaque présentation. La conséquence directe est que le second est trois fois plus gros que le premier.

    Mais dans tous les cas, j'essaye d'inclure le maximum de liens vers les slides des présentations... quand ils sont disponibles !

    [1] http://articles.mongueurs.net/comptes-rendus/fpw-2004.html(...)
    [2] http://articles.mongueurs.net/comptes-rendus/yapc-eu-2004.html(...)
  • [^] # Re: Hors-Sujet

    Posté par  (site web personnel) . En réponse à la dépêche Samedi du Libre Perl (Paris). Évalué à 3.

    Pour plus de détails sur la cuisante défaite des Anglais durant la vente aux enchères de YAPC::Europe 2003 : http://maddingue.free.fr/articles/yapc/2003/#auction%20%28vente%20a(...)
  • [^] # Re: Attention

    Posté par  (site web personnel) . En réponse à la dépêche Brevets Logiciels, action à Paris. Évalué à 0.

    C'est très bien de me faire une leçon d'anglais, mais j'aimerais bien qu'en attendant quelques Parisiens se manifestent auprès de Benjamin Henrion afin de lui montrer qu'on est aussi capable de se bouger.

    Et non, je ne peux pas réceptionner moi-même la banderolle ni venir la tenir devant l'Assemblée pour la simple raison que je suis à Marseille. Alors s'il vous plaît, bougez !
  • # Dictionnaire japonais->français

    Posté par  (site web personnel) . En réponse à la dépêche Dictionnaires libres ?. Évalué à 3.

    Personnellement, j'essaie de faire un dictionnaire japonais->français depuis quelques années. Il est dispo en ligne à http://maddingue.org/dico-jap/.(...) C'est assez pauvre en terme de quantité, mais sinon, le format (.src et XML) et les outils de travail peuvent être réutilisés.

    Pour le moment, je n'ai pas spécifié de licence (c'est Copyright moi-même), mais il faudrait que je package le tout ou tout au moins que je me décide pour une licence libre (FDL? GPL?)
  • [^] # Re: Linus et le micro-kernel

    Posté par  (site web personnel) . En réponse à la dépêche DaNews: Informations du week-end .... Évalué à 1.

    En fait, j'ai lu ailleurs (mais je ne sais plus où..) que Linus avait en réalité critiqué Mac OS Classic, ce qui change légèrement le contexte : Mac OS Classic est en effet très mauvais en termes techniques. Cela n'excuse pas vraiment une critique d'une telle virulence, étant donné que ce système est voué à disparaître.

    Toutefois, si c'était bien Mac OS X qu'il critiquait, ce ne serait pas vraiment surprenant non plus. Il est célèbre pour avoir donné son opinion sur Mach (il y a déjà longtemps de cela) : "Message passing as the fundamental operation of the OS is just an exercise in computer science masturbation. It may feel good, but you don't actually get anything DONE."

    En clair, Linus, il n'aime pas Mach :)
  • # Autres émulateurs/browsers

    Posté par  (site web personnel) . En réponse à la dépêche Emulateur Wap pour Linux. Évalué à 1.

    DeckIt est sympathique, mais un peu lourd, et il a un défault : seules une version Windows et une version Linux Intel sont disponibles. Ceux qui ont une autre architecture (comme moi) l'ont dans l'os.

    Il existe d'autres browsers WML dispos en GPL, comme wApua, écrit en Perl/Tk, et Tofoa, écrit en Python. Il y a aussi WML browser, mais la seule chose qu'il accepte de m'afficher, c'est "core dump"...

    J'en profite, si ça peut intéresser certains, pour indiquer que j'ai écrit un convertisseur de HTML vers WML qui marche assez bien : http://freshmeat.net/projects/html2wml/(...)

    [ wApua -- http://fsinfo.cs.uni-sb.de/~abe/wApua/(...) ]
    [ Tofoa -- http://tofoa.free-system.com/(...) ]
    [ WML Browser -- http://www.wmlbrowser.org/(...) ]
  • # comparatif puissances

    Posté par  (site web personnel) . En réponse à la dépêche Seti@Home sur Science & Vie. Évalué à 1.

    disons que plus que le comparatif plateforme/OS, on peut surtout voir la différence entre les différents types de processeurs. C'est très clair quand on comprend que SETI@home ne fait que du calcul flottant : les Celerons et K6 sont très lents comparés aux Pentiums.

    Plus rigolo, j'avais constaté l'an dernier que le calcul d'un paquet prenait à peu près autant de temps sur un bi-P2 350 sous Debian que sur un G3 266 sous MacOS (environ 14h dans les deux cas).

    Sinon, des copains avait testé (sur la même machine) les temps de calcul sous Win et sous Linux et c'est vrai que ça allait un peu plus vite sous Linux que sous Win
  • # le brevet à la con

    Posté par  (site web personnel) . En réponse à la dépêche les hyperliens de British Telecom. Évalué à 1.

    mais j'avais vu passer une news sur /. comme quoi ils s'étaient boulé et une cour de justice avait dit que leur brevet ne s'appliquait pas; j'avais rêvé ou quoi ?