- Peux-tu te (re) présenter en quelques mots ?
-
Je m’appelle Ivan Enderlin et je suis doctorant au DISC et à l’INRIA.
Le domaine de ma thèse tourne autour de la génération de tests.
Je suis également le créateur et l’un des contributeurs de Hoa, un ensemble de bibliothèques PHP.
Je suis passé par Mozilla, un peu le W3C, bref, je me définis plutôt comme un
hacker
(un bidouilleur), car j’aime toucher à tout. - Que penses-tu de l’évolution de PHP depuis l’abandon du développement de PHP 6 ?
-
Impressionnante, car les releases sont nettement plus rapprochées, la qualité s’est améliorée, il y a plus de nouveautés, plus de nettoyage et ça bouge dans le bon sens !
Je pense aux fonctions anonymes, aux traits, à certains sucres syntaxiques, aux générateurs et à pleins d’autres choses…
- Avec le recul, penses-tu que la communauté des contributeurs a tiré toutes les leçons des erreurs commises avec PHP 6 ?
-
La question porte sur la communauté des contributeurs mais ce n’est pas elle le problème, c’est uniquement certains contributeurs.
Mais comme dans toutes communautés, il faut faire avec tout le monde.
PHP 6 était un symptôme de l’organisation interne de PHP et il fallait que ça ne marche pas.
PHP s’est retrouvé propulsé sur le podium des langages les plus utilisés au monde, et un grand pouvoir implique de grandes responsabilités.
Mais avec le pouvoir viennent les angoisses et les inquiétudes.
Personne ne réagit de la même manière à ce genre de situations et l’écart entre les développeurs et les utilisateurs s’est creusé de plus en plus.
Des reproches ou des demandes ont été faits, et plusieurs, pour se défendre, se mirent à camper sur leurs positions.
Que ce soit justifié ou non, ce n’était pas la bonne attitude à adopter, car PHP 6 était un projet trop important.
Son échec était donc obligatoire pour qu’il y ait une prise de conscience générale.
Aujourd’hui, l’écart entre ces deux mondes diminue énormément et PHP s’ouvre clairement à de nouvelles contributions : passage à Git, miroirs sur Github, intégrations des PR de Github dans le workflow de PHP, etc.
Et ça porte ces fruits : de nouveaux contributeurs apportent un vent de fraicheur bienvenu et tout ceci n’est plus chaotique, monolithique, entre copains.
Le système de RFC avec votes permet d’ouvrir des débats, et nettement moins sur des choses stériles, il y a une base claire et « standardisée » sur laquelle discuter.
Une très grande force de PHP est sa documentation, mais elle est destinée aux utilisateurs du langage et non à ses développeurs.
Ce n’est que récemment que nous voyons apparaître des livres sur le fonctionnement interne de PHP.
C’est une excellente chose, car ça facilite encore plus les contributions et la naissance de nouvelles idées.
Donc oui, je trouve remarquable la façon dont PHP a su se remettre en cause et évoluer, et ce n’est pas terminé.
- PHP évolue aujourd’hui beaucoup plus vite que par le passé, penses-tu que ce soit une bonne chose ?
-
Oui et non, ça dépend la casquette que l’on a sur la tête.
D’un point de vue utilisateur ou développeur, c’est beaucoup plus stimulant.
Quand on construit des outils sur PHP, les nouvelles fonctionnalités font saliver.
Les cycles courts évitent de replonger dans le casse-tête de PHP 6 avec trop de fonctionnalités ou des fonctionnalités trop importantes puisque les choses sont découpées et livrées plus tôt.
Toutefois, si nous nous plaçons du point de vue d’un administrateur système, c’est plus compliqué, car plus de versions impliquent plus de maintenances et des difficultés à conserver une compatibilité.
De plus, PHP, du fait qu’il soit un langage « glue » permettant de faire à peu près tout et n’importe quoi très rapidement, subît des effets de modes.
La communauté de PHP est très active, voire trop et le moindre outil faisant un peu le buzz peut être utilisé par la majorité de la communauté en quelques mois.
Ça a du bon, et du moins bon.
Composer, par exemple, a eu un impact sans précédent sur PHP car La communauté avait besoin d’un tel outil : plus de projets de qualité, plus de versions de PHP à manipuler, il fallait pouvoir gérer tout ça.
Mais Composer est loin d’être parfait et son utilisation massive le cloître et l’oblige à suivre un chemin qu’il ne devrait ou ne voulait pas suivre.
Même si les choses vont vite, il est nécessaire de prendre son temps et de réfléchir.
C’est le dessin du côté obscur de PHP, mais l’autre côté est nettement plus important.
PHP va plus vite et sa communauté le suit, elle est très active comme nous l’avons dit.
C’est une chance énorme car elle essaye tout, donne des retours sur tout, contribue à tout.
Il n’est pas difficile de trouver des utilisateurs et même des contributeurs et il y a beaucoup de conférences à travers le monde, des associations motivées, des bénévoles… beaucoup d’énergie !
Comparé à d’autres communautés ou langages, il est plus facile d’expérimenter et construire des choses.
- De nouveaux langages comme Go, Dart, Node.js, Scala ou Clojure sont venus s’ajouter à la liste des concurrents de PHP au côté de Ruby et python et ils semblent avoir un gros potentiel. En conséquence, penses-tu que PHP soit encore un bon choix actuellement pour commencer un projet ?
-
J’ai démarré des projets utilisant ces langages, mais ils sont tous expérimentaux.
Aujourd’hui, mon regard est tourné vers Rust, que je trouve, pour le coup, réellement intéressant.
Il ne veut pas bouleverser les choses, mais les améliorer en utilisant un état de l’art plus important, sur la sécurité, la sûreté, les performances, les bonnes pratiques, etc.
Node.js est intéressant, mais il faut lui donner le temps de murir.
Tout comme celle de PHP, la communauté JavaScript est très active, et il faut lui laisser le temps de s’organiser, même si elle le fait très vite.
Personnellement, je ne crois pas en Dart ou Go.
Certes, les concepts sont intéressants, mais ce ne sont que des concepts et ce n’est pas assez pour faire un langage.
Malgré tout, ce sont typiquement ce genre de langages et d’expérimentations qui s’ajoutent à l’état de l’art et qui auront un impact à plus long terme.
Enfin, je ne connais pas assez bien Scala et Clojure pour émettre une critique, même si les concepts (pour ne pas parler de théories) qu’ils utilisent n’ont rien de nouveau, et c’est pourquoi je ne m’y suis pas penché.
- Quelles ont été pour toi les évolutions les plus significatives dans l’univers de PHP depuis 2010 ?
-
Les closures probablement car elles ont permis l’utilisation plus importante d’un nouveau paradigme dans PHP : les événements et les écouteurs.
Les générateurs ou les traits sont plus des évolutions qui touchent les performances, mais pas les usages.
En revanche, depuis 2010, grâce à un rythme plus soutenu et une remise en question, PHP voit apparaître des outils sur la qualité logiciel : des frameworks de tests, des plateformes d’intégration continue, ce genre de chose.
Il est souvent reproché à PHP d’être un langage bâtard, capable uniquement de produire du code sale et illisible.
Ces dernières années ont prouvé le contraire, grâce à des outils du genre, construits par une communauté dynamique, elle-même entraînée par le renouveau de PHP.
- De quoi aurais-tu besoin aujourd’hui dans PHP dont tu ne disposes pas ?
-
Je n’ai surtout pas besoin des threads, mais énormément de l’asynchrone.
Ça permettrait d’introduire des théories comme la programmation réactive, la programmation événementielle (la vraie), etc.
Mais il faut que ce soit très bien fait car PHP doit se démarquer là-dessus et ne pas reproduire les erreurs des autres langages.
- Au vu de tes réponses précédentes, est-il possible de dire que tu crois toujours en l’avenir du langage ?
-
Bien sûr, car je vois des projets de grandes qualités arrivées.
J’observe également de nouveaux usages de PHP : dans des micro-systèmes, des TV, des téléphones…
PHP n’a pas encore montré de quoi il était réellement capable.
Ses aspects dynamiques et « glue » lui permet de s’intégrer et se brancher à n’importe quoi.
Je pense qu’il faut attendre des petites révolutions du côté de la qualité et des outils de développement.
Ça reste dans la philosophie première de PHP : tout le monde peut en faire, et les outils pour en faire peuvent réellement s’améliorer.
L'avenir de PHP vu par Ivan Enderlin
mercredi 6 novembre 2013. Lien permanent Réfléxions › PHP
À cause de quelques discussions qui ont accaparé ces jours derniers la plupart du temps que je consacre habituellement à ce blog, je n’ai pas publié la semaine dernière de nouvel opus de mon cycle d’interview à propos de PHP et de son avenir.
Cependant, les choses s’étant un peu calmées à présent, je peux donc reprendre, du moins je l’espère, mon rythme de publication habituel.
À la suite d’une remarque qu’a faite Perrick dans son interview sur le manque d’intérêt de la part des scientifiques pour PHP, j’ai une nouvelle fois décidé de donner la parole à quelqu’un qui n’a pas participé au premier cycle d’interview.
J’ai en effet choisi d’interroger Ivan Enderlin, car il est actuellement le seul chercheur en informatique que je connaisse qui travaille avec PHP.
De plus, ceux qui suivent ce blog savent que je le connais très bien, et je savais donc que je pouvais à la fois le contacter rapidement et obtenir des réponses intéressantes à mes questions.
C’est donc son interview que je publie aujourd’hui, pour vous faire patienter jusqu’à la publication de celle de Pascal Martin actuellement prévu pour la semaine prochaine.
Fil des commentaires de ce billet
Ajouter un rétrolien
URL de rétrolien : http://blog.mageekbox.net/?trackback/459
2 réactions
1 De Gugelhupf - 08/11/2013, 11:11
"J’observe également de nouveaux usages de PHP : dans des micro-systèmes, des TV, des téléphones…"
.
Aie aie aie...
2 De bdelespierre - 12/11/2013, 19:10
Un avis intéressant et pourtant nuancé (c'est rare, j'ai plutôt l'habitude d'entendre des zélotes qui évangélisent pour PHP ou leur techno en particulier).
En revanche, je ne suis pas certain que la programmation évènementielle verra un jour le jour en PHP. Il est d'ores et déjà possible de l'émuler avec la PCNTL mais bon... Je crois au contraire que PHP doit se concentrer sur ses points forts plutôt que de tenter de faire de la concurence à Node.