Peux-tu te présenter en quelques mots ?

Je vais plutôt inciter tes lecteurs à aller lire mon interview précédente, car j'y répond déjà à cette question.

Oui, c’est de la fainéantise (NDLR: je n'appelle pas cela de la fainéantise mais de l'efficacité, après tout, les liens hypertextes sont fait pour cela).

Quand as-tu découvert PHP ?

De mémoire, j’ai découvert le langage vers 1997.

Je me rappelle d’Altern.org et de PHP/FI.

Valentin Lacambre, l’hébergement gratuit sans publicité, ce sont mes débuts sur le web, et j’ai plongé dès le départ avec PHP.

À tes débuts, qu'est ce qui t'as séduit dans le langage ?

Franchement, au début j’ai pris PHP parce que je suis tombé dessus en premier.

C’était un langage simple, accessible, et il y avait un hébergement gratuit qui le proposait.

À l’époque, il n’y avait pas d’alternative similaire.

Et puis, en ce temps là, PHP était vraiment minimal.

C’était un petit langage de script quick‘n dirty, voire un langage de modèles si on met de côté les fonctions d’accès aux bases de données.

Bref, le langage en lui-même n’avait rien de séduisant, mais il proposait un joli premier terrain de jeu sur le web pour un ancien lycéen.

Par la suite, PHP est monté en puissance parallèlement à mes compétences et mes attentes, même s’il était à ce moment là un langage pour mes projets personnels.

Ensuite, il y a plein de choses qui m’ont séduites, au fur et à mesure des évolutions, mais cette séduction est apparue après, lorsque j’ai eu assez d’expérience sur d’autres langages et sur d’autres domaines pour pouvoir faire une comparaison.

Mais pour moi, la magie de PHP est plus dans le fait qu’il a évolué en même temps que moi que dans les fonctionnalités qu’il a intégré au cours du temps.

Et pour en revenir à l’aspect séduction, il y a deux choses qui ont beaucoup joué dès le départ.

Il s'agit de la communauté et de la documentation.

La communauté a toujours été là, dès le début, avec le partage d’expérience, l’entre-aide, et les bouts de code.

La documentation reste une des meilleures disponibles, même si elle a plein de défauts, mais par rapport à ce que j’ai sous d’autres langages, elle est excellente, et ça aide beaucoup.

Et au fil de ton expérience, qu'est ce qui t'as le plus rebuté ?

En vrac, il y a le manque de cohérence du langage et des bibliothèques de fonction, les options de configuration à gogo, le manque de vision dans l’évolution du langage, les bouts de code diffusés sur le Internet (oui, je sais, j’ai également mis ça dans les avantages) et plus tard, le fonctionnement de la core team (NDLR: aka le PHP Group).

Concernant la cohérence, certains mots clefs s’écrivent en majuscules, d’autres non.

On a parfois des exceptions, parfois des erreurs.

0 et 0 sont égaux, 0 et false sont égaux, mais pas 0 et false.

Il y a de bonnes raisons à tout cela, et d’autres raisons simplement historiques, mais on est en terrain miné et il faut faire attention à ce genre de détails pour utiliser correctement le langage.

Pour les fonctions c’est la même chose.

Une fonction peut générer des erreurs, des avertissements que je ne peux pas récupérer simplement, parfois une fonction retourne 0, d’autres fois false ou bien encore null, etc.

Certes, certaines des différences sont justifiées ou compréhensibles, mais le résultat est que même avec 10 ans d’expérience, je me retrouve à regarder très fréquemment la documentation pour me rappeler l’ordre des arguments ou la gestion des cas limites.

Et devoir en permanence vérifier l’ordre des arguments et le type de retour est pénible, très pénible.

La gestion des erreurs est, elle, toujours une plaie.

Ce n’est pas pour rien que la plupart des exemples utilisent le mysql(i)_connect(...) or die().

Faire une gestion correcte de l’erreur est tellement complexe dans un cas réel que le reste du code devient illisible pour un simple exemple.

J’ai aussi longtemps râlé contre l’idée des register_globals et des magic_quotes_gpc.

Même jeune développeur je voyais tout de suite l’erreur fondamentale que c’était.

Je peux pardonner register_globals de part l’historique de PHP mais pas magic_quotes_gpc, ni le fait que ces deux directives soient restées si longtemps actives.

Bon, je critique mais c’est toi qui a demandé hein, ça ne veut pas dire que tout est négatif.

Que reproches-tu à la core team aka le PHP Group ?

J’en ai déjà parlé un peu dans l'interview précédente.

Je pense que dans le cadre de cette question précise, ce qui m’a le plus manqué sont des gens passionnés prêts à faire évoluer le langage autrement que pour leurs besoins du jour.

J’ai eu plusieurs fois l’impression que les évolutions dépendaient uniquement des besoins des membres du PHP Group ou de leurs sociétés.

C’est par exemple le cas pour DateTime. Le besoin était criant depuis longtemps et il a finalement été comblé mais en urgence, avec un conflit vis à vis de pear, parce que (c’est mon interprétation) Derick Rethans en avait besoin pour eZ.

Par contre, je ne le reproche pas.

Il est normal et il est sain que les contributeurs visent leur besoin quand ils font évoluer PHP.

Cela permet d’éviter des délires, et puis ils n’ont aucune raison de faire autrement.

Au nom de quoi viseraient-ils mon besoin plutôt que le leur ?

Je regrette également qu’à l’époque, les désirs de la communauté n’aient pas été plus pris en compte, qu’il n’y ait pas eu plus d’échanges d’idées et de réflexions autour des idées de la core team.

Pendant longtemps, les réponses des contributeurs ont été ce n’est pas possible et PHP n’est pas java, alors que des choses comme les interfaces, le typage d’argument et les espaces de nom ont finalement été implémentés.

Tout comme le manque de cohérence, cela engendre également beaucoup de frustration.

Je regrette de plus qu’il n’y ait jamais eu un passionné capable d’influencer le développement de PHP pour le faire évoluer dans le bon sens, le bon sens étant bien entendu “ma vision” ;).

Là encore, je ne reproche rien puisque chacun a sa vision du langage idéal et de PHP, mais ça ne m’empêche pas de regretter que la direction prise ne soit pas celle que j’aurai choisi, et qu’au final, le résultat me rebute parfois.

Je veux cependant être clair.

Je critique, mais c’est facile de le faire de loin, après coup, et de laisser les autres travailler.

Depuis mon fauteuil, je me rends bien compte que eux font, et que forcément ils ne font pas tout parfaitement mais qu’au moins, ils font, ce qui n’est pas mon cas (du moins pas de la même façon et pas sur le code de PHP lui même).

Quand bien même j'apparais très critique je ne perds pas du tout cela de vue, et je souhaite que tes lecteurs ne le perdent pas de vue non plus : pointer tous les défauts et critiquer ce qui fonctionne mal ne doit pas être vu comme une critique des personnes et ne vient pas du tout en conflit avec l’idée globale qui est que ce qui est fait est bien.

Je sais que ma prose est souvent très critique et je tenais à rappeler qu’il ne faut pas s’arrêter à ce que j’en dis de négatif.

Et finalement, c’est aussi simplement parce que je suis frustré et que je ne m’amuse plus avec PHP que je ressens ces défauts de cohérence, d’organisation de la core team (et pas le contraire).

Le langage que j’affectionne actuellement a certainement autant de défauts, peut être même plus, mais l’amusement qu’il me procure me permet de ne pas les voir.

Utilises-tu encore PHP actuellement ?

Oui et non.

Je ne développe plus en PHP, ou très rarement.

Je le faisais encore il y a un an et demi, mais peu.

C’est en grande partie due à mon évolution professionnelle, qui fait que je code beaucoup moins, tous langages confondus, et que le code que je fais est plus souvent qu’avant du code côté client que du code côté serveur, mais il n’y a pas que ça.

Du côté personnel, quand j’ai un développement à faire, j’utilise Ruby.

Ce n’est pas nouveau puisque j’en parlais déjà en 2005/2006.

Ça m’est venu un peu par vagues successives depuis.

À certains moments, je fais du Ruby, et à d’autres, je reviens vers PHP.

Mais depuis quelque temps, j’ai trop de mal à me contraindre à faire du PHP et d’ailleurs, rien que l’utilisation du mot contraindre est symptomatique.

Du côté professionnel, par contre, PHP reste un domaine fort.

Audit, expertises, architecture, conseil, suivi technologique, une bonne partie de tout cela se fait en PHP et cela ne me pose aucun problème.

Je n’ai aucun mal non plus à souvent conseiller PHP.

Ce n’est pas tant que PHP soit mauvais ou que j’ai absolument envie d’en partir, c’est juste qu’il me frustre et que le fun n’est plus là.

Pourquoi être passé à Ruby ?

L’envie d’explorer a été ma première motivation.

J’ai touché à beaucoup de choses, pas qu’à PHP et Ruby.

Il y a encore deux ans, je faisais un peu de Perl au niveau professionnel.

Actuellement, je touche encore pas mal de Javascript, j’ai donné par le passé des formations Java, et j’ai tenté sans succès d’apprendre OCaml, par exemple.

J’aurai trop de mal à vivre étriqué, sans aller voir ce qu’il y a autour, sans apprendre régulièrement quelque chose de nouveau, et sans prendre le meilleur de chaque expérience pour enrichir ma vision.

Et le problème que j’ai vis à vis de PHP vient de là.

Plus je regarde les autres langages, plus je me sent à l’étroit dans PHP.

Je ne parle pas de savoir si c’est ou non un langage professionnel, on a répondu plus d’une fois à cela et je n’ai pas accroché du tout à la vision de Java et à ses architectes.

Je parle de passion et d’amusement, de liberté et de feeling.

Ruby m’a donné les blocs, les espaces de noms, les fonctions anonymes simples, un vrai modèle objet, la méta programmation, des attributs virtuels, une gestion d’erreur plus cohérente, un framework web plus amusant, des expressions rationnelles avec moins de six \ consécutifs, et j’en passe.

Certaines améliorations sont venues par la suite en PHP (espaces de nom, fonctions anonymes) mais ce n’est pas encore ça.

Notes que j’aurai pu passer à Python ou à autre chose, Ruby n’a été qu’une expérience.

À une époque, j’ai même hésité pendant de longs mois entre Ruby et Python.

Ce qui a été déterminant dans mon choix a été le système de blocs de Ruby, et le fait que les méthodes avec deux _ de Python me gênaient un peu.

Plus tard, l’arrivée de ROR m’a conforté dans mon choix, même si j’ai toujours envie d’explorer plus en avant Python.

Bref, je me dis que j’ai probablement plus quitté PHP que rejoint Ruby.

Ce dernier n’aurait pas été là, j’aurai pris Python, ou encore autre chose.

Et que faudrait-il pour que tu fasses la démarche inverse ?

Pourquoi le ferai-je ?

Et pourquoi souhaiterais-tu que je le fasse ?

J’ai plusieurs outils, je les utilise suivant les besoins et suivant les envies.

Quand c’est côté professionnel, je fais plus attention aux besoins (d’où le fait que je travaille toujours autour de PHP) et quand c’est du côté personnel, je fais plus attention à l’envie.

En ce moment, l’envie est sur Ruby/Python, voilà tout.

J’ai plein de raisons objectives de faire moins de PHP, mais personnellement, ce qui l’emporte est toujours l’envie du moment.

Utiliser plusieurs langages est plutôt une force, et je n’ai aucune intention de faire uniquement du PHP, quand bien même PHP serait objectivement et de loin le langage le plus intéressant.

Maintenant, si le but de la question est de savoir comment lever ce qui me gêne dans PHP, ou ce qui pourrait me faire à nouveau m’amuser avec PHP, je dirais :

  • la disparition de tous les boulets historiques de php (magic_quotes_gpc est dans les premiers),
  • l’ajout d’Unicode,
  • un peu de méta-programmation (et pas les annotations qu’on nous prépare, qui sont la méta-programmation du pauvre),
  • des attributs virtuels (j’y tiens beaucoup),
  • un framework web un peu plus simple et magique (j’ai encore du mal à voir symfony et Zend Framework comme des outils qui simplifient le travail au niveau personnel, ils ne font que cadrer et homogénéiser mais l’architecture reste assez complexe),
  • plus d’homogénéité dans les fonctions (type de retour, retour en cas d’erreur),
  • la refonte des erreurs/exceptions,
  • quelques API objets autour des API fonctions actuelles.

Et comme je suis en train de faire un liste pour le père Noël, je m’arrête là.

Je sais que certaines choses mettront beaucoup de temps et que d’autres sont difficiles voire impossibles avec le moteur actuel de PHP et son environnement.

Et puis, pourquoi vouloir refaire ce que je connais ailleurs ?

Finalement, c’est peut être juste qui manque à PHP, ce petit quelque chose que les autres n’ont pas et qui pourrait m’amuser (un temps, jusqu’à ce que j’ai envie de faire autrement).

Actuellement je n’ai pas (ou plus) ce petit quelque chose.

Penses-tu que casser la compatibilité avec l’existant serait intéressant pour l’avenir ?

C’est absolument nécessaire, et plus on tarde plus c’est difficile (comprendre : si c’est si difficile c’est aussi qu’on a trop tardé).

On ne peut pas évoluer sans rien casser avec un langage qui est si contraint au départ.

Ça s’est vu avec le choix du séparateur pour les espaces de noms.

Avoir dû prendre \, alors qu’il a une signification spéciale très ancrée chez tous les développeurs, prouve qu’on est aux limites des ajouts possibles.

Et puis, certaines choses comme la refonte des fonctions et des erreurs pour plus d’homogénéité demande forcément de casser en profondeur et d’avoir une version réellement incompatible.

Le problème est qu’il va falloir trouver le truc qu’il faut ajouter à PHP pour le rendre suffisamment attirant et ainsi justifier cette cassure de la compatibilité.

Au final, tu n’es donc pas un vrai switcheur, puisque tu utilises encore PHP professionnellement. Pourrais-tu couper le cordon définitivement ?

Damned, je suis découvert !

Non, effectivement, je n’ai pas basculé complètement comme certains.

Ceci dit je n’ai pas vocation à basculer complètement sur quoi que ce soit.

Je considère comme une très bonne chose d’avoir plusieurs cordes à son arc, et de les garder.

Un développeur se doit d’être familier avec plusieurs langages et plusieurs technologies.

Se faire enfermer dans Python ou Ruby plutôt que PHP est peut être mieux à court terme mais n’est pas mon objectif.

Pourrais-je couper définitivement le cordon ?

Probablement pas.

Il y a le côté professionnel, où forcément il est plus simple de valoriser une expertise déjà existante.

Mais il y a aussi la volonté de ne pas être mono-culture et de regarder à chaque fois ce qui est le plus approprié, sans religion établie d’avance.

Je fais aussi du Javascript avancé, j’ai fait du Perl, du Java, etc.

Il faudrait que PHP soit sacrément mauvais pour que je le mette sur ma liste noire et que je me refuse à y toucher.

Ce n’est pas le cas.

Après, il faut voir la différence entre professionnel et personnel.

Côté professionnel, je ne développe plus, ou en tout cas ce n’est pas mon rôle et ma valeur ajoutée.

Et quand il s’agit de parler expertise, architecture, besoins fonctionnels, qualité, usages ... si PHP répond aux besoins du client, je parle de PHP.

Mon travail est de résoudre les problèmes et de gérer les besoins concrets d’entreprises réelles.

Je ne souhaite pas faire n’importe quoi (et je ne le ferai pas) mais je n’ai aucun problème à travailler avec PHP quand cela est pertinent alors que pour mes développements personnels, mes besoins de passion et d’amusement me poussent ailleurs.

Chaque domaine a ses propres contraintes et ses propres critères.

Par contre je me permet de respectueusement disconvenir de ta conclusion.

Je me considère quand même comme un switcheur, bien que je travaille encore autour de PHP (mais pas que).

Mes développements, quand j’ai le choix, se font souvent avec autre chose, et c’est dans la tête que le switch est surtout important.

Je me sens bien plus proche de ceux qui ont basculé vers Python ou Ruby que de ceux qui sont restés avec PHP.

Je comprends et respecte les deux, voilà tout.

Je serai étonné d’ailleurs que les autres switcheurs ne sortent jamais PHP, par exemple pour modifier une application existante, pour faire un petit script qu’on a déjà fait avec ce langage, ou pour utiliser une bibliothèque agréable en PHP qui l’est moins sur Python (par exemple).

Ce sont ces développeurs, qui ont suffisamment de recul pour ne pas être mono-maniaques, que j’apprécie le plus.