Or, cette date de livraison de PHP 7 a plus ou moins été décidée arbitrairement par les promoteurs de phpng, et d’autres développeurs, à commencer par ceux qui mettent quotidiennement les mains dans le code du langage, doute très fortement qu’un tel délai soit tenable.
Et comme à ma connaissance, la feuille de route fonctionnelle relative à PHP 7 est inexistante même si beaucoup ont des idées sur ce qui devrait être son contenu, je ne peux que partager leur opinion, car je vois mal comment une date de livraison peut avoir été définie alors que la masse de travail à réaliser est inconnue.
Comme le disent si bien deux comiques français, il y a en qui ont essayé, et ils ont eu des problèmes.
De plus, phpng est apparemment lui-même loin d’être finalisé, puisqu’il semble manquer de cohérence et que sa documentation est succincte pour un code de cette complexité.
There is almost no documentation, the APIs are not clean or inconsistent […] but having two separate zpp, same area's functions mixing use of zend_char and char (creating hard to catch bugs, not always catch-able at compile time f.e.)
Et enfin, même si ce délai de livraison était réaliste, il faudrait à minima que les développeurs du langage produisent une version 5.7 du langage pour respecter le rythme prévu.
Durant un an à minima, si tout se passe bien, les développeurs de PHP devront donc travailler sur deux versions divergentes du code techniquement parlant puisque l’une utilisera la dernière version du Zend Engine 2 et l’autre phpng.
Et de plus, phpng évoluera certainement pendant ce temps de son côté, car même s’il a énormément progressé depuis qu’il a été présenté par Zend, il subira encore des évolutions significatives, ne serait-ce que pour rester compatible avec les modifications apportées au Zend Engine 2.
Or, le fiasco de PHP 6 a, entre autres choses, démontré que la gestion de deux branches très différentes du code du langage est un exercice plus que périlleux pour les développeurs.
J’ai donc l’impression que contrairement à ce que je pensais, ces derniers n’ont pas vraiment tiré les leçons de l’échec du développement de PHP 6, et que malheureusement l’histoire va une nouvelle fois se répéter, d'autant que les luttes d'influences au sein d'internals@ ont été plus qu'intense à ce sujet.
Et même si je peux comprendre la pression et le danger économique que représente le développement de HHVM pour Zend, j’ai à contrario vraiment du mal à comprendre que la plupart des développeurs du langage ne voient pas le danger que représente cette stratégie.
Donc, lorsque j’apprends que Johannes donne des conférences à propos de phpng, un produit non finalisé qui ne sera intégré au sein du langage que probablement dans plusieurs années, je ne peux m’empêcher de rire un peu jaune, et j’espère que cela intéressera suffisamment les développeurs présents à sa conférence pour qu’ils décident de participer au mariage de phpng avec PHP 7 pour que je n’ai pas à faire dans trois ans sa nécrologie.
4 réactions
1 De pascal - 29/08/2014, 17:25
Je pense que tu tires le signal d'alarme un peu trop tôt, je suis internals et je ne suis pas d'accord, par ailleurs tes infos ne sont plus fraîches
La branche phpng n'existe plus et a déjà été fusionnée sur le master de PHP, on est précisémment dans une situation différente de PHP 6 ou le développement se faisait sur une branche à part qui n'a jamais été mergée sur master. Tous les développements se font sur cette base maintenant et les premiers gros commits depuis ça sont basés sur PHPNG (l'AST dans la compilation, amélioration en 64 bits… https://wiki.php.net/rfc#php_70). On est plus dans la situation où PHPNG est un développement parallèle de la société Zend, ça fait déjà partie de PHPNG.
Le développement de 5.7 se fait à partir de 5.6 et il n'y a presque rien de prévu pour le moment pour 5.7, ça sera vraiment je pense juste une version de transition vers 7.0, ce n'est pas seulement Zend qui le veut, ça semble être l'avis unamime sur la liste, presque toutes les demandes d'améliorations visent 7.0 tout simplement parceque tout ce qui est proposé depuis un an nécessite de casser la compatibilité ascendante et ne peut donc pas être dans une version 5.x. Donc la maintenance de la branche 5.x ne semble pas être si problématique. On est vraiment sur des problèmes de personnes, la discussion sur l'intégration de PHPNG a été plus qu'houleuse mais en fin de compte la RFC a été acceptée par 44 voix pour et 2 voix contre seulement.
En ce qui concerne la feuille de route, je dirais que justement ils ont tiré des leçons de PHP 6 qui avait une feuille de route claire et établie et… qui n'a pas pu être tenue, ce qui a conduit à l'échec et l'abandon de la version 6. Le fonctionnement de PHP avec les RFC est qu'il n'y a pas de feuille de route définie par avance mais que tout passe par les RFC et que les livraisons contiennent ce qui est prêt une fois par an, 5.(4/5/6) ont été livrées avec succès sur ce principe et je pense que PHP 7 le sera aussi. PHP n'a pas de vrai leadership ni de boite qui chapote le projet avec des devs à plein temps sur le long terme, dans ce contexte un processus de livraison par petits pas, avec des sorties régulières me semble au contraire bien adapté.
PHP est dans une situation bien meilleure aujourd'hui qu'il y a 4 ans, mais les tensions sont encore énormes sur internals entre 4 groupes à mon avis:
Le bordel qu'on voit sur internals, c'est la lutte entre ces quatre familles de contributeurs.
Laissons de côté les ultra-conservateurs, ils n'apportent à mon avis pas grand chose et sont moins nombreux que par le passé.
Zend a besoin de montrer qu'il reste dans la course au niveau perfs et ils ont donc opensourcé leur cache d'opcode dans 5.5 et réécrit le moteur avec une optique perf avec PHPNG. Dans les deux cas ils ont fait un passage en force pour que leurs développements soient intégrés le plus vite possible. Ils sont à mon avis dans une course contre la montre, et oui, ils jouent salement (mais ils ont aussi des gros devs, ça compte).
Microsoft a besoin que la version Windows de PHP soit complètement cohérente avec la version Linux pour les pousser à migrer vers du cloud Microsoft, mais ils ne sont pas pressés par le marché, ce n'est pas le cœur de marché de la boîte, juste une activité avec des objectifs à très long terme et ils ont une culture du respect des processus.
Zend comme Microsoft sont les seuls à pouvoir mettre des devs à plein temps sur PHP, presque tous les fils polémiques sont en fait des affrontements d'influence entre deux stratégies commerciales qui ne sont pas sur le même calendrier et deux entreprises aux cultures de travail très différentes.
Ensuite il y a les contributeurs bénévoles dont certains sont juste des brutes et apportent des améliorations énormes au langage (Nikita Povov en particulier, mais aussi Joe Watkins ou Andrea Faulds). Ceux là sont toujours très mesurés dans leurs propos et ils ont une énorme influence sur le projet, certains sont étudiants et consacrent clairement des dizaines d'heures par semaine en dev pour PHP. Ceux là sont clairement l'avenir du projet, le fait qu'ils soient des personnes agréables, mesurées et qui ne créent pas de polémique me rend optimiste sur l'avenir de la communauté.
Est-ce que PHP 7 sortira dans un an ? J'en doute, je parie sur deux ou trois, mais je vois tout de même que déjà de gros patchs sont là (PHPNG et AST), j'ai compilé localement et dans l'ensemble ça marche bien. J'ai rapporté deux gros bugs, l'un des deux a été résolu super réactivement par Zend, l'autre est que'Atoum fait planter PHP 7 ;), j'ai fourni un backtrace la semaine dernière mais pas encore de nouvelles. Mon expérience est que les employés Zend sont réactifs et que les bénévoles participent, je vois donc une certaine collaboration entre deux des groupes de gros faiseurs autour du langage et ça c'est encourageant.
Donc oui, ils s'engueulent, oui Zend méprisent clairement les processus et se comportent comme s'ils étaient en terrain conquis, mais le langage avance avec eux en ce moment il faut le reconnaître, il ne faut juste pas compter sur eux pour le long terme car les ressources qu'ils mettent en ce moment sont opportunistes.
Microsoft, par la voix de Pierre Joye en général, a un mode de fonctionnement qui me correspond plus, plus carré, plus dans le respect des processus du libre, mais la communication ne marche pas (elle marcherait très bien si on était dans le cadre de Mozilla en fait). Elle est trop abrasive, trop défensive et trop focalisée sur les processus. PHP n'a pas de leader, pas de système de gouvernance, il fonctionne par compromis et il n'y a pas de système d'arbitrage final (en dehors des RFC) en place en cas de conflit. Dans ce contexte, on ne peut pas lutter continuellement sur des points de procédure sans passer pour le râleur de service.
2 De mageekguy - 29/08/2014, 20:33
@pascal : Le développement de 5.7/5.8/5.9 et consors devra être réalisé indépendamment de phpng, même s'il est mergé dans le master (mes infos ne sont certainement pas aussi à jour que les tiennes vu que je suis tout cela de très loin, mais je suis quand même relativement bien informé), le contraire serait de la pure inconscience vu le travail qu'il reste à faire pour le rendre digne de la production.
Alors, je n'ai pas de boule de cristal (quoique certain pense le contraire) mais il faudra à un moment ou un autre partir de 5.6 pour construire 5.7, donc plusieurs branches… ou alors, le processus de release est mis à la benne et le rythme actuel ne sera plus respecté (ce qui ne serait peut être pas un mal car je le trouve trop rapide actuellement par rapport aux contraintes de développement et de production des entreprises que je connais).
Car le plus dingue dans tous cela, c'est que la décision de merger phpng dans le master a été prise en se basant sur le fait qu'il faudrait un an pour finaliser l'intégration de phpng au sein du langage. Et estimer, c'est mentir, surtout dans ce cas ou ceux qui ont fait l'estimation sont ceux qui ont le plus d'intérêt à faire passer la RFC correspondante, aucune analyse contradictoire n'a été faite, aucun tiers n'a été consulté pour donner son avis… (au passage, internals@ serait bien inspiré d'écouter les conseils d'Olivier Sibony).
Et faire un aussi gros paris sur une estimation de ce genre, c'est carrément gonflé.
Donc s'il ne faut effectivement qu'un an, ok, je fabule. Mais dans le cas contraire ? Parce que… franchement… tu as suffisamment d'expérience dans le métier pour savoir que ce genre d'estimation est totalement foireuse 75% du temps, et je suis très gentil, tu le dis d'ailleurs toi-même puisque tu parie sur 2 ou 3 ans. Et on fait quoi pendant ces deux ou trois ans ? rien ? on reste en 5.7 ? Ou alors on continuera à faire vivre cette version sur une branche indépendante du master… ?
Et il y a aussi le problème des extensions, car phpng demandera une mise à jour de ces dernières, et si les extensions de base ont bien été migrées, il y a fort à parier que, outre la charge de travail et de test que la migration représentera sera mal vu par les développeurs concernées, ce qui veut dire que le rythme d'adoption de PHP 7 ne sera peut être pas aussi rapide qu'espéré et que la branche 5 vivra encore pas mal de temps avant de passer en EOL (car il y a pas mal d'entreprises qui utilisent des extensions soit propriétaires, soit qui ne font pas partie de la distribution de base du langage).
Enfin, phpng a beau être mergé dans le master, seul trois développeurs en ont une connaissance réellement approfondie (notamment parce que l'un d'eux l'a développé 8h / jour grâce au sponsoring de Zend). On se retrouve donc dans la même situation que PHP 6 ou seul une très petite partie des contributeurs comprenait réellement les tenants et les aboutissants de l'intégration d'unicode dans le Zend Engine.
Et à la lecture d'internals@, je doute que les remarquables capacités de communication des personnes concernées vont améliorer rapidement les choses à ce niveau, d'autant que Zend n'a pratiquement aucun intérêt à diffuser largement cette connaissance car c'est l'un des seuls moyens dont elle dispose pour garder le contrôle sur le développement du langage.
Car outre l'aspect technique, c'est bien l'aspect humain qui m'inquiète finalement le plus, surtout avec l'éclairage que tu apportes par ton commentaire, car fondamentalement, rien n'a vraiment changé.
En effet, si je suis bien d'accord avec toi sur le fait que la situation du langage est bien meilleure qu'à l'époque de PHP 6, internals@ est toujours le même asile de fou dès qu'il y a quelques choses qui ne cadrent pas avec les besoins de l'un ou l'autre des camps présents, et bon gré mal gré, ce sont ses membres qui font vivre le langage, et tant qu'une personne ou un groupe cherchera son propre avantage plutôt que l'intérêt commun, il y aura toujours un manque/problème dans son processus de développement.
Il y avait certainement moyen de faire autrement, que ce soit dans la forme ou le fond. Je trouve dommage que la communauté n'est pas choisie de sortir des sentiers battus sous la pression, pour quelques % de performance supplémentaire.
On en reparle dans trois ans, lorsque tout le monde utilisera HHVM ;).
3 De Pierre - 30/08/2014, 10:04
@Pascal
"ceux qui veulent améliorer la cohérence du langage en particulier sous Windows par rapport à Linux, c'est en réalité Microsoft qui vend de l'Azure et qui a besoin d'avoir des langages populaires dessus. Il est important pour eux que le langage soit le plus "industriel" et windows friendly possible"
Oui mais bon.
Vu que tu fais directement référence à mon équipe...
1. 90%+ de nos contributions affectent prioraitement Unix
2. 75% des fixes pour apporter la compat avec les dernières releases sous PECL et autres sont faites par nous
3. On est les seuls à tester intensivement, en continue (CI) toutes les branches, commits, releases avec les apps&frameworks majeurs
4. mes commentaires sur la list sont mes opinions personnelles et non celle de Microsoft
5. Les APIs internes contiennent encore des functions de PHP4, des inconsistences immenses existes, duplication de code, etc.
6. Clean code, usage correct des types/casts, etc. améliore letravail des compilateurs (gcc, vc, icc, etc.) et améliore la sécurité globalement
7. Azure supporte Windows et Linux/BSD, mon équipe est non seulement le 1er contributeur PHP en 2013/4 mais aussi dans le kernel
8. Et contrairement à des companies dites OSS, nous faisons tout de manière ouverte, en collabaration avec les différentes communautés.
Donc avant de partir dans des délires "la big Corp force la main", regarde un peu l'historique.
Merci.
4 De Julien Breux - 30/08/2014, 15:03
Je partage entièrement ton avis. Et je commence à me poser de sérieuses questions quant à l'avenir non-tracé de notre language préféré.