- 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 denumber_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 ?
L'avenir de PHP vu par Laurent Jouanneau
jeudi 26 août 2010. Lien permanent PHP X
C'est maintenant au tour de Laurent Jouanneau de nous faire partager sa vision de l'avenir de PHP, avant que cette série d'interview soit cloturée par celle d'Éric Daspet.
Je connais Laurent virtuellement depuis maintenant plus de cinq ans.
J'ai fais sa connaissance via openweb, et nous avons discuté par blog interposé pendant longtemps, notamment au sujet de PHP et de ses bugs, avant de nous rencontrer physiquement lors d'un forum PHP.
Depuis, nous gardons le contact et nous discutons ensemble régulièrement, notamment sur le canal IRC de Jelix.
Fil des commentaires de ce billet
Ajouter un rétrolien
URL de rétrolien : http://blog.mageekbox.net/?trackback/177
9 réactions
1 De Jérémy Lecour - 27/08/2010, 10:08
Belle analyse de l'état et de l'avenir du PHP.
J'ai moi même "quitté" PHP il y a quelques années lorsque j'ai découvert Ruby. J'aurais probablement trouvé de très bonnes choses dans Python, mais j'aime mieux le feeling Ruby.
J'avais proposé ma petite analyse des différences intrinsèques de PHP et Symfony par rapport à Ruby et Rails lors d'un choix interne dans ma boîte.
http://jeremy.wordpress.com/2009/11...
2 De Moi - 30/08/2010, 09:39
Bonjour,
J'ai une question si l'interviewé passe dans le coin.
En quoi SVN n'est plus adapté pour un projet digne de ce nom ?
Sinon je suis tout à fait d'accord sur les failblesses de PHP mais c'est dommage de ne traiter que cet aspect négatif alors que PHP a aussi beaucoup de qualités qu'un développeur de framework ne doit pas ignorer (je mets de côté le dernier paragraphe qui ne fait pas directement mention de PHP mais plutôt de son environnement).
3 De Nicolas Laforêt - 30/08/2010, 11:46
Bonjour,
Il faudrait envoyer cette interview ainsi que d'autres sur internals pour voir les réactions et voir si les choses ont vraiment changées, car en attendant, on se pose pas mal de questions sur la suite des évènements et ce que les "têtes-pensantes" veulent vraiment pour PHP et son avenir.
4 De mageekguy - 30/08/2010, 12:53
@Nicolas Laforêt : Certain membres de @internals suivent ce blog.
5 De Laurentj - 30/08/2010, 13:25
Je parle des projets communautaires. Quand on participe activement à un projet comme ceci, Mercurial/Git, de par leur nature décentralisés, facilitent beaucoup les choses. Commit en local, création de branches personnalisées en local, merge bien plus puissant etc... Ce sont des outils qui permettent de proposer et gérer des séries de patchs beaucoup plus facilement. Il n'y a qu'à voir le succès auprès des développeurs, de sites comme github et bitbucket.
Pour moi SVN garde un intérêt seulement dans un projet centralisé, contrôlé, interne, avec une petite équipe. Et encore. Je ne dis pas que SVN ne permet pas de travailler sur des gros projets open source avec des grosses équipes. Mais il est maintenant dépassé sur ce secteur là. D'ailleurs, beaucoup de projets open source ont switché (python, mozilla, kde, open office, symfony, jelix, ror...)
PHP a des aspects positifs, j'en ai cité quelques un. Mais pas sûr qu'ils suffisent, à long terme, à maintenir PHP en haut de l'affiche. Et l'interview parle bien de l'avenir.
Ensuite, en tant que développeur de framework, je n'ignore absolument pas les qualités de PHP, sinon y aurait longtemps que j'aurais arrêté de participer au développement de Jelix.
6 De Nicolas Laforêt - 30/08/2010, 14:19
A dire vrai, je pensais plus a une ligne directrice officielle sur le futur de PHP.
Histoire de fédérer les contributeurs actuels, futurs et les utilisateurs, autour des évolutions fonctionnelles et optimisations.
Tes différentes interviews me donnent l'impression qu'il manque une ligne directrice au futur de PHP.
7 De mageekguy - 30/08/2010, 14:39
@Nicolas Laforêt : Ce n'est pas une impression, c'est une réalité, et elle est loin d'être nouvelle.
Et malheureusement, cela ne semble pas prêt de changer vu qu'il existe deux camps opposés sur ce sujet au sein de la communauté de contributeurs.
L'un prône une certaine "professionnalisation" du développement du langage, avec une roadmap précise, des outils plus adaptés, une formalisation plus poussée, et l'autre veut continuer à travailler comme actuellement, c'est à dire dans le
le plus complet, même si cela s'améliore grâce au travail de fond de Lukas Smith sur le sujet, avec par exemple la mise en place des RFC.8 De Nico - 11/09/2010, 17:00
Concernant le passage des API et extensions à installer en option, je ne trouve pas ridicule de vouloir éviter de surcharger bêtement un serveur.
C'est bien normal de faire ça, sinon PHP serait un gouffre au niveau des performances comme Java ou d'autres.,
Et puis-ce qu'on parle de
, les n'auront aucun mal à activer les extensions nécessaires au fonctionnement de Jelix (ou autre) et ainsi éviter de bouffer des perf dans une grosse API qui ne serait que partiellement utilisée.Si l'on veut que tous les langages aient le même fonctionnement, à quoi çela sert d'avoir plusieurs langages ?
Pour une grosse API bien fournit et bien gourmande il faut voir du côté de Java et d'autres langages.
Si PHP devient un langage trop magique (avec classe intégrée pour envoyé un e-mail avec pièce jointe, etc), dans le futur, il faudra utiliser une vieille version de PHP pour viser les performances.
[EDIT] JNico, j'ai édité ton message, car le fond était intéressant, mais la forme...
9 De Laurentj - 14/09/2010, 16:46
@nico : il n'est pas toujours évident d'activer des extensions sur un serveur "professionnel". À mon avis tu imagines mal le coté bureaucratique de certaines boites où pour changer un truc sur un serveur, il faut fournir des demandes en 3 exemplaires, qui doivent transiter par x niveau de hierarchie. j'exagère à peine.
Et puis quand tu veux fournir une appli web qui puisse fonctionner partout, c'est un cauchemar. Il n'y a pas que les "pros", il y a ceux aussi qui veulent des applis cms ou autre qui s'installent sur leur serveur mutualisé. Et les développeurs de ces applis en bavent encore plus que les autres.
Ensuite pour les performances ce genre de choses, ça se rêgle. Le lazy loading, ça existe, même pour des bibliothèques binaires (y abien l'autoload en php non ?). Et ce n'est certainement pas le volume des bibliothèques standards de language comme java qui gène au niveau performance. Il y a bien d'autres paramètres qui rentrent en ligne de compte. Dire ça est méconnaitre la manière dont une appli web tourne avec ces langages. En java ou python par exemple, une fois l'appli chargée en mémoire, elle y reste, et les bibliothèques utilisées par l'appli aussi. Contrairement à PHP où le code source est rechargé, réinterpreté à chaque requete HTTP. Les systèmes de cache à la APC ne sont que du platre sur une jambe de bois.
Bref, avoir une bibliothèque standard très fournie, ne veut absolument pas dire bloatware, surtout si le langage et son runtime sont conçus en adéquation. Ne pas avoir en standard des classes utilitaires de bas niveau comme pour faire du HTTP ou du mail, c'est juste ridicule, en regard des besoins actuels (et passés) des développeurs.