Le forum PHP 2010, qui a eu lieu les 9 et 10 novembre derniers, a accueilli quatre figures emblématiques de la communauté des développeurs de PHP.
Rasmus Lerdorf, le créateur du langage, et Zeev Suraski, l'un des deux pères du Zend Engine, avaient ainsi fait le déplacement jusqu'à Paris.
De plus, Derick Rethans, notamment connu pour avoir développé Xdebug, et Ilia Alshanetsky, qui participe au développement du langage dans sa globalité, ont participé à l'événement, qui fêtait cette année les 15 ans d'existence du langage et les 10 ans de l'AFUP.
J'ai donc profité de cette occasion pour discuter physiquement, avec Rasmus, Derick et Ilia de l'avenir de PHP et du fonctionnement de la communauté des développeurs, sans passer par mes outils de communication habituels que sont IRC et la liste de diffusion des développeurs du langage, internals@.
Je vous livre donc dans les lignes qui suivent une synthèse de ces discussions très informelles, puisqu'elles ont eu lieu en dehors des conférences.
J'ai ainsi eu au cours de nos conversation la confirmation qu'il y avait 90% de chances pour que Derick Rethans soit le release master
de la prochaine version du langage.
Cette version, fruit du travail énorme effectuée par la communauté des développeurs depuis l'abandon du développement de PHP 6, sera certainement nommée PHP 5.4 et sa sortie est prévue pour la première moitié de l'année 2011.
Elle proposera entre autre chose un modèle objet renforcé, via le concept de traits, ainsi que le support de DTrace, la possibilité d’accéder directement aux éléments d'un tableau renvoyé par une fonction ou une méthode, et des améliorations au niveau du support des fonctions anonymes et des fermetures.
Elle donnera également la possibilité de définir le type numérique des arguments des méthodes et des fonctions, et elle proposera l'interface jsonable
qui permettra de définir le comportement d'un objet lorsqu'il sera sérialisé au format JSON.
Cependant, tout cela n'a pas été fait au détriment des performances, puisqu'elles sont en nette hausse, grâce à une optimisation poussée de la gestion de la mémoire.
PHP 5.4 sera donc plus rapide, mais surtout beaucoup moins gourmand en mémoire, puisque les tests montrent que suivant le contexte d'exécution, il est susceptible de consommer jusqu'à 30% de mémoire de moins que la précédente version.
Enfin, certains boulets
historiques de PHP, comme la directive register_globals
, le safe mode
ou les magic quotes
ont été supprimés, mais en contrepartie, le code existant reposant sur ces fonctionnalités ne fonctionnera plus.
Ilia m'a d'ailleurs indiqué que ce nettoyage devrait se poursuivre avec les prochaines versions, de façon à assainir le langage, mais cependant, cela ne provoquera jamais de cassure brutale de la compatibilité.
La communauté a en effet la volonté de faire cela de manière très progressive afin de permettre une mise à jour en douceur des quelques milliards de lignes de code PHP existantes dans le monde.
Et de plus, le périmètre de cet assainissement n'est pas clairement défini puisque le développement du langage suit à l'heure actuelle une politique très pragmatique.
Ainsi, toute modification ou un évolution doit absolument répondre à une problématique réelle et sérieuse qui ne peut pas être résolue par un autre moyen, tout en ayant un impact minimal sur les performances du langage et ne pas rendre le langage plus complexe.
L'ajout de l'interface jsonable
est l'exemple parfait de cette politique, car elle permet de répondre simplement à une problématique concrète dans le monde du développement web d'aujourd'hui, induite l'utilisation massive d'AJAX qui nécessite de faire transiter dans un format simple un volume de données important entre des clients et un serveur.
En conséquence, la décision de supprimer une fonctionnalité jugée comme dangereuse ou comme étant une erreur de conception ne sera prise qu'uniquement en fonction de cet aspect pragmatique.
C'est la raison pour laquelle il y a peu de chances de voir un jour la règle de nommage des fonctions de PHP uniformisée, alors que c'est une demande récurrente des utilisateurs du langage.
En effet, les fonctions concernées fonctionnent parfaitement, et la correction de cet aspect purement esthétique n'est pas jugée comme primordiale, même si Rasmus avoue que s'il en avait la possibilité, il réécrirait PHP en suivant une politique de nommage des fonctions beaucoup plus rigoureuse.
Cette philosophie est également la cause du refus de l'implémentation des annotations proposée récemment.
D'une part, les partisans des annotations n'ont pas su convaincre les contributeurs de la pertinence de ce qu'ils proposaient, tant au niveau fonctionnel que technique.
D'autre part, les annotations peuvent être émulée à l'aide d'outils déjà présent dans le langage, et notamment l'introspection.
Il est cependant possible d'espérer voir arriver un jour les annotations dans PHP, car Derick Rethans a posé le dossier sur la table lorsqu'il a proposé une feuille de route pour la publication de la prochaine version du langage, dont la première version alpha doit être diffusée à la fin de novembre 2010.
Il a également proposé d'intégrer APC, l'un des systèmes de cache d'opcode disponible sur le marché, dans le cœur du langage.
Cependant, aucune décision définitive n'a été prise à ce niveau, car certain problème sont à régler, le premier d'entre eux étant que pour l'instant, APC ne fonctionne pas avec la version de développement de PHP.
Et pour en revenir à l'aspect pragmatique du développement du langage, Rasmus le justifie très simplement.
Pour lui, PHP doit être un outil simple et efficace, qui doit permettre avant tout de résoudre des problèmes réels rapidement.En conséquence, il ne faut développer que l'indispensable, et peu importe si l'implémentation sous-jacente n'est pas belle
.
De son point de vue, un code mal écrit qui résout un problème vite et bien vaut mieux qu'aucune solution.
De plus, il pense qu'il est inutile de perdre du temps à développer des fonctionnalités qui ne présente pas une valeur ajoutée suffisante ou à rendre le code plus esthétique : la résolution du problème prévaut sur la beauté de la solution.
Les membres de la communauté des développeurs appliquent également cette philosophie, même si Rasmus avoue qu'ils sont certainement beaucoup moins extrémistes que lui.
Et d'après Ilia et Derick, ils l'appliquent d'autant mieux que la plupart d'entre sont des bénévoles qui développent le langage sur leur temps libre.
Ils préfèrent donc ne pas perdre leur temps à refaire plus proprement des choses qui fonctionnent alors qu'elles sont mal implémentées, et à contrario se concentrer sur des développements à forte valeur ajoutée pour le plus grand nombre plutôt que sur des choses plus exclusives fonctionnellement et nécessaires uniquement à une minorité.
Le support d'Unicode, qui devait être la fonctionnalité phare de PHP 6, fait d'ailleurs les frais de cette politique, puisque les développeurs du langage considèrent que les outils présent dans PHP actuellement pour manipuler des chaînes de caractères dans ce format sont suffisants pour répondre à la majorité des besoins.
En conséquence, depuis l'arrêt du développement de PHP 6, la communauté des contributeurs n'a fait aucun développement pour implémenter ou améliorer son support dans le langage, et il ne faut donc pas compter voir ce dernier être intégré plus fortement à PHP à court terme.
PDO, la couche d'abstraction dédiées aux bases de données, fait également les frais de cette approche pragmatique.
Il existe en effet une
Cependant, le développement est au point mort, notamment à cause du fait que la version actuelle est fonctionnelle et couvre un spectre suffisant des besoins des utilisateurs du langage.
Autre conséquence, la feuille de route concernant l'ajout de fonctionnalité est complètement vierge actuellement, et aussi bien Rasmus que Ilia ou Derick n'ont pu me donner la moindre indication sur une quelconque orientation.
J'ai donc lancé quelques sondes
pour connaître leur ressenti par rapport à quelques technologies émergentes dans le web actuellement.
En effet, la volonté de la communauté des développeurs est de faire évoluer le langage en même temps que le web, et il m'a donc semblé pertinent de leur demander ce qu'ils pensaient d'une technologie comme node.js, par exemple, qui permet d'exécuter du code Javascript au niveau du serveur avec une gestion des entrées/sorties non bloquante.
Ilia et Derick pensent que c'est une technologie très intéressante, mais que, pour l'instant, l'intérêt d'intégrer tout ou partie des concepts sous-jacents de node.js n'est pas démontré.
Rasmus est quand à lui beaucoup plus intéressé par Gearman, qui permet faire de la distribution de tâches de manière asynchrone sur un ou plusieurs serveurs.
Il voit en effet cette technologie comme une alternative crédible aux threads, qu'il considère en conséquence comme complètement inutile au niveau de PHP.
J'ai également évoqué le départ de Lukas Kahwe Smith de la communauté des développeurs avec Ilia.
Pour mémoire, Lukas est celui qui avait une réelle volonté de structurer le développement du langage.
Pour cela, il a mis en place divers outils de suivi, ainsi que le principe des release masters
et des RFC.
Le fait qu'il quitte le projet pouvait donc potentiellement avoir un impact important sur le développement du langage.
Cependant, Ilia considère que ce type d'événement est parfaitement normal dans le sens ou il fait parti du cycle de vie d'un projet libre, et qu'en conséquence, son impact est nul.
Le futur de PHP s'annonce donc intéressant, car si pour son créateur, le langage est mature et ne nécessite plus d'évolution majeure, car il lui permet de résoudre l'ensemble de ses problèmes, la porte n'est pas fermée, bien au contraire.
L'ajout de fonctionnalités ou les évolutions devront juste être en accord avec la politique de développement pragmatique appliquée par les contributeurs.
De plus, les problèmes rencontrés ces derniers mois dans le développement du langage et par sa communauté n'a pas perturbé fortement son évolution, puisqu'une nouvelle version proposant de nouvelles fonctionnalités va voir prochainement le jour, et cela même si elle n'implémentera pas Unicode ou certaines évolutions réclamées par certains utilisateurs, car jugées peu pertinentes, aussi bien fonctionnellement que techniquement.
17 réactions
1 De Nicolas Laforêt - 21/12/2010, 08:21
Hello,
J'ai un peu de mal a comprendre ce "manque d'objectif" de la part de la "tête" de PHP... Ne pas vouloir passer du temps a renommer une partie des fonctions car c'est une perte de temps pourrait se comprendre s'ils avaient des gros morceaux a développer sur le langage, mais ça ne semble pas être le cas .... donc c'est tout ? ....en gros : "tout marche donc on touche rien de ce qui existe, on touche que des nouveauté, sauf qu'on a pas beaucoup de nouveauté a mettre donc on voit au jour le jour" ... ? Pas très moteur pour une équipe je trouve.
Enfin... ce n'est que mon ressentit et mon avis.
Merci pour cet article, dommage d'avoir passer beaucoup de temps a le rédiger pour ne pas le voir publier dans programmez, même s'il a tout autant d’intérêt ici que la bas, voir même plus.
Bonne journée.
2 De Blount - 21/12/2010, 08:57
Merci pour cet article intéressant.
Je ne suis tout de même pas d'accord avec Rasmus sur sa politique de priorité, quand il dit que la résolu rapide d'un problème prévaut sur la "beauté" du code.
Pour moi la "beauté" du code consiste à réduire au minimum le nombre de lignes dans le code. Le but n'est certainement pas de gagner quelques octets sur le disque, mais d'avoir une meilleur maintenance. Plus le code est réduit, plus l'analyse se fait plus rapide, que l'on soit l'auteur ou pas.
Quand on applique cela à des millions de lignes, si dans le lot la moitié est "inutile", c'est tout de même une grosse perte de temps de revenir dessus.
Le nombre de lignes doit être une des composantes de la "beauté" du code, la structure en est une autre. Je ne suis pas le plus doué sur la structuration de code, mais j'ai conscience de son importance.
3 De Eric - 21/12/2010, 09:13
Merci pour cet article vraiment très intéressant.
> En conséquence, il ne faut développer que l'indispensable,
Pour ca, je suis complétement d'accord, je pense même qu'il commence à y avoir "trop" de choses dans PHP hérité de langage actuellement plus à la mode, mais qui dans quelque année deviendrons des cauchemars pour la maintenance (fermeture, trait )
> Ils préfèrent donc ne pas perdre leur temps à refaire plus proprement des choses qui fonctionnent alors qu'elles sont mal implémentées,
Ca, c'est potentiellement une erreur qui explique le gigantisme du code PHP. Mais ca ne regarde que les développeurs.
4 De sunseb - 21/12/2010, 09:24
D'accord avec les précédentes interventions ! C'est dommage ce pragmatisme poussé à l'extrême et ce manque de créativité ou de magie.
Maintenant, pour du hype et du nouveau, il faut sans doute se tourner vers les frameworks.
Je me demandais, est-ce que ce serait coûteux techniquement de renommer les fonctions PHP tout en gardant un alias vers les anciennes fonctions (pour ne pas casser la compatibilité) ?
Est-ce qu'il a déjà eu des forks de PHP ? (Simple curiosité, c'est pas une solution que je préconise !)
5 De MathRobin - 21/12/2010, 17:15
Comment est-ce qu'on peut pousser alors justement à prendre en compte un peu plus l'esthétisme du langage? Comme tu le sais, j'adore chipoter, mais aussi parce que je fais partie de ces extrémistes du beau code qui implique un code avec des conventions de nommage/codage très strictes, correctement commenté, versionné, ...
Il y a nombre de méthodes qui sont nommés n'importe comment et qui sont régulièrement utilisés dans tout dev avancé, pendant que d'autres utilisent une logique assez présente. C'est très dommage que tout cela ne soit pas uniforme et je trouve que ça fait vraiment perdre de sa crédibilité à ce langage.
6 De mageekguy - 21/12/2010, 17:21
@MathRobin : Rasmus te répondrait la même chose que ce qu'il a dit lors de sa keynote d'ouverture du forum PHP 2010 : si tu aime les beaux langages, tu n'utilises pas le bon et tu devrais en changer.
7 De MathRobin - 21/12/2010, 18:08
Il n'a pas un pet de sens commercial lui non ? Je ne me vois pas exposer ce genre de réponse à un client.
8 De mageekguy - 21/12/2010, 18:12
@MathRobin : Je connais assez peu de client suffisamment fort en programmation pour juger de la qualité du code, même au niveau esthétique, et j'oserais même dire aucun.
Sinon, il n'aurait pas besoin de moi.
Ton argument n'est donc guère recevable dans ce contexte.
Mais oui, il n'est pas commercial pour deux sous, et il tient plus de l'ours mal léché que du bisounours :).
9 De Nicolas Laforêt - 22/12/2010, 08:19
Tu es un peu réducteur la, si ton client est une SSII qui sous-traite, une boite qui a un SI qui check les devs, si ton client fait procéder a un audit par une équipe parallèle, si travail entre indépendant, si c'est ta boite... Quelques exemples qui pourrait impliquer qu'un code crade provoque quelques problèmes avec ton "client".
Reste que le sentiment est un peu trop "je fais ce que je veux, pas ce que 1.000.000 de développeur PHP veulent"... Sans les personnes pour utiliser PHP il ne serait rien, envoyer les gens chier comme ça va lui revenir en pleine tête un jour ou l'autre et n'encourage pas a faire confiance. C'est la communauté qui fait le langage, il faudrait qu'ils le comprennent un jour.
10 De mageekguy - 22/12/2010, 08:57
@Nicolas Laforêt : Il faudrait définir ce qu'est un code dans le cas de PHP.
S'il est crade juste parce qu'il y a un mix de subsr(), str_*(), etc, parce que nécessaire au domaine fonctionnel, est-ce réellement
?À mon sens, la réponse est non.
11 De MathRobin - 22/12/2010, 09:34
Je n'irais pas jusqu'à dire qu'il est crade mais il manque parfois de sens ou simplement de continuité comme tu le remontres toi-même dans ta dernière réponse. En soit ce n'est pas très grave, mais l'image professionnelle de PHP en pâtit beaucoup je trouve. Certes pas que de ça et de loin, mais si on pouvait se passer de ce genre de choses, ça serait un plus.
Après je suis d'accord qu'il est rare de tomber sur un client qui s'y connait vraiment, quand on bosse dans l'édition de logiciels ou de sites webs. Dans les télécoms, secteur où je bosse, pareil.
Mais dans le freelance, quand il faut faire un dév complet en proposant un langage, régulièrement tu verras PHP se faire jeter. Et pas toujours parce qu'il n'est pas le plus adapté, juste parce qu'il n'est pas toujours considéré comme un langage de pro.
@Nicolas Laforêt: certes, c'est un peu bourrin d'ignorer les réclamations de nombre de ses utilisateurs, mais il y en a un grand nombre aussi qui ne le demandent pas, ou qui préfèrent que ça ne change pas et surtout, ça reste son bébé à lui. Son point de vue peut se défendre aussi.
12 De mageekguy - 22/12/2010, 09:56
@MathRobin : Ça reste son bébé, oui et non, dans le sens où il ne participe plus réellement au développement.
Il est plus que discret, et se contente la plupart du temps d'une remarque sur internals@ ou de donner son avis sur un point précis.
Et lorsque ça arrive, il a évidemment un certain poids, mais son influence s'arrête là, pour ce que je peux en voir et en savoir.
De son propre aveux, PHP en tant que tel ne l'intéresse plus.
Ce qui l'intéresse, c'est de régler des problèmes concrets grâce à lui, car c'est pour cela qui l'a conçu au départ.
PHP fait tout ce dont il a besoin, donc il est passé, et je pense depuis longtemps, à autre chose, et il se
de jouer le gardien du temple pour éviter que la philosophie qu'il a choisie pour son , comme tu l'appelles, ne soit trop dénaturé et que PHP ne réponde plus alors à ses besoins ou à sa philosophie de développement.13 De norto - 23/12/2010, 09:47
"Il n'a pas un pet de sens commercial lui non ? Je ne me vois pas exposer ce genre de réponse à un client."
@MathRobin : C'est justement le cas. PHP n'est pas un produit à vendre, c'est un outil qu'il a mis à disposition, nuance ... Et c'est cette transparence qui me plait le plus dans le monde du libre.
14 De MathRobin - 23/12/2010, 10:59
Faux, c'est justement quelque chose que tu peux vendre. Quand tu vends un soft ou un service, tu vends aussi ce qui a servi/sert/servira à le produire.
Suffit de voir les différences de salaire entre un ingé php et un ingé .Net de même durée d'expérience. C'est pas énorme mais ça suffit à voir que la techno derrière est vendue avec le produit/service.
15 De norto - 23/12/2010, 12:42
Hum, ce que tu dit est intéressant en un sens : Tu penserais que PHP se DOIT de devenir un outil pour les professionnels, c'est ça ?
Pour moi PHP n'est qu'un outil libre qui m'aide à développer rapidement des solutions simples à mettre en place.
Je ne suis effectivement qu'un
, mais ça me suffit.Personnellement je ne compte pas me faire un
grâce à mon langage de prédilection.Ce que je veux, c'est développer, si possible proprement, mais surtout, simplement.
J'aime l'argent, mais j'aime développer avant tout et sans me prendre la tête et j'avoue que je me fait du mal : je passe régulièrement sur ce blog alors que non seulement je suis encore en train d'utiliser PHP 5.2 mais en plus j'essaye même de me mettre au Perl en ce moment même.
J'ai cru comprendre qu'il y a peu de service avec PHP, Il suffit de voir son
sur php.net qui me semble déjà très complet et accessible ... sans avoir à acheter le moindre bouquin, ni installer le moindre framework, alors oui ça ne suffit qu'aux purs novices/amateur/script-kiddie, mais pour moi c'est le principal.Ce que j'aime dans PHP c'est qu'il permet à un type qui
de faire un truc qui tourne en quelques instants.Si on recompare .Net à LAMP, la différence accessibilité doit déjà se voir non ?
C'est vrai qu'ici le professionnalisme de PHP semble être au cœur du débat mais pour moi PHP répond bien à sont besoin premier : un langage accessible aux débutants. il aide le particulier à développer un truc déjà bien 'sexy' de manière simple.
Cette article est pour moi une bonne remise au point des choses : Rasmus semble avoir offert PHP plus pour les petit développeurs en herbe plutôt qu'aux pro ingénieur en chef de multi-projets de plus de 100 millions de lignes,
Ah et une dernière remise au point de ma part : Ramsus semble ne pas vouloir se faire de l'argent avec PHP, moi non plus mais si tu veux te faire de l'argent avec PHP c'est ton droit.
Mais de mon point de vue, tu vas te faire du mal.
16 De mageekguy - 23/12/2010, 13:21
@norto : Je laisse couler car le débat est très intéressant, mais je sens se pointer le troll bien velu à terme.
Je compte donc sur toi ainsi que sur ceux qui te répondront pour ne pas trop dériver.
17 De MathRobin - 23/12/2010, 14:53
@norto: L'idée n'est pas spécialement de se faire de l'argent même si je le reconnais, j'aime ça aussi.
Je suis d'ailleurs totalement d'accord avec toi que si on reste sur l'idée de départ qui est de faire de PHP un langage accessible au plus grand nombre et surtout aux non-développeurs, effectivement, c'est réussi. C'est un langage qui s'apprend facilement, auquel on peut facilement s'accrocher et suffisamment riche pour répondre je crois à la totalité des besoins en développement web (dans ce que j'ai pu vouloir faire en tout cas).
Ceci dit, je n'ai pas dit que PHP se doit de devenir un langage professionnel. J'essaie plutôt de faire passer le message qu'en tant que développeurs PHP, on passe (trop) souvent pour des rigolos, des bricolos. Et ce n'est pas avec ces paroles là "si tu aime les beaux langages, tu n'utilises pas le bon et tu devrais en changer." (Rasmus) que ça va aider.
Je travaille dans le développement web depuis quelques années même si depuis seulement quelques semaines si on ne compte pas les stages/apprentissages. J'aimerais qu'un jour on me regarde autrement que comme un gamin qui code dans sa chambre parce que je fais du PHP. C'est une image qu'on m'a souvent, très souvent collé.
Pour ce qui est du service autour de PHP, je ne comprends pas ta remarque, j'ai dû mal m'exprimer ou c'est à quelqu'un d'autre que tu réponds parce que je suis bien d'accord avec toi, rien que php.net est une source énorme d'informations. La documentation coule à profusion partout sur le net ou même sous forme de livres.
Pour finir, je reviens sur ce qui me marque le plus dans ton dernier message. Cette phrase: "Pour moi PHP n'est qu'un outil libre qui m'aide à développer rapidement des solutions simples à mettre en place.". Solutions simples... c'est une des choses que j'entends le plus des regards extérieurs à PHP sur ce langage. Et c'est aussi ce terme que je voudrais voir disparaître. Facebook (c'est un exemple parmi tant d'autres, juste que c'est le plus connu que j'ai en tête) est un exemple de service en ligne complexe développé avec PHP. Mais les gens, les extérieurs eux ne pensent pas à ça quand ils pensent à PHP, ils pensent à phpbb par exemple et ses innombrables et toujours plus nombreuses failles de sécurité, manques incroyables de performances et cet aspect amateur général.
Je veux que PHP reste ce langage accessible que j'ai appris tout seul dans ma chambre quand j'étais ado, mais je veux aussi qu'il soit reconnu comme un langage noble pour des professionnels. Je veux qu'on arrête de me dire, de dire des pros de PHP, qu'on est presque des sous-informaticiens à cause de notre langage favori.