Je ne vois donc aucune raison pour que les contributeurs d’atoum fassent l’effort nécessaire pour rendre atoum compatible avec HipHopVM.
Et d’autant plus que HipHopVM est actuellement à mes yeux un outil certes intéressant, mais encore complètement inadapté à des développements en environnement professionnel ou utilisable en production.
Sa compatibilité avec le Zend Engine n’est en effet pas totale, et ses développeurs sont encore en pleine phase de recherche et développement pour y remédier.
Il n’y a d’ailleurs qu’à lire leur blog, par ailleurs très intéressant, pour s’en convaincre.
De plus, le fait de supporter HipHopVM dans son état actuel est à mon sens une très mauvaise stratégie pour obtenir à plus ou moins moyen terme une alternative au Zend Engine digne de la production.
En effet, elle favoriserait l’émergence d’un nouveau langage qui aurait la couleur du PHP, l’odeur du PHP, mais qui ne serait pas du PHP puisque la compatibilité du code que pourra exécuter HipHopVM ne sera pas garantie avec le Zend Engine, et non celle d’une alternative crédible et surtout fiable à ce dernier.
PHP se retrouvera alors dans la même situation que Java, avec du code qui ne sera pas forcément exécutable sur la totalité des machines virtuelles disponibles (ceux qui ont essayé de faire tourner du code Java sous OpenJDK et HotSpot comprendront sans problème ce que je veux dire).
L’utilisation du code et l’administration de son environnement d’exécution deviendront alors beaucoup plus complexes qu’actuellement, et cela alors que paradoxalement, beaucoup d’efforts ont été faits ces dernières années avec le développement d’un outil tel que composer et divers travaux périphériques pour justement simplifier l’installation et le déploiement du code.
Dans le pire des cas, cela pourrait même aboutir à une scission du marché.
Donc, en résumé, si des développeurs PHP font les efforts nécessaires pour rendre leur code compatible avec HipHopVM, ils se tirent une balle dans le pied.
Alors que forcer (entre guillemets) les développeurs de HipHopVM à faire les corrections nécessaires dans leur code pour rendre ce dernier compatible à 100 % avec le Zend Engine permettra de mettre ces deux machines virtuelles en concurrence, à la fois au niveau des performances et au niveau des fonctionnalités.
En effet, si HipHopVM est totalement compatible avec le Zend Engine, mais qu’il offre de meilleures performances ou des fonctionnalités supplémentaires, par exemple (totalement au pif) le support d’Unicode, les développeurs du Zend Engine seront forcés de suivre le mouvement s’ils ne veulent pas voir leur bébé progressivement abandonné au profit de HipHopVM.
Ils seront alors obligés soit d’implémenter les fonctionnalités manquantes ou bien d’améliorer les performances du Zend Engine, l’un n’excluant pas l’autre évidemment.
Et pour la même raison, toute évolution fonctionnelle du Zend Engine devra forcément être répercutée au niveau de HipHopVM.
Cela aura aussi comme effet de bord intéressant d'obliger les développeurs actuels de PHP à décrire le fonctionnement du langage, afin que tout le monde puisse à la fois suivre son évolution et éventuellement développer sa propre machine virtuelle en étant certain qu'elle est à 100% compatible avec l'ensemble du code existant.
Les utilisateurs de PHP ont donc bien tout à gagner à tout faire pour disposer d’une alternative au Zend Engine qui soit totalement compatible avec ce dernier et comme je viens de l’expliquer, je pense que cela ne passe en aucun cas par une modification de leur code pour le rendre compatible avec HipHopVM.
En conséquence, le code d’atoum ne sera pas modifié pour le rendre compatible.
Cependant, cela ne veut pas dire que les développeurs d’atoum ne fourniront pas à ceux de HipHopVM toutes les informations à leur disposition afin qu’ils parviennent à rendre leur création à 100 % compatible avec le Zend Engine, car cela ne pourra qu’être bénéfique à la communauté des utilisateurs de PHP.
Et c’est la raison pour laquelle le rasta blanc y travaille !
6 réactions
1 De Olivier - 11/01/2014, 22:03
Bien d'accord !
On s'autorise à penser dans les milieux autorisés que HHVM sera très bientôt full compatible - je prend les paris
2 De Kenny - 13/01/2014, 10:43
Je comprend les raisons (et merci pour ce post très complet), mais cela m'embête quand même un peu.
La première étape pour que l'on puisse commencer a passer certains projet isolés ayant des grosses problématique de charge sur HHVM, est de faire passer les tests.
Hors, nos tests utilisant tous Atoum, ne peuvent pas passer, HHVM ne réussissant pas encore à lancer Atoum, et du coup, nous sommes bloqués avant même de pouvoir tester/bencher/comparer les perfs et la stabilité de nos projets entre du Php classique et HHVM. Du coup, c'est quand même pour nous Atoum qui est un frein dans notre R&D sur HHVM ...
Malgré cela, votre volonté de remonté les bugs rencontrés à HHVM, et grace au fameux rasta blanc, va je l'espère, être très profitable à HHVM, et aboutir à un support rapide des fonctionnalités manquante du Zend Engine pour faire tourner Atoum
Bref, on continue de suivre le sujet, et on a hâte de pouvoir tester nos projets sur HHVM via Atoum !
3 De Adirelle - 13/01/2014, 11:02
"ceux qui ont essayé de faire tourner du code Java sous OpenJDK et HotSpot comprendront sans problème ce que je veux dire"
Ce qui est rigolo, c'est qu'OpenJDK 7 est l'implémentation de référence pour Java 7 : https://blogs.oracle.com/henrik/ent...
4 De mageekguy - 13/01/2014, 13:39
@Kenny :
En quoi ?
Visiblement, atoum fait parti intégrante de votre cycle de production, donc si HHVM n'est pas capable de le faire tourner correctement, c'est qu'il n'est pas prêt à faire tourner votre code.
C'est un indicateur comme un autre concernant le fait que HHVM est prêt ou non pour la production.
Et en toute franchise, je trouve très prématuré de faire de la R&D pour une éventuelle migration vers HHVM à son stade de développement, sans parler du fait qu'à ma connaissance, Facebook n'a pas communiqué sur la façon dont elle comptait en assurer le support, aussi bien à court qu'à moyen ou long terme (oui, je sais, c'est de l'open-source, mais il n'empêche que les développeurs capable de réaliser ce genre de développement correctement ne court pas les rues, d'autant qu'il faut également une bonne connaissance du Zend Engine).
5 De Kenny - 14/01/2014, 08:39
@mageekguy : L'application peut très bien fonctionner sur HHVM alors que Atoum plante au lancement des tests.
Bon ca ce mord la queue, mais au final c'est un peu ca.
Rien ne dit que nos applications fonctionneraient sur HHVM, mais les tests ne se lançant pas, nous sommes bloqués à ce stade. Et comme tu le dis, nos tests ne fonctionnant pas, ca ne sert à rien pour nous d'aller plus loin.
Pour le coté prématuré concernant la R&D sur HHVM, je ne suis pas d'accord.
HHVM peut nous apporter énormément de choses, même sans aller jusqu'a mettre un projet en production.
Nous l'utilisons depuis quelques jours par exemple pour Composer sur nos environnements de développement (et gagnons un temps très précieux). cela peut être utile pour pas mal d'outils backend ou cron job aussi.
D'autres projets en prod, sont moins critique, et nous permettrait aussi de bencher dans des conditions réelles, la tenue en charge et la stabilité de HHVM, et de la comparer avec le code actuel.
Mon rôle, et c'est le rôle de la R&D d'un point de vue général, c'est aussi d'anticiper les tendances, et faire de la veille active, sur ce qui peux nous aider dans notre travail quotidien, d'un point de vue efficacité, performances ou même coût.
Et dans tout ces critères, HHVM (tout comme Node les années précédentes) est l'un de nos très gros points d'attention sur 2014.
Mais tout ca n'engage que moi, et est aussi surement propre à notre contexte chez M6Web
6 De mageekguy - 14/01/2014, 10:08
@Kenny : C'est juste que faire de la R&D sur un outil qui est lui même encore en phase de R&D, même s'il apporte déjà des choses intéressantes, me semble très prématuré.
Après, chacun voit midi à sa porte et comme en plus j'ai un fort à priori par rapport à Facebook…