perl est difficile a maintenir si l'on approche perl comme n'importe quel autre langage.
Pas d'accord. Perl est difficile à maintenir parce qu'il y a tellement de façons de faire quelque chose, que si toi tu lis du code que moi j'aurais écris avec mes habitudes et préférences, à tous les coups tu vas le trouver illisible. Et inversement bien sûr. Et si tu dois améliorer/changer mon code, tes changements seront illisibles pour moi.
La multiplicité des styles de programmation en Perl est sûrement un avantage pour l'écriture car les gens "trouvent" un style proche de leur approche et leur façon de faire, par contre c'est un inconvénient pour la maintenabilité du code dans une grande équipe (moi je bannis "unless" que je trouve illisible, ce genre de détail à la con).
Je ne vois pas d'ailleurs en quoi le fait qu'il ne faille pas l'aborder comme les autres langages solutionne quoi que ce soit au niveau de la maintenabilité du code.
pour donner un exemple, ecrire la doc d'une feuille d'impots est un exercice à plusieurs mains, il faut que cela soit le plus homogene possible sinon c'est inmaintenable.
Je ne vois pas du tout où tu veux en venir dans ce post. Je pense que tu n'illustres pas assez. Bon ton exemple avec l'enfant et le ballon est drôle. Ceci dit, Larry Wall est un linguiste à ma connaissance, donc je pense que tu creuses un point intéressant de son approche à son langage.
un extrait de code pour le SMTP genericisé ( commentaire d'origine ;) ) :
Si j'ai bien compris, tu construis un objet HA::Net::SMTP puis tu le précises dans les méthodes helo et ehlo. C'est effectivement un side-effect élégant de la syntaxe de création des objets en Perl, j'acquièsce vigoureusement. Maintenant, est-ce que l'intérêt est suffisant pour contrebalancer la ligne « bless » supplémentaire nécessaire pour tous les objets qui n'auront jamais besoin de cette fonctionalité ? Je n'en suis pas vraiment sûr. En plus, Perl pourrait suivre la convention de faire un bless implicite sur la valeur de retour de la fonction "new" avec le nom de package adéquat, si cette valeur n'est pas déjà un objet (ça a peut-être été écarté pour raisons de compatibilités avec les anciens programmes perl non objet utilisant la fonction new ? bon un tel problème n'a pas empêché d'ajouter l'appel implicite de DESTROY).
[^] # Re: Heu, perl ?
Posté par gc . En réponse au message Qui m'aime me suive !!. Évalué à 1.
Pas d'accord. Perl est difficile à maintenir parce qu'il y a tellement de façons de faire quelque chose, que si toi tu lis du code que moi j'aurais écris avec mes habitudes et préférences, à tous les coups tu vas le trouver illisible. Et inversement bien sûr. Et si tu dois améliorer/changer mon code, tes changements seront illisibles pour moi.
La multiplicité des styles de programmation en Perl est sûrement un avantage pour l'écriture car les gens "trouvent" un style proche de leur approche et leur façon de faire, par contre c'est un inconvénient pour la maintenabilité du code dans une grande équipe (moi je bannis "unless" que je trouve illisible, ce genre de détail à la con).
Je ne vois pas d'ailleurs en quoi le fait qu'il ne faille pas l'aborder comme les autres langages solutionne quoi que ce soit au niveau de la maintenabilité du code.
pour donner un exemple, ecrire la doc d'une feuille d'impots est un exercice à plusieurs mains, il faut que cela soit le plus homogene possible sinon c'est inmaintenable.
Je ne vois pas trop le rapport :)
j'avais ecrit ce post sur usenet a propos de perl ( effectivement cité sur wikipedia http://fr.wikipedia.org/wiki/Perl_%28langage%29(...)(...) ) :
http://groups.google.fr/group/fr.comp.lang.perl/msg/f8e35176b2448bb(...)
Je ne vois pas du tout où tu veux en venir dans ce post. Je pense que tu n'illustres pas assez. Bon ton exemple avec l'enfant et le ballon est drôle. Ceci dit, Larry Wall est un linguiste à ma connaissance, donc je pense que tu creuses un point intéressant de son approche à son langage.
un extrait de code pour le SMTP genericisé ( commentaire d'origine ;) ) :
Si j'ai bien compris, tu construis un objet HA::Net::SMTP puis tu le précises dans les méthodes helo et ehlo. C'est effectivement un side-effect élégant de la syntaxe de création des objets en Perl, j'acquièsce vigoureusement. Maintenant, est-ce que l'intérêt est suffisant pour contrebalancer la ligne « bless » supplémentaire nécessaire pour tous les objets qui n'auront jamais besoin de cette fonctionalité ? Je n'en suis pas vraiment sûr. En plus, Perl pourrait suivre la convention de faire un bless implicite sur la valeur de retour de la fonction "new" avec le nom de package adéquat, si cette valeur n'est pas déjà un objet (ça a peut-être été écarté pour raisons de compatibilités avec les anciens programmes perl non objet utilisant la fonction new ? bon un tel problème n'a pas empêché d'ajouter l'appel implicite de DESTROY).