On fait la publicité de Python comme langage objet. Mais pourquoi n'ont-ils pas fait les choses jusqu'au bout ?
Là, c'est quand même le ponpon ! Tu dis préférer perl à python, et dans le même temps tu critiques python en tant que langage objet... chapeau, faut oser !
Notons que je n'affirme pas que Perl est mieux là-dessus, Perl est une catastrophe pour l'objet
encore heureux... en python tout est objet ; en perl, objectivement je sais même pas si on peut dire qu'on puisse faire de quelque chose un objet. Sérieusement, la POO en perl est une expérience cauchemardesque que je préfère oublier. C'est dommage, c'est même un vrai gâchis, perl aurait pu être un super langage. Pour reprendre les mots de Larry Wall, perl est ce que la communauté en a voulu...
C'est objet mais pour avoir la longueur d'une chaîne, là où Ruby a fait le boulot correctement (chaine.length) en Python c'est len(chaine).
s="En python aussi, gc..."
print s.__len__()
22
Conversion d'une chaine vers un entier ? En Ruby je fais chaine.to_i en Python rebelote je dois faire int(chaine).
int est une fonction fabrique (design pattern : factory): elle crée un objet de classe int... je vois pas plus objet comme approche.
Par ailleurs je sais que tu sais (et tu le sais...) qu'il n'y a aucune différence fondamentale entre les deux formes f(a) et a.f(), c'est juste du sucre syntaxique, comme savent si bien dire les perliens.
Enfin, je me répète, mais le plus important est bien qu'en python, tout soit objet. Si la syntaxe par défaut ne te plaît pas, tu peux toujours ajouter les méthodes de ton choix aux classes natives afin de pouvoir écrire "128".to_i
Donc tes arguments avancés sur ce point ne tiennent pas.
J'invalide le point n°4.
Au passage, je n'imagine pas me passer de surcharge d'opérateurs, simplissime à mettre en oeuvre en python. Comment peux-tu survivre en perl sans ça ?
Conclusion
Et voilà ma conclusion sur Python, je disais que l'absence de fonctionnel l'alimenterait ; les points ci-dessus aussi.
J'ai répondu aux quatre critiques avancées et j'ai montré qu'elles ne tenaient pas.
Ça n'était donc que ça qui te retenait de passer à python ? Parfait, bienvenue au club !
# Re: objet ? pas objet ?
Posté par bobert . En réponse au message de la puissance de (beep) pour trouver un truc simple en 2 minutes. Évalué à 2.
On fait la publicité de Python comme langage objet. Mais pourquoi n'ont-ils pas fait les choses jusqu'au bout ?
Là, c'est quand même le ponpon ! Tu dis préférer perl à python, et dans le même temps tu critiques python en tant que langage objet... chapeau, faut oser !
Notons que je n'affirme pas que Perl est mieux là-dessus, Perl est une catastrophe pour l'objet
encore heureux... en python tout est objet ; en perl, objectivement je sais même pas si on peut dire qu'on puisse faire de quelque chose un objet. Sérieusement, la POO en perl est une expérience cauchemardesque que je préfère oublier. C'est dommage, c'est même un vrai gâchis, perl aurait pu être un super langage. Pour reprendre les mots de Larry Wall, perl est ce que la communauté en a voulu...
C'est objet mais pour avoir la longueur d'une chaîne, là où Ruby a fait le boulot correctement (chaine.length) en Python c'est len(chaine).
s="En python aussi, gc..."
print s.__len__()
22
Conversion d'une chaine vers un entier ? En Ruby je fais chaine.to_i en Python rebelote je dois faire int(chaine).
int est une fonction fabrique (design pattern : factory): elle crée un objet de classe int... je vois pas plus objet comme approche.
Par ailleurs je sais que tu sais (et tu le sais...) qu'il n'y a aucune différence fondamentale entre les deux formes f(a) et a.f(), c'est juste du sucre syntaxique, comme savent si bien dire les perliens.
Enfin, je me répète, mais le plus important est bien qu'en python, tout soit objet. Si la syntaxe par défaut ne te plaît pas, tu peux toujours ajouter les méthodes de ton choix aux classes natives afin de pouvoir écrire "128".to_i
Donc tes arguments avancés sur ce point ne tiennent pas.
J'invalide le point n°4.
Au passage, je n'imagine pas me passer de surcharge d'opérateurs, simplissime à mettre en oeuvre en python. Comment peux-tu survivre en perl sans ça ?
Conclusion
Et voilà ma conclusion sur Python, je disais que l'absence de fonctionnel l'alimenterait ; les points ci-dessus aussi.
J'ai répondu aux quatre critiques avancées et j'ai montré qu'elles ne tenaient pas.
Ça n'était donc que ça qui te retenait de passer à python ? Parfait, bienvenue au club !