- Peux-tu te (re)présenter en quelques mots ?
-
Je suis ingénieur en R&D et référent JavaScript dans une société de mise en relation commerciale.
Depuis la précédente interview, j’ai aussi travaillé dans une société de télécommunication comme développeur pour des produits de téléphonie.
Je suis toujours un geek passionné par la bonne gastronomie et les bons alcools et autres spiritueux. Je suis également formateur JavaScript.
Au moment de l’interview précédente, je m’apprêtais à basculer dans le monde du Java.
Mais suite à des mensonges répétés de la direction de la boite où j’étais, j’ai démissionné.
Du coup, j’ai remis les pieds dans le PHP et j’en ai profité pour faire du C++ et plus de JavaScript.
J’ai alors développé une vraie passion pour ce langage incompris sur lequel je me concentre de plus en plus.
- Que penses-tu de l’évolution de PHP depuis l’abandon du développement de PHP 6 ?
-
À l’époque, je commençais ma carrière et depuis, des choses que je reprochais à l’époque à PHP ont fini par disparaître de mes préoccupations.
On va dire que je m’y suis habitué, d’autant que du côté de JavaScript, il y a également de quoi s’arracher des cheveux.
Le problème de typage faible reste une tare à mon sens.
Comme j’en discutais avec Amaury Bouchard sur son blog il y a quelques semaines, je pratique le code défensif (erreur de jeunesse, peut-être ?) et le typage faible m’impose donc beaucoup de code pour "rien", ce qui représente une vraie perte de temps.
L’évolution de PHP est donc intéressante, mais même si des choses passionnantes sont arrivées et sont bien pratiques, comme les traits et composer par exemple, je ne suis pas encore satisfait.
J’ai en revanche totalement changé d’avis sur le mapping et les ORM. A l’époque je me plaignais qu’il n’y ait pas de solution à la sauce JPA dans PHP.
Maintenant, ça me va très bien. Le mapping me semble en effet être une horreur en terme de maintenance et finalement, coder soi-même ses requêtes SQL, prendre le temps de les comprendre, de les améliorer est bien mieux, aussi bien pour le code que pour les performances ou pour soi-même.
- Avec le recul, penses-tu que la communauté des contributeurs a tiré toutes les leçons des erreurs commises avec PHP 6 ?
-
Non, car PHP ne supporte toujours pas Unicode et c’est dommage, mais oui, car j’ai l’impression que les processus de développement se sont améliorés et que les développeurs sont plus à l’écoute des besoins des utilisateurs et moins à l’écoute d’eux-mêmes.
C’est un vrai gain.
- PHP évolue aujourd’hui beaucoup plus vite que par le passé, penses-tu que ce soit une bonne chose ?
-
J’ai toujours trouvé très drôle la polémique sur les versions à la Chrome où l’on reproche à Google de vouloir aller trop vite au point que ça en devient ridicule.
Je suis plutôt pour des cycles rapides.
Je suis très jeune, je fais partie de cette génération qui n’aime pas attendre, qui veut tout tout de suite, tout le temps, partout.
Donc quand on me parle d’une nouvelle fonctionnalité, mais que je vais devoir attendre des mois voire des années pour l’avoir, je ne suis pas d’accord.
On pense faire ça ? Alors on le fait, c’est tout. Donc oui, ce nouveau cycle est une bonne chose de mon point de vue.
- De nouveaux langages comme Go, Dart, Node.js, Scala ou Closure 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 ?
-
Techniquement, je ne peux pas considérer NodeJS comme un nouveau langage, car c’est seulement un environnement différent.
PHP a atteint un certain stade maturité et des frameworks solides l’exploitent pleinement aujourd’hui donc ça a toujours un intérêt d’opter pour lui. J’ai bien évidemment un faible pour NodeJS, mais il y a encore quelques soucis, comme l’absence d’une version 1.0, donc stable. Et il y a des problèmes assez fâcheux, puisque certains développeurs arrivent à se débrouiller pour écrire des scripts compatibles uniquement avec OSX (genre nopt qui pose régulièrement souci sur Debian) alors que le langage est censé être comme Java multi-OS.
Et tout le monde connaît mon manque d’amour pour la Pomme.
- Quelles ont été pour toi les évolutions les plus significatives dans l’univers de PHP depuis 2010 ?
-
Les traits et surtout Composer qui un petit outil sympathique tout comme un machin appelé atoum, bien qu’il ne soit pas encore très connu… Non, je rigole !
Ce sont ces 3 aspects qui me semble les plus importants.
- De quoi aurais-tu besoin aujourd’hui dans PHP dont tu ne disposes pas ?
-
Je voudrais pouvoir avoir du typage fort ou plus restrictif.
Je suis en train de basculer sur TypeScript en JS (un truc Microsoft) qui me permet d’avoir du typage fort en codant en JavaScript.
- Au vu de tes réponses précédentes, est-il possible de dire que tu crois toujours en l’avenir du langage ?
-
L’avenir de PHP n’est pas quelque chose qu’on peut remettre en cause.
Ma génération a appris en grande majorité PHP.
Que ce langage soit adapté à toutes les situations, il est sûr que non, mais beaucoup de développeurs de mon âge garderont tout de même le réflexe de l'utiliser.
Et s’il y a des utilisateurs en quantité, il y aura toujours des évolutions.
Composer a apporté un énorme vent de fraîcheur et de capacité à PHP, car avant qu’il n’existe, qui mettait vraiment à jour le code externe de façon régulière et efficace ?
L'avenir de PHP vu par Mathieu Robin #2
vendredi 20 septembre 2013. Lien permanent Réfléxions › PHP
Voici la deuxième interview de ce second cycle d’interviews au sujet de l’avenir de PHP.
Aujourd’hui, c’est donc Mathieu Robin qui prend la parole puisqu’il m’a fait le plaisir de répondre à mes questions une nouvelle fois, et je l’en remercie.
Je ne sais plus exactement dans quelle circonstance j’ai fait sa connaissance, mais à l’époque, il m’avait semblé un garçon intéressant et la chronique qu’il publie maintenant depuis quelques années à propos de jQuery ainsi que nos échanges épisodiques aussi bien sur Internet que dans la vraie vie n’ont fait que confirmer ma première impression.
À l’époque de sa première interview, Mathieu était encore un apprenti, mais depuis, il est rentré de plain-pied dans la vie active et cela a fait forcément évoluer la vision qu’il a de son métier en général et de PHP en particulier.
Fil des commentaires de ce billet
Ajouter un rétrolien
URL de rétrolien : http://blog.mageekbox.net/?trackback/450
8 réactions
1 De Kyoku57 - 20/09/2013, 14:26
" ... alors que le langage est censé être comme Java multi-OS ... "
Tu sais, je croyais aussi avant d'en faire que Java c'était du "Write one, run everywhere" et puis la réalité m'a fait un joli s/run/debug/g dans la face. Les implémentations de JVM qui change d'une plateforme à l'autre (Comment ça IBM ???). Je pourrais en parler des heures ...
Pour les ORMs, ça dépend toujours des goûts et couleurs sur le moment, sur le projet. Perso, j'en étais pas fan et je codais sur PHP en mode Porky. Mais JPA est quand même pratique côté Java car il ne t'empêche absolument pas de coder des requêtes natives. La phase de mapping est chiante et longue, je te l'accorde ... mais c'est Java et au final sur le reste du projet, tu gagnes quand même du temps. Sur Python, je suis fan de SQLAlchemy qui est un ORM vraiment très bien conçu et pratique et ça ne me viendrait pas à l'idée de faire sans avec ce langage. Les goûts et les couleurs du moment. Je pensais que doctrine était bien pour PHP mais j'avoue n'avoir jamais pris le temps de m'y mettre sérieusement. As tu déjà essayé ?
Merci de cette interview Mathieu. Au plaisir de lire tes chroniques
2 De bdelespierre - 20/09/2013, 20:00
Pour moi, ce qui va réellement tuer PHP dans les 10 prochaines années c'est son incapacité à s'adapter aux nouveaux usages du web (je pense surtout au push et aux sockets). Cette incapacité vient, selon moi, de la difficulté que le langage ait a se réinventer. C'est en quelque sorte la rançon de sa gloire: PHP a toujours mis le focus sur la rétro compatibilité, ce qui nuit aujourd'hui a son développement. Je ne serais pas étonné de voir d'autres plateformes (JavaScript en tête prendre le lead d'ici 2020). Les évolutions timides (traits, générateurs, this dans les closures) ne sont a mes yeux que de simples hacks destinés à donner a la communauté des OS a ronger pendant qu'on balaie sous le tapis les véritables attentes du marché.
Donc, oui, pour moi PHP est et restera longtemps une techno avec laquelle il faudra compter... Mais de moins en moins.
3 De bohwaz - 24/09/2013, 05:41
Marrant mais on n'est pas d'accord du tout. Perso je préfère largement des cycles de release lents, j'ai autre chose à faire que passer mon temps à me mettre à jour des nouvelles fonctionnalités et trucs qui cassent, donc le cycle actuel me convient très bien avec les 5.x qui apportent leur lot de nouveaux trucs tous les 2-3 ans et les 5.x.y qui apportent des corrections et des petites nouveautés. Je trouve les cycles de Firefox ou Chrome complètement illisibles et ridicules. C'est d'ailleurs pour ça que j'utilise Debian : la stabilité c'est important, et ça implique déjà que le système n'évolue pas tout le temps n'importe comment.
Quand à Composer je trouve ce truc complètement inutile et chiant. Inutile car il suffisait de faire des paquets deb/rpm pour ses dépendances et chiant car complètement pas intégré avec le reste du système. C'est un peu comme les gems pour ruby ou les pip pour python ou ndm pour nodejs, je trouve que c'est une incitation à faire n'importe quoi n'importe comment et importer du code de n'importe où qui peut potentiellement faire n'importe quoi.
4 De bdelespierre - 25/09/2013, 16:39
@bohwaz : heu... y'a peut être une raison qui pousse les plateformes à se doter de leurs propres gestionnaires de paquets non ?
Je crois que les contributeurs de Node, ROR et PHP savent tous très bien ce que sont les systèmes de dépôt et je pense qu'ils s'en sont inspirés créer ceux de leur plateforme avec un objectif en tête: l'indépendance vis-a-vis de l’environnement. Parce que, qu'on l'aime ou non, tout le monde n'est pas sur Debian, tous les dépôts ne sont pas gérés de la même manière et il faut malheureusement prendre en compte Windows Server...
Quand aux cycles de release lents, je comprends ton point de vue concernant la stabilité et dieu sait qu'il est difficile de trouver un compromis satisfaisant pour tout le monde entre rétro-compatibilité et innovation. Le problème avec PHP, c'est qu'il bouge selon moi pas assez vite pour rester dans la "course" des plateformes web. C'est ce que je voulais dire en disant que c'est sa force et sa faiblesse.
5 De MathRobin - 26/09/2013, 11:37
@bohwaz : Je peux comprendre tes craintes concernant l'ouverture au n'importe quoi via Composer. Ceci dit, ça ne fait que faciliter les choses. Les ev qui font n'importe quoi le pouvait déjà avant Composer, avant Bower, avant npm etc. La preuve, le nombre incalculable de sites qui utilisent en simultané plusieurs versions de jQuery. C'est comme pour tous les outils, il y a les consciencieux qui font les choses bien et les mecs qui de toute façon, avec ou sans, font n'importe quoi.
Je suis surpris de l'argument de "autre chose à faire que mettre à jour". Il est vrai que c'est coûteux en temps, mais en général, si c'est pour gagner en sécurité et performances (arguments clés), ça vaut souvent le coup.
6 De MathRobin - 26/09/2013, 11:40
@Kyoku57 : Je ne connais pas SQLAlchemy, je vais essayer au plus vite. Merci Par contre j'ai essayé plusieurs fois Doctrine, utilisant souvent Symfony. Je ne peux plus l'encadrer. C'est un des premiers trucs que je dégage quand je lance un projet Symfony.
7 De bohwaz - 28/09/2013, 13:46
@MathRobin : Comprenons nous bien, je suis toujours pour gagner en sécurité, performance (faster faster!) et bugfixes, mais les nouveautés syntaxiques je préfère que ça soit d'un coup. Par exemple je suis le dév de PHP pour voir ce qui se fait, mais je ne teste pas trop les nouvelles fonctionnalités tant qu'elles ne sont pas dans debian stable. Sinon c'est un coup à commence à utiliser un nouvel outil/syntaxe über-cool et réaliser que tes serveurs ne peuvent pas l'utiliser encore : frustration.
Je parlais en fait surtout des grosses màj comme PHP 5.4/5.4 ou quelques fonctionnalités clé sont dépréciées/supprimées et d'autres apparaissent, je préfère que ça se fasse tout d'un coup, ça permet de laisser du temps et préparer la mise à jour de son code, plutôt que d'avoir des petites mises à jour qui cassent des petits trucs différents à chaque fois ou alors apportent une nouvelle fonctionnalité essentielle : on ne sait plus trop où on en est. Je trouve que justement PHP a un cycle tout à fait satisfaisant de ce point de vue-là et le guide de migration à chaque version est exemplaire : je kiffe.
8 De Amaury - 29/09/2013, 23:13
Merci pour la citation et le lien
Je ne vais pas refaire la discussion, mais je persiste : le code préventif, c'est mal