Et je vais commencer avec l'introduction, puisqu'il commence ainsi :
[...]En mars 2010 Rasmus Lerdorf annonçait l'arrêt du développement de PHP6 à cause de difficultés insurmontables dans l'implémentation de l'Unicode.[...]
Or, PHP n'a pas été abandonné pour cette raison.
Lors de l'arrêt du développement, le support d'Unicode au niveau du moteur de PHP 6 était même pleinement fonctionnel, et j'ajouterais qu'il ne restait même qu'un peu plus de 2% des fonctionnalités du langage à mettre à niveau lorsque le développement a été arrêté.
La raison de l'abandon de PHP 6 n'est donc nullement technique, mais humaine.
En effet, ce sont les contributeurs qui ont tué PHP 6, car ils ont jugé que le travail demandé pour migrer vers cette version était trop complexe et trop long pour un gain fonctionnel peu significatif, et j'ai pour preuve le nombre de modifications absolument ridicule effectué sur le dépôt de PHP 6 sur les mois précédents son abandon.
Stéphane enchaîne ensuite en indiquant que la prochaine version majeure de PHP intégrera enfin, comme tout bon langage moderne, une console interactive, comme si PHP n'en disposait pas depuis 2005, via l'option -a
en ligne de commande.
Il poursuit ensuite avec cela :
[...]Plutôt que de modifier un fichier, de l’enregistrer et de rafraîchir son navigateur, on peut maintenant exécuter directement du code dans une console interactive[...]
Je ne sais pas comment Stéphane travaille avec PHP, mais depuis 2005 et l'apparition de la CLI, je ne travaille plus de cette façon, et que je ne quitte même plus VIM pour exécuter du code.
Je passerais sur sa proposition de remanier la syntaxe, qui est une pure affaire de goût personnel, et qui en conséquence ne supporte aucune discussion, et cela même si je trouve son idée de proposer deux syntaxes en fonctions du contexte complètement stupide, d'autant que PHP le fait déjà via l'utilisation de la balise <?=
.
Il poursuit ensuite son article en partant du postulat que PHP a été conçu pour le web.
Pourtant, Dieu Rasmus Lerdorf a toujours présenté son langage comme une colle entre plusieurs technologies qui permet de développer rapidement, et non comme un langage propre dédié au développement web, même s'il est parfaitement capable d'assurer dans ce domaine.
Ses remarques sur l'API du langage sont cependant pertinentes, même si elles sont récurrentes depuis des années, et je suis l'un des premiers à militer pour son homogénéisation, et cela même si Dieu Rasmus Lerdorf a dit très clairement lors de sa conférence au dernier forum PHP que les développeurs qui veulent pouvoir coder proprement ne devrait pas être dans la salle, comprendre ne devrait pas utiliser PHP.
Cependant, le fait qu'il reproche au langage de parler hébreux est tout de même un peu gros.
Le fameux T_PAAMAYIM_NEKUDOTAYIM
dont Stéphane parle dans son article est en effet bien connus, et il est de plus une private joke
qui circule au sein de la communauté du langage en raison des origines des développeurs du Zend Engine.
J'ajouterais que le tokenizer de PHP n'y fait pas appel et utilise en remplacement son équivalent en langage commun, à savoir T_DOUBLE_COLON
.
Cependant, ce n'est pas aussi gros que de dire que la gestion des erreurs telle qu'elle existe aujourd'hui dans le langage rend ce dernier inefficace et difficile à utiliser.
En plus de 10 ans de développement, PHP m'a effectivement posé bien des problèmes, et il continue toujours aujourd'hui, mais leurs origines n'avaient rien à voir avec la gestion des erreurs.
À tout le moins, j'aurais préféré que Stéphane dise dans son article que la gestion des erreurs de Python était bien meilleure que celle de PHP en donnant des arguments objectifs, plutôt que de dire une telle bêtise.
D'autant qu'il poursuit ensuite en critiquant le processus de développement de PHP, qui ne reposerait que sur la liste de diffusion des contributeurs, au contraire de celui de Python qui utilise des PEP.
Je voudrais alors que quelqu'un m'explique la différence entre les PEP de Python et les RFC de PHP, parce que j'avoue avoir un peu de mal à voir la différence.
Stéphane poursuit ensuite en disant que PHP est un tellement mauvais langage qu'il nécessite le recours systématique à un framework.
Donc, en suivant son raisonnement, Ruby, Python et tous les langages pour lesquels il existe des frameworks ne sont pas mieux que PHP.
Est-il vraiment nécessaire que je dise explicitement ce que je pense de cela ?
Pire encore, selon lui, sans framework, le développeur est exposé à un échantillon des mauvaises pratiques :
[...]Dans le cas contraire, le développeur est en contact permanent avec un échantillon des mauvaises pratiques de développement[...]
Il est vrai que les mauvaises pratiques ne se trouvent que dans du code PHP, et que le développeur n'a aucun esprit critique lui permettant de comprendre que le code qu'il a sous les yeux n'est peut être pas le plus pertinent qui soit.
D'ailleurs, vu que j'utilise le langage depuis des années, je dois être un très mauvais développeur, d'autant que, comble du pire, je l'ai utilisé sans framework plus d'une fois.
Bref, je ne suis absolument pas contre le fait que l'on critique PHP, et ce serait d'ailleurs mal venu de ma part puisque je le fais très régulièrement.
Je ne suis pas non plus contre le fait que l'on s'appuie sur ses faiblesses pour promouvoir une technologie alternative, bien au contraire.
La concurrence a du bon, et je suis persuadé qu'une bonne remise en question induite par la montée en puissance significative d'un langage alternatif ferait énormément de bien à PHP.
Encore faut-il que le sujet soit maîtrisé, ce qui n'est visiblement pas le cas pour la partie concernant PHP de l'article, et que cela soit fait correctement, avec des informations valides, précises, et fiables ainsi qu'une argumentation qui tient la route.
28 réactions
1 De Frank Denis - 02/03/2011, 15:55
Surtout, ça ne sert à rien de rêver de "PHP Reloaded" alors que PHP Reboot existe, est tout à fait fonctionnel et pourrait bien être l'avenir de PHP : http://code.google.com/p/phpreboot/
2 De desfrenes - 02/03/2011, 16:13
Ouais... en parlant arguments, la syntaxe n'est pas qu'une affaire de goût, en particulier dans le cas de python puisque tout à fait objectivement celle-ci a le génie d'assurer un minimum de cohérence d'un programmeur à l'autre dans la mise en forme des sources... de fait on parle assez peu de "coding style" en python (voir la PEP8: http://www.python.org/dev/peps/pep-... qui enfonce le clou pour les doutes qui subsisteraient).
Et pour l'utilisation de php en dehors du web... et bien si la plateforme était aussi versatile que tu le dis on aurait peut-être des exemples d'applications remarquables dans d'autres domaines... mais je crois que c'est assez rare.
Pour la gestion des erreurs on en a déjà parlé ici, tu sais ce que je pense.
Ce n'est pas la première fois que phpsolutions fait de la pub pour python, je ne comprend pas bien leur intéret à faire ça.
"la montée en puissance significative d'un langage alternatif " >> j'ai l'impression que ce langage/plateforme n'existe pas, ou plutôt qu'il y a trop de challengers pour qu'un seul s'en dégage. Python, Ruby, Groovy, plein d'autres...
3 De mageekguy - 02/03/2011, 16:15
@desfrenes : J'ai des démons en PHP, des scripts en CLI, j'ai même fais de l'imagerie avec PHP pour prototyper des choses.
PHP n'est pas utile que dans le web, il a d'autres cordes à son arc.
Certes, elles ne sont pas forcément utilisées, et d'ailleurs, je ne dis pas dans mon billet que c'est le cas.
Je dis juste que PHP n'a jamais été conçu expressément pour le web, mais comme un intermédiaire entre le web et d'autres technologies.
4 De mageekguy - 02/03/2011, 16:18
@Frank Denis : PHP au dessus d'une JVM... et est-ce encore du PHP...
Autant faire du Scala.
5 De desfrenes - 02/03/2011, 16:38
"Je dis juste que PHP n'a jamais été conçu expressément pour le web, mais comme un intermédiaire entre le web et d'autres technologies."
J'admire un tel sens de la nuance... Moi aussi je fais du CLI et autre chose que des pages webs en php, mais très franchement c'est plus par flemme d'utliser les bons outils pour ça, parce que j'ai trop l'habitude de penser en php, parce que ça fait X années que je le pratique, parce que j'ai commencé avec ça, etc. J'ai même du faire du php-gtk... mais j'aurai du utiliser quelque chose de mieux comme pyqt par exemple que j'ai pu pratiquer plus tard.
Point amusant, Python ne figure pas au cv de Stéphane Planquart:
"Languages: C/C++, Java, pl/SQL, Php, Css, Html, Javascript, Xml, Uml, Asm..."
Une découverte récente peut-être ?
"Si j'avais un marteau..."
6 De mageekguy - 02/03/2011, 16:45
@desfrenes : Il est clair que je n'irais pas développé une application desktop avec PHP.
Pour le coup, il est clairement inadapté.
Mais bon, tu discutes avec un mec dont le window manager est géré par des démons en PHP, alors.... :).
7 De desfrenes - 02/03/2011, 17:04
Pour du desktop si déjà on avait des threads ça serait plus envisageable... mais bon, il parait que ça ne sert à rien :-P
8 De Frank Denis - 02/03/2011, 17:24
Et Quercus c'est pas du PHP ?
Je ne comprends ton amalgame entre une vm et un langage.
9 De mageekguy - 02/03/2011, 17:31
@Frank Denis : C'est du PHP qui repose sur une VM Java, donc je le met dans le même sac que php.reboot.
Pour simplifier, je n'ai pas une bonne opinion des VM Java.
10 De Amaury - 02/03/2011, 17:31
Ouaip, moi aussi j'ai du code PHP de partout. Des démons (comme dans FineFS, par exemple), mais aussi des scripts CLI pour lesquels je préfère PHP au shell 9 fois sur 10 (pour toutes les librairies accessibles directement dans l'interpréteur, sans parler des objets métier qu'on peut ainsi utiliser directement).
Perso, j'utilisais PHP comme interpréteur CLI largement avant 2005. Il suffisait d'utiliser l'interpréteur CGI avec l'option -q. Ça marchait très bien.
Pour le développement d'application desktop, si on compare PHP-GTK à du XUL/Javascript, du wxWidget/Python ou du QT/QTscript, c'est une solution à envisager sérieusement quand on a les compétences PHP. C'est sûr qu'il faut se forcer à faire les choses proprement (utiliser Glade pour faire le squelette en XML, par exemple), mais rien de rédhibitoire.
Pour en revenir à l'article dans PHPSolutions, peut-être qu'il voulait lancer un sujet polémique, pour faire bouger un peu les choses et voir ce qui en ressortira. Je connais un mec comme ça...
11 De mageekguy - 02/03/2011, 17:53
@Amaury : Je pense qu'on connait le même mec.
Mais je crois savoir que lui essaye de faire les choses correctement.
12 De François - 02/03/2011, 22:12
Une précision sur les consoles.
S'il est vrai qu'une console PHP existe depuis longtemps, j'y vois un inconvénient que celle de Python n'a pas: quand on a une erreur PHP, on sort de cette console (et toutes les variables déjà initialisées sont perdues), alors que les exceptions Python ne font pas quitter la console.
13 De oxman - 02/03/2011, 22:28
Je découvre PHP.Reboot, très intéressant
14 De bohwaz - 03/03/2011, 00:48
Je cite l'article de PHP Solutions :
Je réponds en code à mettre une fois pour toutes dans l'include principal du projet ou (plus radical) dans un auto prepend :
OK, voilà ça c'est fait.
Maintenant toutes les erreurs enverront des exceptions.
Il suffit de lire l'excellente doc de PHP : http://fr.php.net/manual/fr/class.e....
Personnellement le truc qui me fait toujours rebuter à utiliser un autre langage que PHP quand j'ai le choix (et comme tout le monde, je fait des scripts et des démons en PHP), c'est la doc, là où la doc de PHP est parfois spartiate (cf. la partie du imagick), elle a l'immense avantage d'être vraiment très complète et didactique, agrémentée de notes des utilisateurs qui apportent bien souvent des informations très intéressantes.
Cette doc, c'est l'assurance que quand je m'attaque à un truc que je ne connaît pas encore / maîtrise pas / mal, je comprendrais très rapidement le fonctionnement du bouzin.
Je vous laisse comparer avec les docs de Python et Ruby par exemple, pas vraiment lisibles, la doc Python est dans le mieux, mais les exemples sont rares, hors un bon exemple vaux mieux que 100 pages de théorie en général...
Quand à la qualité générale du magazine (qui fait écho à mon sens au faible niveau de l'article cité, pourtant j'aime bien Python), pour une publication de 2011, faire un article sur la gestion des erreurs PHP avec trigger_error (article suivant le troll sur Python) c'est quand même un parfait exemple de mauvaise pratique digne de PHP 3.
PHP n'est pas parfait, on est tous déçus de ne pas pouvoir compter sur PHP6 tout de suite (ah sweet str_transliterate...) mais quand même depuis PHP 5 puis 5.3, on a un langage qui tient tout à fait la route.
Et surtout, les efforts à faire pour continuer à faire fonctionner du vieux code sont minimes, j'ai toujours du code tout moche tout pourri de PHP3 qui fonctionne en PHP 5.3 moyennant quelques changements dans le php.ini.
Le plus gros souci à mon sens reste le nom aléatoire des fonctions, l'ordre des arguments qui change un peu n'importe comment, etc. bref du passif.
15 De Kane - 03/03/2011, 11:40
Tout ce que Stéphane reproche au PHP, en dehors du style, est plus ou moins contournable/déjà corrigé/etc.
La vraie question est plutôt: Comment se fait-il qu'il (et ceux qui l'entourent) ne connaissent pas/utilisent pas/ne lui en ai pas parlé ?
En somme, le langage est trop permissif et aussi bien documenté que les bonnes pratiques ne sont pas mise en exergue ni plébiscités…
C'est clairement un troll appelant au changement… Ce que je ne pourrai pas lui reprocher.
16 De David A - 03/03/2011, 13:42
Réponse intéressante à cet article de Stéphane Planquart qui annonçait un peu de bruit dans la communauté PHP française.
A noter son blog ouvert pour l'occasion accessible via http://www.pythonphp.org/2011/03/py... sur lequel j'ai mis un message pour renvoyer sur ton article.
Moi je me posai un peu la question sur le réel successeur entre Python ou Ruby, mais bon, cela restera indéfini pour quelques temps encore je pense... A moins que PHP subisse une bonne et violente restructuration..
17 De Paul - 03/03/2011, 16:16
Y a t'il des projets de fork de PHP ? (et pas un PHP sur une JVM
)
18 De Kane - 03/03/2011, 19:04
Et Node.js avec Coffeescript ?
19 De Paul - 03/03/2011, 21:02
Ils ont supprimé le GIL (Global Interpreter Lock) dans python 3.x ? il me semble pas du coup qu'on puisse dire que python peut etre multithread.
20 De mageekguy - 03/03/2011, 22:46
@Paul : Pas à ma connaissance, et ça serait un énorme travail.
21 De dePassage - 04/03/2011, 12:55
Bjr,
Vous écrivez régulièrement Rasmus Lerdorf = Dieu (ou tout comme) dans vos articles, ne pensez-vous pas que le 'mal profond' de PHP est qu'au-dessus de Dieu il y ait les 2 promoteurs de Zend et que si l'on n'adhère pas (pour X et Y raisons) à la voie tracée par Zend, ben on ressent comme une absence de véritable leader concernant le langage (R.Lerdorf ne m'ayant jamais semblé vouloir endossé ce rôle, et en est-il capable ?).
Autrement dit ne manque-t-il pas à PHP son véritable Dieu, à la Guido van Rossum par exemple, capable d'amener le langage là où le bon sens commun se trouve ? avec pour conséquence que PHP 'patine' depuis 4, 5 ans.
Juste pour éclairer ma lanterne, merci à vous.
22 De mageekguy - 04/03/2011, 13:52
@dePassage : Ma référence récurrente à Dieu en parlant de Rasmus est tout ce qu'il y a d'ironique, d'où le
Dieu, car comme vous l'avez noté, il n'a pas un rôle de leader au niveau des contributeurs de PHP, et il ne semble d'ailleurs aucunement le souhaiter.Le management de projet ne l'intéresse clairement pas, et il préfère se concentrer sur la résolution de ce qu'il considère comme des problèmes importants, plutôt que sur ce genre de tâche.
Pour autant, lorsqu'il parle, il est écouté, et il est rarissime que les contributeurs aillent à l'encontre de son avis.
Il suffit donc qu'il soutienne une initiative pour qu'elle soit immédiatement acceptée par la communauté (nous venons encore d'en avoir la preuve avec la RFC proposant l'intégration d'un serveur http au sein de PHP), et à contrario, il suffit qu'il s'érige contre une suggestion pour qu'elle soit définitivement enterrée (l'intégration des threads dans le langage en est un parfait exemple), même si ce n'est pas une règle absolue puisqu'il arrive bien souvent que des choses soient faites sans qu'il ai donné son avis.
Il fait donc tout de même, à sa manière, un peu la pluie et le beau temps, lorsqu'il en a la motivation.
Malgré cela, Je suis d'accord avec vous, il manque, et il a toujours manqué, un réel leadership aux contributeurs, ou du moins une personne capable de trancher lors des débats importants, ce qui permettrait de mettre fin aux guerres de tranchées récurrentes au sein de la communauté.
23 De desfrenes - 04/03/2011, 13:58
@Paul: Le GIL n'a pas été supprimé mais amélioré. Cela dit on est toujours limité à 1 core. Sinon il y a Jython qui étant basé sur la JVM n'a pas de GIL.
24 De Stephane - 04/03/2011, 17:54
Effectivement il existe bien une console interactive en php. Voici un petit tour d'horizon des consoles interactives php et python. http://www.pythonphp.org/2011/03/me...
25 De mageekguy - 04/03/2011, 17:58
@Stephane : La gestion des erreurs est effectivement un problème, et d'ailleurs, je n'ai jamais dis qu'il n'y en avait pas, que ce soit au niveau de la console ou de PHP.
J'ajouterais que ma façon de travailler fait que je vois mal l'utilité de la console, au moins pour PHP.
J'édite en effet mes scripts dans VIM, et je bénéficie donc de sa puissance (coloration, complétion, j'en passe et des meilleurs) pour l'édition de mon script
J'exécute ensuite ce dernier sans quitter VIM en appuyant simplement sur une touche.
Bref, VIM est ma console.
26 De sunse8 - 05/03/2011, 01:03
Python est techniquement plus avancé et abouti. Mais PHP écrase Python en terme de visibilité : hébergement, communauté, tutoriaux, scripts, applications, cms, etc.
L'écosytème est de loin plus important que le langage en lui-même ! La gestion des erreurs ou le support console ? Des détails à mon sens très peu pertinents pour comparer globalement ces deux langages.
27 De stephane - 05/03/2011, 09:06
@mageekguy il y a toujours une utilité à une console, surtout quand elle fonctionne bien et que l'on peut faire des tests dans une fenêtre et son code dans une autre. C'est une façon de gagner du temps quand on veut maquetter quelque chose. PHP ne dispose pas d'un console interactive utilisable (donc pas de console) ce qui fait que les développeurs PHP n'en ressente pas forcement le besoin. C'est la même chose qu'avec la documentation en ligne dans une shell unix, il n'y a pas d'équivalent sous windows et les admins sys windows ne s'en plainent pas.
28 De Amaury - 06/03/2011, 13:58
@Paul : La seule chose digne d'intérêt que je connaisse qui ressemble à un fork (même si ça n'en est pas un), c'est le projet HipHop de Facebook, qui permet de compiler du code PHP en natif (en passant par une phase de traduction en C++).
Un compilateur JIT, ce serait pas mal, mais c'est un boulot titanesque.