Pour ceux qui ne connaissent pas (en gros les non-informateux), Python est un des langages à la mode, pas dans la section « hype cool qui en met plein la vue mais qu’on aura oublié dans deux ans » mais dans la plus sérieuse « c’est en prod’ depuis une décennie, Google utilise massivement, et y a pléthore d’applis et de bibliothèques ».
Depuis des années je ne code plus qu’en SQL ou un méta-équivalent, ou en bash, et je voulais retrouver un langage généraliste, agréable, plus concis que Java (c’est pas dur), de plus haut niveau que le C, qui ne me prenne pas le chou à apprendre, moins spécialisé que l’ABAP, plus répandu que l’Objective C, assez établi pour que l’investissement en vaille la peine, impérativement utilisable sur Mac comme Linux, éventuellement Windows, et accessoirement potentiellement utilisable au boulot (ça fait toujours bien sur le CV et bricoler une petite application rapidement peut sauver la vie ou juste une soirée).
Finalement, à part peut-être Ruby, il n’y a à ma connaissance que Python à remplir le cahier des charges.
Globalement c’est très positif. J’ai dévoré un bon livre d’initiation sur le sujet que je recommande, mais pas encore réalisé grand-chose d’envergure, donc ce qui suit sera à revoir dans quelques mois :
J’aime :
- le côté multiplateforme (Linux, Mac, Windows), y compris pour la partie graphique avec PyQt4 (on verra ce que ça vaut à l’usage) ;
- la syntaxe assez propre (je suis un ancien du Pascal, le C est trop dangereux pour un étourdi comme moi, et Perl est illisible) ;
- l’intégration de plein de paradigmes à la mode avec les librairies qui vont bien : les tests intégrés (assert), la documentation automatique...
Je suis surpris par :
- les espaces significatifs : un coup à prendre paraît-il, mais mélanger le formatage et la syntaxe, bôf bôf… ;
(Mise à jour de 2009 : Finalement, c’est une excellente idée qui allège beaucoup le code.) - les distinctions subtiles entre listes, ensembles, tuples, en fin de compte logiques à l’usage, et entre types mutables et immutables — il faut savoir ce qu’on manipule.
J’aime pas trop, peut-être parce que ça casse mes habitudes, mais je vivrai avec :
- le côté interprété (mais comme disent certains, le plus lent là-dedans c’est encore le développeur, et c’est son temps qu’il faut économiser) ;
- la non-déclaration des variables, ne serait-ce que parce que je suis le roi des fuates de frappe ;
- le non-typage explicite des variables, certes plutôt logique quand tout est objet, mais qui doit ouvrir des classes entières de bugs.
(Ces deux derniers points se résumant en « je ne peux pas contraindre les objets que je manipule ».)
Thias avait aussi découvert le langage il y a peu et pour le moment j’aurais tendance à partager les mêmes impressions.
8 réactions
1 De Eric C. - 10/07/2008, 09:20
Hihi, c'est toute la différence entre un informaticien habitué à la rigueur et un codeur du dimanche comme moi. Ce que j'apprécie dans Perl/Python, c'est justement la non-déclaration et le non-typage, ça permet de bricoler vite fait des trucs sans s'emmerder avec des dizaines de lignes de boulot préalable :) Mais c'est clair que dans un contexte industriel, ça doit vite pouvoir devenir un piège.
Perl illisible ? Bon, c'est vrai que parfois ... Mais Python est mieux de ce point de vue ?
2 De Pete - 10/07/2008, 13:04
1) Les programmes Perl illisibles sont dues à de mauvais programmeurs.
2) Les programmes Perl ne sont pas illisibles par nature, contrairement à ce qui est prétendu dans ce billet. N'importe quel langage permet d'obtenir des programmes illisibles.
3 De Nicolas - 10/07/2008, 14:24
J'ai apprécié Python au début, effectivement par la rapidité d'apprentissage et le fait que le code soit concis. J'ai également appris à programmer en Pascal, donc je constate les mêmes 3 inconvénients que toi. Si effectivement le temps du développeur est a économiser, ce ne doit pas être pour sacrifer en temps de débug. Je pars du principe que le programmeur n'est pas toujours rigoureux, et que le langage doit aider l'être. Dans ce sens, il me parait indispensable que le compilateur détecte un maximum d'erreurs (faute de frappe, cast non explicite, etc.). Un bug découvert à la compilation est à mon sens découvert beaucoup plus rapidement qu'à l'exécution. Et c'est là qu'on va gagner du temps.
4 De vpo - 10/07/2008, 17:34
Bah les espaces comme délimiteurs de bloc d'instruction on s'y fait vite même si c'est vrai que c'est curieux.
Mais c'est surtout ennuyeux pour faire un merge entre deux versions d'un fichier Python avec des blocs d'instructions modifiés dans les deux versions ET dont le niveau d'imbrication change dans une des deux versions.
Exemple, un morceau de code passe dans un else ET il faut prendre les modifs des deux versions dans ce bloc.
Ca peut paraître rare, mais pas tant que ça quand on bosse sur des milliers de fichiers.
D'expérience :
Soit tu gardes les espaces et tu te retrouves avec des conflits du fait des espaces, soit tu demande à l'outil de gestion de conf d'ignorer les espaces et là paf, c'est python qui hurle. Bien sûr la solution serait que les outils de diffs utilisés par les système de merges soient capables de faire la diff du texte sans gérer les espaces PUIS appliquent les changements d'espaces. Mais ça, je n'en ai jamais trouvés encore.
Au moins Python force les gens à banir les tabulations comme système d'indentation au profit des espaces.
Ce n'est pas plus mal, car quoi de plus pénible que d'avoir un truc illisible par ce que l'éditeur de machin est configuré pour afficher 8 blancs pour une tabulation et celui de tartanpion pour afficher 4 blancs.
On se retrouve avec des morceaux de code qui dépassent de l'écran / la feuille de papier.
Alors que tout éditeur digne de ce non sait convertir les tab en N espaces et sait gérer le changement d'indentation de N lignes en même temps lorsque l'on sélectionne le texte et que l'on appui sur (<shift>)<tab>.
Enfin, je suis bien d'accord avec Thiais (cf son blog) : ne pas pouvoir déclarer une variable comme une constante c'est vraiment un manque sémantique. Conceptuelement, ça me gêne d'utiliser une variable modifiable pour définir quelque chose qui NE doit PAS varier. ET que se passe-t-il si quelqu'un modifie par erreur cette valeur?
Sinon, c'est clairement un très bon langage, souple et évitant d'avoir à réinventer la roue pour bcp de chose.
5 De Steve Schnepp - 10/07/2008, 19:36
L'illisibilité légendaire des programmes écrits en Perl viens souvent de 2 choses :
- Perl est souvent choisi pour faire un truc ultra rapidement, la lisibilité n'est à ce moment là souvent pas une priorité (alors qu'elle le devrait, on est tous d'accord... )
- Perl est très simple à apprendre, Internet fourmille de tutoriels. "Apprendre Perl en 21 jours" n'est souvent PAS une bonne manière de faire du code très propre
En fait, on retrouve un peu les mêmes critiques qui visent maintenant plutôt PHP (Perl étant tout de même un peu "vintage") sur un billet [1] de Gordon.
[1] "No, PHP does not suck; YOU suck" à gordon-myers.com/?p=103
6 De Le webmestre - 10/07/2008, 21:25
@Eric : Oui, je suis échaudé : un programme bricolé qui devient un prog de production, ou qu’on réécrit parce que la petite extension qu’on veut devient celle de trop, ou qu’on n’arrive plus à comprendre un an après... j’ai déjà donné. Si ça vaut le coup d’être écrit, ça vaut le coup d’être bien écrit. Comme je dis, je n’ai PAS le temps de bâcler les choses. En plus ça cadre avec mon côté perfectionniste.
@Nicolas : Tout pareil. Toute erreur qui peut être décelée automatiquement par une machine DOIT l’être par la machine (compilo), et le plus tôt possible (donc à la compilation, voire dans l’environnement de dév). Je ne sais pas comment je vais concilier ça avec les variables non déclarées. Et je ne parle pas des pièges qu’un langage pose délibérément à un étourdi (if a=b en C... ma croix !), qui en font certes sa richesse parfois, mais le rendent rédhibitoire pour moi.
@Steve & Pete : Il y a l’illisibilité intrinsèque : du Pascal ou du SQL se lisent grosso modo comme de l’anglais, on peut comprendre ce qui se passe sans connaître grand-chose au langage et son maniement subtil des @, (), [], etc. Je serais incapable de relire le peu de perl que j’ai fait - mais les programmes en Pascal, si.
Il y a l’illisibilité encouragée par le langage et ses contraintes : typiquement, un langage-carcan comme le Pascal donnera des machins bricolés plus lisibles qu’en C ou bash. Mais on peut faire du très beau structuré au cordeau en Basic aussi...
Il y a l’illisibilité liée à la complexité intrinsèque du système, sa verbosité, et la masse de code à écrire pour faire les choses bien : là ce serait plutôt Java (ou l’ABAP...) qui décroche la timbale, alors que là les langages de script sont irréprochables.
Il y a l’illisibilité liée au milieu culturel. Et d’après ce que j’ai vu, la culture Perl ou C admire plutôt les « one-liners » qui font plein de choses en une ligne cryptique, ou ne font PAS ce qu’ils sont censés faire (rédhibitoire pour la sécurité, ça).
Et Perl semble bien cumuler les trois handicaps.
Noter que je n’en nie point la puissance, notamment au vu de la monstrueuse collection de librairies. Simplement ce n’est pas un langage pour moi. Et il ne me semble pas si généraliste que ça.
(Je savais que taper sur Perl ça ferait réagir certains - la provoc’ a marché, mais c4est tellement facile :-)
@Steve : Oui, la rançon du succès est que les débutants, les « commerciaux », les gens « pas propres » ou qui n’auraient pas dû faire d’informatique se ruent sur la plate-forme/le langage et veulent du « qui marche tout de suite » plutôt que du propre. Ce fut ou c’est le problème du Basic, de Windows, du PHP... (Tiens, on pourrait discuter de la nécessité de changer régulièrement de langage ou de plate-forme trop démocratisée pour lourder l’existant mal fichu...)
7 De Le webmestre - 10/07/2008, 22:51
@vpo : J’ai sauvé ton billet de Spamplemousse, tu as dû utiliser un terme qu’il n’a pas aimé !
Je n’avais pas pensé au gag de la fusion des programmes. Et pas remarqué le problème des constantes variables. Chouette, je vais pouvoir tester ce que le monde donne avec plusieurs valeurs de π !! :)
8 De Thias - 13/07/2008, 12:21
Il y a aussi l'illisibilité des erreurs. la différence entre un message du genre «il manque une virgule à la ligne 23» et le «syntax error» qui peut inclure un numéro de ligne vague (fin de bloc) ou erroné. Python ne brille pas particulièrement sur ce point. Cela dit ce n'est pas tant une caractéristique du langage que des outils/implémentations. Il est possible de faire des messages d'erreur très clairs en C++, mais ceux de gcc sont généralement mauvais.