Peux-tu te présenter en quelques mots ?

Autodidacte, je m'intéresse à PHP depuis 7 ans environ, et ce exclusivement dans un cadre non professionnel.

Je me focalise principalement sur le langage et son implémentation, c'est à dire le Zend Engine et son évolution.

Je garde aussi un œil sur les frameworks et les bibliothèques que je juge représentatifs des grandes tendances en matière d'ingénierie logicielle.

Cependant, je ne suis pas passionné au point d'exercer cette activité de manière très suivie.

PHP reste un hobby parmi d'autres, et dans la vie active je travaille dans la branche Qualité de la pharmaceutique industrielle.

Que représente pour toi l'arrêt du développement de PHP6 ?

Tout d'abord, la prise de conscience que les choix techniques du support d'Unicode, tels que décidés il y a plusieurs années, ne constituent pas une solution viable.

Ensuite, une réorganisation des branches du VCS, et notamment du trunk, qui ne peut qu'être bénéfique pour la suite du développement.

C'est pourquoi je n'ai jamais considéré l'arrêt de PHP 6 comme étant la mort de PHP version 6.0.

Cela parait contradictoire, mais les décisions prises n'ont pas d'autres buts que de remettre les choses sur pied.

Certes, la fonctionnalité emblématique, unicode, est reportée faute de mieux.

On sait dorénavant que la solution initiale n'est plus envisageable.

En conséquence, quelles sont tes attentes vis à vis de la prochaine version ?

La remise à plat du développement a produit ses premiers effets.

Beaucoup de RFC et de patchs très intéressants qui gravitaient autour du projet, pour certains depuis des lustres, sont de nouveau considérés.

C'est un point essentiel car cela montre que l'engouement pour la prochaine version est bien présent.

Cette prochaine version ne sera d'ailleurs pas forcément PHP 6, il pourrait s'agir de PHP 5.4.

PHP 5.3 a innové dans la mesure où une version mineure a vu l'introduction de fonctionnalités majeures tels que les espaces de nommage ou les fonctions anonymes.

La version 5.3 a donc été en quelque sorte une anomalie.

Or, ce qui était anormal n'était-il pas plutôt un bridage contraint par le statut très particulier de PHP 6 ?

J'attends de la prochaine version qu'elle continue sur cette lancée et soit un juste reflet des efforts fournis.

Dès l'instant où une nouveauté fait consensus et qu'elle ne pose plus de problèmes techniques, pourquoi ne pas l'intégrer officiellement ?

L'introduction de FPM dans PHP 5.3.3 abonde dans ce sens.

Par rapport à ce qui est en incubation actuellement, je pourrai citer les traits, le support objet des fonctions anonymes ou le runtime cache qui concerne le modèle objet.

Penses-tu que la communauté des contributeurs a tiré les leçons de PHP 6 ?
En partie, oui.

L'environnement est maintenant plus sain.

Les nouveautés peuvent être introduites sur une base bien connue qui est celle de la branche 5.3.

Cela ne veut pas dire pour autant que ce qui est ajouté sera conservé de facto, l'essentiel est que l'ancien code base de PHP 6 ne constitue plus un frein pour juger de ce qui est fonctionnellement pertinent.

En ce qui concerne Unicode, les causes de l'échec ont été diagnostiquées et parmi celles-ci un manque de communication et de documentation.

Parmi les contributeurs, auxquels il faut inclure les auteurs d'extensions, seule une poignée étaient au courant des enjeux et des contraintes qui en découlent.

La communauté est maintenant consciente qu'une traçabilité et un meilleur suivi sont nécessaires.

L'échec de PHP6 révèle aussi un sérieux problème au niveau de l'architecture même de PHP.

Le couplage entre les extensions (standards et tierces), les SAPI et le Zend Engine est trop fort, de trop bas niveau.

De petites modifications peuvent avoir des répercussions généralisées à tous les niveaux.

Se prémunir d'un nouvel échec à la PHP 6 demanderait une refonte complète de l'architecture.

Autant dire que la tâche n'est pas facile et elle n'est pas, à ce que je sache, planifiée.

Quelques documents exposent cependant le problème, notamment Removal of the Zend API.

On entend beaucoup parler de la professionnalisation de PHP actuellement, quel est ton avis sur le sujet ?

Ce qui est en vogue actuellement serait plutôt une industrialisation de PHP.

PHP est utilisé professionnellement depuis plusieurs années, et je suis parfois étonné de constater que cette question d'industrialisation ne semble faire surface que maintenant.

Comment faisaient-ils avant ? Du copier/coller dans un FTP ?

Étant amateur, mon point de vue est externe par nature et je reconnais que ma position est confortable, puisque je ne suis pas directement concerné.

A mon sens, il s'agit essentiellement d'une question de pratiques et de méthodologies.

Le langage et les outils ne viennent qu'en second temps.

L'industrialisation de PHP, ou toute autre technologie, passe par une plus grande ouverture au monde du logiciel en général.

Ces problématiques ont déjà été rencontrées ailleurs.

Il faut donc appliquer ce qui fonctionne et a fait ses preuves.

En amont, la formation m’apparaît comme essentielle.

Il ne s'agit plus de débarquer sur le web sans aucun bagage.

Le développement de prochaine version va-t-il dans le sens de cette professionnalisation ?

Oui, car des bugs sont sans cesse corrigés et des améliorations régulièrement apportées.

Quoi de plus banal ? Cela n'en reste pas moins essentiel !

Oui aussi car la tendance est à une accélération des dépréciations et retraits des fonctionnalités obsolètes ou jugées problématiques, souvent pour des questions de sécurité.

En revanche, les partisans d'un nettoyage complet seront déçus.

Son manque d'homogénéité est fréquemment pointé du doigt.

Personnellement, je comprends la position conservatrice du PHP Group qui tend à refuser les changements non rétrocompatibles, à fortiori quand il ne s'agit que de changements cosmétiques.

Je pense par exemple aux fonctions str* ou array*.

Assurer tant que possible la rétrocompatibilité est d'après moi une démarche professionnelle.

De plus, l'introduction de ce que je pourrai appeler des raccourcis syntaxiques n'est plus aussi taboue qu'avant.

On peut citer le déréférençage automatique des tableaux en retour de fonctions ou des plus grandes facilités pour chaîner les appels de fonctions.

Ce sont des améliorations au niveau du langage que je considère essentielles.

De une, cela réduit l'écart par rapport à nombre de langages concurrents et le comportement de PHP est tout simplement plus naturel et professionnel.

De deux, les utilisateurs du langage sont prompts à tirer partie de ces améliorations et cela peut déboucher sur de nouveaux concepts et au final une meilleure productivité.

L'arrivée de DTrace ou APC en tant qu'extension standard va dans le sens d'une plus grande professionnalisation.

Mais celle-ci ne saurait être satisfaisante sans un meilleur support d'Unicode.

Ce n'est pas ironique, c'est problématique !

Au vu de tes réponses précédentes, est-il possible de dire que tu crois en l'avenir du langage ?

PHP est très répandu, son avenir est de ce fait assuré à moyen terme.

Cependant, les technologies évoluent vite, les applications se complexifient c'est pourquoi il me parait essentiel de ne pas s'enfermer dans PHP afin de pouvoir choisir la bonne technologie pour le bon travail.

PHP doit cultiver ce qu'il sait bien faire : un bon interfaçage avec les différents OS, serveurs et protocoles et son modèle de perfect sandbox de requête en requête.

Bref, il doit rester pragmatique d'autant que les langages qui savent intégrer des éléments empruntés à la programmation fonctionnelle, comme Javascript, Scala ou bien Clojure, ont le vent en poupe, et PHP ne pourra pas rivaliser sur ce terrain.

Je pense qu'à terme ce sera son plus gros défaut.