mageekblog

J'ai découvert l'informatique à l'âge de 8 ans, je n'ai jamais arrêté depuis, et J'ai des compétences en développement, système d'exploitation, base de données, infographie et ergonomie.

En tant que développeur, je pratique PHP professionnellement depuis maintenant plus de 10 ans, dans le cadre de projets de petite ou grande envergure.

Je suis son développement dans le cadre de ma veille technologique depuis plusieurs années, même si ce suivi a été interrompu à plusieurs reprises, soit par manque de temps, soit parce que j'en ai eu marre de l'attitude des développeurs du langage vis à vis des utilisateurs.

Cette dernière raison est d'ailleurs, avec d'autres, à l'origine de la création de ce blog il y a maintenant 2 ans, puisque l'un de ses objectifs, relativement ambitieux, est de parvenir à avoir une réelle influence sur le développement de PHP, en mettant en lumière ses faiblesses, telles qu'elles sont perçues par ses utilisateurs, d’où mon premier billet.

J'avais en effet fait le constat au cours des années que je n'aurais jamais assez de poids en tant qu'individu pour parvenir à me faire entendre, et qu'il me fallait donc parvenir à fédérer suffisamment de personnes autour de moi pour y arriver.

J'ai donc commencé modestement à décrire mes frustrations, qui ont suscité quelques échos dans la communauté française des utilisateurs de PHP, ce qui m'a prouvé que je n'étais pas le seul à les ressentir.

Depuis, l'actualité du langage m'a donné l'opportunité de passer à la vitesse supérieure, mais je dois bien avouer que l'effet de masse n'a pas encore porté ses fruits, même si je sais qu'il y a des développeurs majeurs du langage me lise.

Si tu désires plus de détails sur moi, je t'invite à lire ce billet ainsi que mon CV qui te permettra de mieux cerner mon personnage.

Certain des interviewés précédents ont répondu qu'ils avaient ressentis du soulagement.

Or, ressentir du soulagement implique d'avoir souffert précédemment, et dans mon cas, ce n'était pas du tout le cas.

J'ai suivi le développement de PHP 6 depuis ses débuts, et je savais donc précisément à quoi m'en tenir sur le sujet, à tel point que j'ai répondu à un recruteur quelques jours avant l'annonce officielle de l'arrêt du développement que PHP 6 n'avait plus de raison d'être à part Unicode, vu que PHP 5.3 avait intégré la plupart de ses nouveautés, et qu'en conséquence, continuer son développement n'avait plus grand intérêt.

De mon point de vue, PHP 6 n'était donc pas une source de souffrance, puisqu'il ne m'a privé de rien.

À contrario, j'ai ressentie une certaine jubilation, car j'y ai vu une réelle opportunité de changer les choses, de corriger ce qui ne va pas, et de repartir de l'avant avec des bases plus saines, plus pratiques, d'autant que les raisons de l'échec de PHP 6 sont un regroupement de tout ce que je n'aime pas dans le développement de PHP.

J'y ai également vu la possibilité de repartir de l'avant, car depuis 2005, PHP était du réchauffé.

En effet, les versions successives du langage n'ont fait qu'introduire des fonctionnalités prévues pour PHP 6 et les développeurs n'ont pas intégré dans le langage de nouvelles idées, de nouveaux concepts réellement novateurs, comme les traits, par exemple, alors qu'ils étaient formalisés depuis longtemps.

J'ai donc commencé à suivre beaucoup plus sérieusement le développement de la prochaine version du langage, afin de voir s'il allait prendre une meilleure direction, si les choses allaient changer.

En parallèle, j'ai commencé à publier la série de billets Mort de PHP 6 + [123456789]\d\+ jours, afin de rendre moins opaque le développement de PHP en partageant ma veille, et ainsi potentiellement arriver à influer sur le développement du langage, conformément aux objectifs de ce blog.

Elles sont multiples,et je ferais un distinguo entre ce que j’attends en terme de fonctionnalités, et ce que j'attends au niveau de la politique de développement.

En terme de fonctionnalités, j'aimerais que le langage gagne en cohérence, et je ne parle pas uniquement des noms de fonctions ou de l'ordre des arguments de ces fonctions.

PHP dispose en effet de concepts intéressants, mais ils sont en général bridés ou inapplicables dans tous les contextes.

Je pense notamment aux fermetures, qui ne sont pas utilisables en tant que propriété d'un objet, ou bien à la méthode magique __invoke(), qui souffre du même problème, ou bien encore au contrôle du type des arguments qui est limité aux tableaux et aux objets.

Sur ces points précis, j'ai bon espoir de voir les choses changer, car par le passé, il y a eu, par exemple, un problème similaire avec les méthodes magiques __set() et __get(), qui perturbait le fonctionnement de isset(), et qui a finalement été réglé avec l'implémentation de __isset().

Rétrospectivement, le statut Wont fix du rapport de bug en question me fait d'ailleurs bien rigoler.

Je voudrais également un modèle objet plus puissant, la possibilité de pouvoir définir le type de la valeur de retour d'une fonction ou d'une méthode, une extension phar qui fonctionne correctement, la possibilité de passer un bloc d'instruction comme argument à la manière de Ruby, du threading, la possibilité d'utiliser n'importe quel mot-clef comme nom de classe, une utilisation des exceptions au sein des fonctions à la place de certaines erreurs, la conservation du domaine applicatif entre chaque requête http, et évidement un support natif d'Unicode et une réelle cassure de la compatibilité avec les versions précédentes afin de ne plus se traîner les boulets historiques du langage.

Cette liste n'est pas exhaustive, mais au final, je veux pratiquement les mêmes choses que les intervenants précédents, et pour ce que j'en sais actuellement, certaines sont effectivement prévues dans la prochaine version sur langage, alors que d'autres sont très clairement du domaine de l'utopie.

En terme d'organisation du développement, je voudrais que les développeurs de PHP soient plus à l'écoute des utilisateurs, de ceux qui veulent contribuer à son développement, et que des outils efficaces permettent de suivre le développement.

En effet, aujourd'hui, il n'y a rien qui permette de comprendre la façon dont est développée le langage.

Des décisions sont prises, mais personne ne peut dire exactement par qui ni comment, et en cas de conflit, il n'y a pas un leader capable de trancher une bonne fois pour toute et d'imposer une solution.

Et ces décisions sont censées être prise démocratiquement, mais il n'y a rien pour comptabiliser les votes ni même pour savoir ceux qu'il y en a en cours et qui a un droit de vote.

De plus, il n'y a pas de moyen simple de suivre un débat de manière efficace, d'autant qu'énormément de discussions ne sont pas publiques et que des développeurs qui ont un certain poids au sein de la communauté se comporte comme des électrons libres.

J'ajouterais que la documentation technique du Zend Engine est quasiment inexistante et que la communauté des développeurs est très hermétique aux nouveaux arrivants, ce qui ne facilite pas l'intégration des personnes intéressées par le développement du langage, d'autant que ce dernier obéit à des règles tacites et non écrites.

PHP n'a pas de lignes directrices, de philosophie de fonctionnement clairement définie, revendiquée et affichée, au contraire de Python, par exemple, qui a son zen.

En conséquence, le moindre ajout au langage ou la plus petite des modifications est susceptible de lancer un débat sans fin et enflammé au sein de la communauté, car personne n'a la moindre référence sur laquelle s'appuyer pour discuter.

Tout le monde parle donc du problème en fonction de sa sensibilité, et non en fonction de ce vers quoi doit tendre le langage en terme d'utilisabilité, de logique de fonctionnement, de performances, etc.

En bref, de l'intérieur comme de l'extérieur, PHP semble à certain moment plus être développé par des gamins dans une cours de maternelle que par des professionnels soucieux des utilisateurs, et j'aimerais vraiment que cela change.

Il est difficile de répondre à cette question de manière absolue, car tout dépend du point de vue.

Du point de vue de la communauté, le développement de la prochaine version a été considérablement simplifié par rapport à ce qui avait court du temps de PHP 6, du fait même de l'abandon de ce dernier, puisqu'il n'y a plus plusieurs branches de développement à gérer.

De plus, l'utilisation systématique des RFC, inaugurée pour le développement de PHP 5.3, a été généralisée, et tout à été fait pour faciliter la vie des contributeurs et leur donner à nouveau envie de travailler sur le langage.

Tout cela a parfaitement fonctionné et la communauté est à nouveau motivée et mobilisée.

Cependant, d'un point de vue externe, peu de choses ont changé.

S'il y a clairement une partie de la communauté qui ne veut plus repasser par un épisode similaire à celui de PHP 6 et qui fait tout son possible pour que cela ne se reproduise pas, il y a également très clairement des développeurs qui n'ont apparemment pas pris la pleine mesure de l'échec représenté par l'abandon de PHP 6, et c'est regrettable.

De plus, l'un des hommes les plus aptes à tirer pleinement les leçons de PHP 6, à savoir Lukas Kahwe Smith, a quitté plus ou moins le projet.

Pourtant, il y a de l'espoir, car la communauté des développeurs, même si cela lui est encore difficile, semble maintenant capable de s'accorder et de refuser de se laisser imposer des décisions individuelles sans contestations.

De plus, la porte n'est plus fermée systématiquement lorsque quelqu'un d'extérieur propose une fonctionnalité intéressante.

Je pense donc que la communauté des développeurs n'a pas encore, et j'insiste sur le encore, tirée toutes les leçons de l'expérience PHP 6, mais que cela va venir.

Par contre, je ne m'avancerais pas à dire combien de temps cela prendra...

Cependant, je peux dire ce que j'aimerais que les choses aillent beaucoup plus loin, et que la gestion du projet soit revue dans son intégralité, mais je pense que j'en demande beaucoup trop, car une grande partie des développeurs historiques du langage refusent en effet de trop structurer son développement et d'accepter de nouvelles règles.

Tout dépend de ce que tu met derrière ce terme.

Si tu veux dire par là que PHP devient un langage de qualité professionnelle, alors je te répondrais que cela fait maintenant longtemps qu'il l'est, même s'il n'est pas exempt de tares congénitales qui font dire à certain qu'en 2010, il est le langage le plus utilisé côté serveur mais qu'il a toujours besoin de prouver sa crédibilité et son sérieux.

Si tu veux dire par là qu'il est possible d'en vivre, comme l'entend Éric Daspet, alors je te répondrais, de part mon expérience récente, qu'il y a encore du chemin à faire, du moins en France et surtout en province.

PHP n'est effectivement pas l'un des langages leaders sur le marché pour les SSII, qui représente une grosse partie du monde professionnel en France, à tel point qu'un directeur d'agence d'une des plus grosses SSII françaises m'a dit récemment, je cite, que le marché, c'est 80% Java, 15% .net, et le reste, on ne sais pas ce que c'est !.

PHP, en province, est majoritairement l'apanage de petites structures, qui sont sur des marchés de niches, et il est donc difficile d'en vivre.

Sur Paris et sa région, la situation est un peu différente, car il y a de plus grosses structures qui font du PHP, mais là encore, le langage est loin d'être le plus répandu.

Maintenant, la situation est en train de changer, puisqu'il y a de plus en plus d'offres d'emplois relatives à PHP actuellement, et je ne peux que m'en réjouir.

Cependant, derrière cette forme de professionnalisation se cache en fait une industrialisation, et pas dans le meilleur sens du terme.

Je parle en effet d'une industrialisation au sens productif du terme, qui induit un nivellement par le bas.

En effet, elle passe par des outils tel que Symfony ou Zend Framework, dont le but est de faciliter les développements en cachant au maximum la complexité des technologies sous-jacentes et en simplifiant le plus possible les choses pour gagner en productivité.

Au final, les développeurs ne savent donc plus ce qu'ils manipulent exactement, et en arrive à ne plus comprendre toutes les conséquences de leurs actions, ce qui peut induire des problèmes de performances, des failles de sécurités, etc.

De plus, la créativité, l'imagination n'a plus du tout sa place dans le processus de développement, puisque les règles de développements sont imposées et que tout est fait pour qu'elles ne puissent pas être contournées.

Si on rajoute à cela le fait que la formation au développement web en général et à PHP en particulier est très succincte, du moins dans les cursus informatique généraliste français, on arrive à un résultat qui n'est pas forcément beau à voir et l'avenir ne parait pas rose.

Certaines incohérences du langage, comme celles liées aux fermetures, sont corrigées dans la version de développement, et l'extension du contrôle du type des arguments à l'ensemble des types du langage est à l'étude.

Les traits, qui facilite la réutilisation du code, seront certainement l'une des grosses nouveautés de la prochaine version, avec DTrace, qui facilitera le débogage.

Une simplification de la syntaxe est également en cours, puisqu'il est maintenant possible de manipuler la valeur de retour d'une fonction ou d'une méthode sans avoir à l'affecter à une variable, et que l'intégration des annotations pour permettre la méta-programmation est à l'étude.

Dans le même temps, des couches basses du langage sont remaniées et optimisées, et les performances sont à la hausse.

PHP va donc clairement dans le sens de cette professionnalisation.

Maintenant, j'aimerais quelque chose qui fasse la différence avec les autres langages.

La plupart des choses que je viens de citer ne sont pas novatrices, à part peut-être les traits, et ne sont que des améliorations de l'existant ou des apports de l'extérieur.

Alors, personnellement, contrairement à d'autres interviewés, je m'amuse encore avec PHP, certainement parce que je suis un peu masochiste, que j'aime me prendre la tête et que je connais très bien le langage et ses arcanes,

Cependant, je reste sur ma faim et j'aimerais à nouveau être impressionné par PHP sans devoir déchanter quelques minutes plus tard parce que les développeurs du langage n'ont pas été au bout des choses.

C'est d'ailleurs l'une des raisons qui me poussent à aller voir ailleurs.

Je n'ai pas encore franchis le pas, mais j'y pense de plus en plus sérieusement, à tel point que j'ai compilé node.js sur ma machine de développement, histoire de m'amuser vraiment et parce que je pense que la mutualisation du langage entre le client et le serveur a de l'avenir.

Encore une fois, je n'ai pas de réponse absolue.

Il y a des jours ou j'y crois, et d'autres ou je me dis, souvent d'ailleurs à la lecture de internals@, que PHP ne peut pas avoir d'avenir vu la façon dont il est développé.

Je me dis en effet très régulièrement, qu'avant même Python, Ruby ou tout autre langage, le plus gros problème de PHP est PHP lui-même, ou plus exactement ceux qui le développe.

Cependant, cela fait maintenant 15 ans que le langage évolue de cette manière, alors, pourquoi cela provoquerait sa mort ?

Le vrai problème est donc bien l'outsider, le langage efficace, fun et tourné vers ses utilisateurs qui pourrait faire ce que fait PHP et plus encore.

Ces langages existent, et qu'ils s'appellent Python, Ruby, ou Javascript importe peu.

La seule solution qu'à PHP de survivre face à eux est qu'il évolue dans le sens attendu par ses utilisateurs, ses fans, ceux qui ont une réelle passion pour le langage, afin qu'ils ne soient pas déçus et qu'ils aillent en conséquence voir ailleurs, car ce sont eux qui assurent sa pérennité : un langage est vivant et a donc un avenir tant qu'il est utilisé.

Et pour cela, il faut que la communauté des développeurs entende et écoute les utilisateurs du langage.

Et je crois suffisamment, du moins pour l'instant, au fait que c'est possible pour faire ce blog et y consacrer le temps suffisant pour me faire entendre.