mageekblog

La dernière fois, c’était en 2010 ? Alors depuis j’ai cofondé une startup dans la distribution du livre numérique. Nous accompagnons les libraires dans la vente d’ebooks via une solution la plus ouverte possible, tranchant avec les jardins fermés et prisons dorées des Amazon et cie. Nous y faisons du PHP, mais aussi un peu de Ruby et du JavaScript.

Plutôt du bien. Les versions 5.4 et 5.5 ont permis de confirmer que les innovations de la 5.3 n’étaient pas qu’un accident de parcours. J’avoue que je n’avais pas parié sur une évolution aussi positive.

Je retiens les traits, l’API pour les mots de passe, l’abandon des magic quotes (enfin) et l’arrivée d’un cache d’opcode intégré à PHP (je ne saurai exprimer combien la situation précédente était insensée). Il y a aussi plein d’autres choses que je trouve sympa, mais essentiellement de l’ordre de la correction ou de l’amélioration.

Bref, c’est bien et ça va dans la bonne direction, pas un rythme insoutenable, il faut que ça continue de monter en puissance.

Je vais répondre à côté : Il y a eu une bonne prise de conscience du mauvais fonctionnement entre les développeurs et la communauté et, de l’extérieur vu que je ne suis plus la liste interne de façon régulière, j’ai l’impression que le nouveau fonctionnement est plutôt bon.

La gestion du langage reste toutefois trop influencée par Zend, Rasmus et quelques développeurs historiques. Pendant des années, on nous a dit qu’intégrer APC n’était pas une bonne idée parce qu’il fallait avoir le choix et que ça ralentirait PHP, mais quand c’est Zend qui propose d’intégrer son code pour faire la même chose, ça passe. Pour moi c’est assez symptomatique. Ceci dit seul le résultat importe et ce résultat est bon, donc ne mégotons pas.

Franchement, je pense qu’on peut amener plus de choses. J’ai encore de grandes attentes et je suis plutôt favorable à une accélération qu’à un ralentissement. C’est d’autant plus vrai que le plus difficile était de laisser derrière nous certains reliquats historiques. Maintenant que c’est fait, il n’y a pas de raison d’avancer lentement.

D’autres langages comme Ruby semblent avoir un cœur bien plus sujet à modifications sans que ça soit un vrai problème. Je crois qu’un des problèmes de PHP c’est aussi le faible suivi des mises à jour, et avancer trop vite ne servirait à rien.

Quel projet ? Avec quelles contraintes ? Avec quelle équipe ? Avec quelle histoire et quel existant ? Ce n’est pas forcément un mauvais choix. Après je ne fais pas de religion et chaque projet a ses besoins et ses spécificités.

Je pourrai partir en PHP, Ruby/Python (que je mets dans la même case), Java, ou JavaScript suivant les cas. Go, Dart, Scala, Clojure, je ne pense pas que je l’envisagerai hors besoin très spécifique. Ça fait beaucoup parler, mais non seulement je manque de recul, mais en plus le retour d’expérience et la masse critique sont insuffisants pour moi.

Ceci dit ça n’empêche pas de jouer avec, de découvrir. Au contraire : J’incite tous les développeurs à jouer avec un maximum de langages.

L’intégration d’un cache d’opcode est une grosse étape. Pas forcément la plus utile vu que tout le monde ajoutait un cache d’opcode de toute façon, mais symboliquement ça permet de laisser ce sujet derrière nous.

Je n’utilise pas encore vraiment les traits (les habitudes ont la vie dure), mais je suis heureux de voir arriver quelque chose pour favoriser la mutualisation technique dans le modèle objet. Ça manquait vraiment, surtout quand je vois la richesse qu’apportent les mix-in en Ruby.

L’API de mot de passe était un indispensable. L’API crypt était sous-utilisée, les gens faisaient n’importe quoi. Bref, j’espère que ça va améliorer sensiblement l’état des applicatifs PHP. Ça mérite mieux qu’attendre une mise à jour vers 5.5.0.

Après même si je pense que ça ne changera rien pour 99 % des projets, je suis heureux de voir qu’on laisse derrière nous des fautes de conception comme les magic quotes. On a traîné ça trop longtemps par peur de casser la compatibilité. Passons à autre chose.

Je trouve la syntaxe des fonctions anonymes assez lourdes. Le function ($x, $y) use ($a, $b) { /* … */ } prend une sacrée place et ce n'est pas forcément top pour la lisibilité du code. Une syntaxe courte serait appréciable. Et quitte à aller dans ce sens, j’apprécie beaucoup le système de bloc de Ruby donc pourquoi ne pas imaginer quelque chose de similaire côté syntaxe (mais probablement plus restreint en terme de fonctionnalités).

J’ai aussi surtout envie de pouvoir gérer des accesseurs automatiques sur les attributs, ou des attributs virtuels, suivants comment vous appelez ça. Pour l’instant la seule solution si on ne veut pas faire des getX() et setX() partout à la Java, c’est d’utiliser les horribles __get() et __set(). Python, JavaScript et Ruby ont tous réussi à trouver une façon de faire. C’est une attente que j’ai depuis la 5.0 et je suis convaincu que ça diminuerait significativement la complexité et la quantité de code en jeu dans pas mal de projets et bibliothèques.

Après j’aimerai plus d’API objet et une meilleure homogénéité dans les fonctions natives, mais je sais que modifier ça ne se fait pas facilement.

Je crois que PHP ne risque pas de disparaître, et que de nombreux projets vont continuer à se baser dessus, avec raison. Après ça ne m’empêche pas d’avoir des préférences personnelles pour d’autres langages plus dynamiques.