Peux-tu te présenter en quelques mots ?

J'ai commencé à faire du web en 1995 (avec le navigateur Mosaic puis Netscape Navigator !) et je fais du PHP depuis plus de 10 ans.

Parallèlement à cela, j'ai co-fondé en 2003 openweb, le site pour la promotion des standards, et je travaille depuis la même période avec les technologies Mozilla (XPCOM, XUL...) pour réaliser des applications desktop et des extensions pour Firefox en tout genre.

Je contribue d'ailleurs modestement au développement de Firefox.

Pour en revenir au PHP, j'ai été core-developer sur le framework Copix à partir de 2001, et j'ai créé un autre framework en 2006, Jelix, qui est maintenant utilisé par pas mal de monde, y compris par des gros sites à très forte audience, bien que sa popularité soit loin d'atteindre celle de Symfony ou de Zend Framework.

Et puis, j'ai quelques connaissances sur le fonctionnement interne de PHP, puisque le développement d'une extension n'est pas un secret pour moi.

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

C'est probablement le signe d'un changement de la direction des développements, vers des améliorations permettant d'avoir du code plus propre, plus professionnel à l'avenir.

On verra.

C'est surtout la fin d'un vaporware, et que l'on va peut-être avoir plus de choses concrètes à l'avenir.

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

J'espère qu'ils vont vite intégrer une solution pour la gestion native des chaînes de caractères en Unicode (et pas seulement obliger à utiliser des fonctions spécifiques comme les mbstring), parce que ça commence à devenir lourd de contourner les bugs de beaucoup de fonctions sur les chaînes de caractères encodées en UTF-8.

Par exemple, le dernier hack en date dans Jelix fut de faire du bon code crado pour contourner le bug de number_format(), car cette fonction ne sait pas utiliser un séparateur encodé en UTF-8, donc sur plusieurs octets.

Je souhaite aussi qu'ils planchent à nouveau sur un PHP 6, dans lequel ils auraient le courage de faire un grand nettoyage dans les incohérences des API dont tu as déjà parlé et que tout le monde connaît, avec également plus de paradigmes objets et fonctionnels.

Penses-tu que la communauté des contributeurs a tiré les leçons de PHP 6 ?

Je ne sais pas car je ne suis plus vraiment ce qui se dit sur les listes de diffusion, je n'ai pas trop le temps pour ça en ce moment.

L'avenir nous le dira.

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

C'est vrai que le langage en lui même a progressé, avec les fermetures et d'autres choses.

Depuis ces dernières années, les frameworks ont aidé à avoir des développements plus propres, cachant en grande partie, il faut le dire, la misère, et il est indéniable que cela a contribué à crédibiliser à la technologie.

Cependant, il y a encore du chemin à faire au niveau des API.

Il y a les histoires des incohérences dans le nommage et les arguments, mais surtout et aussi le manque de fonctionnalités de base par défaut.

Vous vous rendez compte qu'il n'y a même pas, nativement, une classe pour envoyer un courrier électronique, avec toutes les fonctionnalités qu'on en attend comme pouvoir ajouter facilement des en-têtes ou des pièces jointes ?

PHP a 15 ans, et on en est encore à devoir intégrer des classes externes plus ou moins lourdes pour pouvoir envoyer des courriers électroniques décemment, pour éviter d'avoir à apprendre par cœur les RFC relatif à SMTP afin de forger correctement une chaîne de caractères pour cette pauvre fonction mail().

Je pourrais citer aussi le cas de DateTime.

Pour avoir une API décente de manipulation des dates, il a fallu attendre PHP 5.3, et c'est effarant quand on y pense.

J'attends toujours aussi plein d'autres choses, comme une API pour faire du HTTP pour appeler des services web.

Je ne sais pas si des concepts comme REST et les services web parlent au PHP Group.

Je pourrais certes utiliser l'extension HTTP de PECL, mais elle ne sera que sur mon serveur, et mon application aura toutes les chances de ne pas fonctionner ailleurs.

Et voilà donc un autre problème de PHP : d'un serveur à un autre, on n'est pas sûr d'avoir les mêmes API activées, pour une même version du langage.

C'est juste ridicule, et il faudrait vraiment qu'ils suppriment bon nombre des options de compilation conditionnels.

Car avec ce système, les frameworks doivent imposer un certain nombre d'extensions PHP installées, mais ce nombre est, par nature, pas très important si on veut pouvoir utiliser le framework un peu partout.

Les concepteurs de frameworks sont donc obligés de faire une surcouche à certaines API pour contourner ce problème et proposer quelque chose de plus propre et plus professionnel.

Ils sont condamnés à implémenter des fonctionnalités manquantes qui sont indispensables.

Bref, il y a probablement plus de 50% de code dans un framework qui ne devrait pas exister, et je ne trouve pas cela professionnel.

Toutes ces fonctionnalités devraient exister nativement dans API, afin d'éviter d'une part de réinventer la roue à chaque fois et avoir une API standard comme il en existe dans d'autres langages, et d'autre part pour améliorer les performances, en évitant d'aller lire 150 fichiers à chaque requête.

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

J'attends tes billets sur les futures avancées pour me faire vraiment une idée :).

Je pense toutefois que PHP ira vraiment dans le sens de la professionnalisation, quand les développeurs du langage eux-même seront un peu plus professionnel dans l'organisation même du développement.

Peut être que je me trompe, mais du bout de ma lorgnette, de ce que j'en vois, ce qu'ils font ne me parait pas très professionnel ni très efficace.

Le projet est devenu très important d'un point de vue de la popularité, mais le reste n'a pas vraiment suivi.

Nous ne sommes plus en 1998.

Les outils doivent donc évoluer en conséquence, ainsi que l'organisation du développement, et cela faciliterait au passage l'arrivée de nouveaux contributeurs.

Quand je vais sur le bug tracker de PHP, j'ai l'impression de retourner 10 ans en arrière.

Et encore, il y a 10 ans, même Bugzilla était mieux.

Moi qui contribue à Mozilla, c'est le jour et la nuit quand je compare les deux projets.

Il faudrait vraiment qu'ils utilisent un vrai outils comme Bugzilla ou Redmine.

Et il faudrait vraiment qu'ils passent à Git ou Mercurial, car Svn n'est vraiment plus adapté pour des projets open-source digne de ce nom.

Ce serait bien aussi qu'ils changent le processus de contribution.

Dans le cadre de Mozilla, quand vous voulez savoir quelque chose par rapport à un bug, vous allez sur le ticket correspondant et vous avez tout : les discussions techniques, les patchs, pourquoi telle ou telle solution a été choisi, qui a fait le patch, qui l'a vérifié, qui l'a validé, sur quelle branche, avec les liens vers les changesets etc.

Et chaque patch est revu par deux développeurs différents avant son intégration dans le code source, ce qui est le gage d'une certaine qualité et une certaine constance du code.

Dans le cadre de PHP, tout est éparpillé dans les listes de diffusion ou ailleurs.

Pour trouver une information sur un bug, c'est la croix et la bannière.

Le bug tracker ne sert finalement pas à grand chose, sauf à dire que c'est corrigé ou pas.

Et ça, quand on ne s'est pas fait dire d'aller voir ailleurs, parce qu'on a osé proposer une amélioration intéressante ou un bug important, mais que les quelques gourous PHP sont de l'avis contraire.

Et là j'en viens à un autre aspect de l'organisation : je trouve qu'ils ne respectent pas toujours ceux qui veulent aider, et que les relations sont plutôt froides et hautaines.

En tout cas, c'est le ressenti que j'ai eu en lisant certains rapports de bugs, et ça m'a refroidi.

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

Oui et non.

Oui parce que PHP est tellement répandu qu'il restera encore je pense le langage web coté serveur le plus utilisé, et qu'il y a quand même maintenant un gros marché autour de PHP.

Mais non si le PHP group ne se remet pas en question, d'un point de vue organisationnel d'une part, et d'un point de vue technique d'autre part.

Python et Ruby commencent vraiment à avoir la cote, à grignoter des parts de marché et le coté professionnel des APIs et la modernité des éléments de ces langages font ressortir tout les mauvais cotés de PHP, mauvais cotés qu'on essayait autrefois d'ignorer ou de contourner.

Mais un développement sérieux de nos jours ne se fait plus à coup de hack toutes les 10 lignes de code.

Il n'est pas étonnant alors de voir des développeurs migrer vers Python, par exemple, une fois qu'ils y ont gouté.

D'ailleurs, Mozilla est en train d'abandonner complètement PHP pour ses sites web, en les réécrivant tous en Python, avec Django comme framework, si je ne me trompe pas, même si pour être honnête, PHP n'est pas non plus la seule raison de ce chantier, puisqu'il y a aussi une question d'homogénéité de l'infrastructure et d'autres problématiques qui rentre en ligne de compte.

Bref, il va falloir que le PHP Group fasse de gros effort à l'avenir, si il ne veut pas voir PHP devenir un langage de seconde zone.

Restons toutefois optimiste : J'ai été très critique, mais qui aime bien châtie bien comme on dit.

PHP a beaucoup d'autres atouts, comme sa facilité d'apprentissage, ses performances, sa facilité de déploiement, qui font que des gens, dont moi, utilisent PHP, et nous avons de beaux frameworks à disposition pour être productif.

Au fait, je vous ai dit que j'ai goûté à Python ?