Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Sans vouloir troller, si c'était pour passer à des langages modernes ce serait plutôt Kotlin, Scala, Rust ou PureScript.Envoyé par Matthieu76
Et pour répondre à la question : peut-être pour ne pas perdre des années à devoir réapprendre un langage et son écosystème et réécrire toute la base de code.
En quoi Java est-il plus moderne que PHP (question sérieuse, pas de troll)?
Sinon autre question : pourquoi quitter un language en pleine évolution et qui a connu de belles avancées au cours des 5 dernières années?
Pourquoi quitter un language quand tu une certaine expertise dedans, et qu'il y a une forte demande sur le marché, pour un truc où tu vas recommencer presque junior?
J'ai presque envi de refaire du PHP.
J'en ai plus fait depuis la version 5.5 et synfony 2
Consultez mes articles sur l'accessibilité numérique :
Comment rendre son application SWING accessible aux non voyants
Créer des applications web accessibles à tous
YES WE CAN BLANCHE !!!
Rappelez-vous que Google est le plus grand aveugle d'Internet...
Plus c'est accessible pour nous, plus c'est accessible pour lui,
et meilleur sera votre score de référencement !
Le soucis n'est pas d'avoir besoin de puissance, mais d'en utiliser moins et donc avec un même serveur d'envoyer beaucoup plus de requêtes et, au final, de gagner sur le long terme en terme de coût. Je ne dis pas que ce n'est pas confortable de travailler avec des langages interprétés (cela me rappelle BASIC dans les années 80 :-)) mais au moins il n'y a d'erreurs de syntaxe à l'exécution et on ne divise pas non plus le développement par 10 non plus.
Et honnêtement si on gagne en PHP par rapport au C++ sur le web c'est principalement grâce à l’écosystème à côté non ?
Comme je ne suis pas développeur WEB mais plutôt application lourde/embarquée, qu'en est il d'un serveur qui n'envoie que des données, et que les pages web (front-end) sont "redessinées" totalement sur le desktop (Vue.js...) ce qui reviendrait alors à avoir comme une application "lourde" qui travaille avec un serveur, dans ce cas il est intéressant que le serveur envoie toutes les données rapidement, on y gagne non ?
Quand on regarde https://www.techempower.com/benchmar...w=ph&test=json on voit quand même que les langages de scripts sont à la traîne et que les languages compilés ou JIT sont plus performants.
Explication ? (comme je ne suis pas développeur web ceci n'est pas un troll mais c'est sérieux)
Je me moque que PHP soit typé dynamiquement ou pas. Jusqu'à présent ça ne me pose pas tellement de problème.
Quand on travail avec une bonne documentation, on connait le type à l'avance, il n'a pas fallu PHP7 pour s'en assurer.
Pt'être un ptit test !== null, que l'on avait déjà en C (ou nullptr en C++).
Après si vous voulez que l'on soit obligé de définir le type à la déclaration ça ne me gêne pas, tant que PHP ne perd pas de performance CPU/RAM pour un même code.
Mais j'avoue que ce débarrasser du '===' et '!==' n'est pas du luxe, mais en échange on aura surement la perte de la conversion du int en string automatique lors de la concaténation.
Je tiens à souligner que j'utilise PHP à titre personnel et non professionnel, ce qui peut expliquer mon jugement sur la question.
Dans la plus part des cas les backend ne font quasi pas de tache très intensive , du coup la différence entre un backend php et un backend C++ (par exemple) est pas perceptible dans l'expérience utilisateur.
Et ce que tu vas potentiellement économiser en coût d'infrastructure (mois de ressource pour même résultat) tu vas le perdre presque x2 en coût homme.
Tu payes pas un expert C++ comme un expert PHP et aujourd’hui recruter des jeunes sur du C++ c'est difficile , parce que ça ne fait pas rêver grand monde et que, soyons honnete, c'est plus dur de faire du C++ , il faut donc de meilleur candidat pour arriver au même résultat. (on à une équipe à 80% C++ et c'est compliqué de l'étoffer).
En interprété t'es qd même censé testé ton code et ne pas avoir d'erreur d'exécution en prodJe ne dis pas que ce n'est pas confortable de travailler avec des langages interprétés (cela me rappelle BASIC dans les années 80 :-)) mais au moins il n'y a d'erreurs de syntaxe à l'exécution et on ne divise pas non plus le développement par 10 non plus.. Ca arrive quand meme c'est vrai, tout comme une fuite mémoire en C++ , sauf que l'erreur d’exécution est bien plus facile à corriger qu'un fuite un peu pernicieuse.
Tout à fait. PHP est aussi très facile à appréhender , c'est loin d'êtr ele cas de C++.Et honnêtement si on gagne en PHP par rapport au C++ sur le web c'est principalement grâce à l’écosystème à côté non ?
Rajoute à ca que mon équipe PHP peut travailler sous n'importe quel OS et que ma base de code peut fonctionner sous n'importe quelle OS sans devoir recompiler des lib ou parsemer mon code de #ifdefD'un point de vue performance brute , oui c'est évident. Du c++ compilé sera toujours plus rapide à l’exécution.Comme je ne suis pas développeur WEB mais plutôt application lourde/embarquée, qu'en est il d'un serveur qui n'envoie que des données, et que les pages web (front-end) sont "redessinées" totalement sur le desktop (Vue.js...) ce qui reviendrait alors à avoir comme une application "lourde" qui travaille avec un serveur, dans ce cas il est intéressant que le serveur envoie toutes les données rapidement, on y gagne non ?
Mais le dév aura couté bien plus cher (plus long à dév et main d'oeuvre plus cher) pour une différence perçue inexistante. Que les données arriver en 2ms au lieu de 4ms n'à aucune espèce d'impact sur l'UX et c'est ca qui prime aujourd'hui.
Y'a des truc comme le framework phalcon qui sont intéressants : Le fw est en C donc performances optimales , mais l'utilisation reste en PHP donc facilité et rapidité
Oui enfin le C++ a beaucoup évolué également et aujourd'hui il permet de coder plus rapidement et plus efficacement. Et les frameworks web C++ aussi ont beaucoup évolué (il y en a même un qui fonctionne un peu comme PHP : http://www.tntnet.org). Et il n'y a pas que C++, Rust est peut-être une alternative intéressante.
Justement, la compilation fait certaines vérifications automatiquement ce qui évite certains tests. Et en C++ moderne, les fuites mémoire sont quand même beaucoup plus rares. Rust apporte également beaucoup sur ces points.
Oui mais alors non. Déjà en backend, le code tournera sur un serveur, donc les problèmes de portabilité n'ont rien à voir avec ceux d'une appli desktop. Et compiler un projet C++ moderne, ça se résume généralement à un "apt install" ou "git clone --recursive" suivi d'un make. En PHP, il faut quand même installer un serveur web + son module PHP voire une interface fastcgi...
Je travail sur un backend C++ qui peut s’exécuter sur les 3 systèmes en fonction des souhaits client. Et sa compilation est loin de se résumer à un make.
Je dois avoir toutes les dépendances compilées pour mon environnement car tout est static (boost,openssl,curl, et j'en passe).
Ce qui veux dire qu'en fonction du système et du compilo utilisé , il faut que j'ai un .lib ou .so/.a de disponible pour toutes les dépendances (30 actuellement ...). Autant dire que c'est pas toujours fun quand t'es le premier à inaugurer un nouveau truc sans compatibilité binaire avec les précédents.
Dès que j'ai besoin de faire quelque chose qui touche au système je suis obligé de #ifdef et d'écrire 3x la la même fonctionnalité.
Autant de problème qui n'existerait pas en PHP. Ce backend est fait en C++ car on fait plein de chose que PHP ne saurait pas faire correctement mais c'est pas nouveau que le dév C++ même en C++11 et + est plus compliqué que d'autre langage, c'est aussi ce qui fait sa force.
Ben voilà, tout est dit. C'est peut-être pas tant C++ qui est compliqué mais surtout qu'on l'utilise généralement pour des applications elles-mêmes compliquées. Maintenant, PHP convient très bien pour pas mal d'appli, le tout c'est d'avoir un outil adapté au problème.
Pour avoir lu les discussions sur le P++ (https://externals.io/), quasiment tous (si ce n'est tous) les autres développeurs de PHP sont contres. Sans compter les utilisateurs.
Ils viennent également d'ouvrir un sondage, et pour l'instant, l'avis général est clair : 0 - 13 en faveur du non en 20 min
https://wiki.php.net/rfc/p-plus-plus
Coté C# avec .net core ça s'améliore fortement quand même (coté perf et déploiement)….
Cela dit quand tu parle de .net à certains ils te sortent des arguments de vb6 ( qui date 1988 et qui n'est pas du .net).
Coté Java la lourdeur est souvent due à des technologies ayant grossi au fils des années : Eclipse RCP , OSGI sont de bon exemples , c'était super robuste , mais dorénavant c'est très compliqué à faire évoluer ( exemple : l'ihm d'éclipse).
Mais on trouve aussi beaucoups de Framework Java qui font parties des plus rapides du marché.
Ils sont en train d'ajouter le typage dans PHP qui vaut mieux continuer dans cette voie plutôt que rajouter un nouveau format. Certes, il est optionnel, mais en PHP 7.4 si on le met partout dans un fichier, ça devient grosso-modo un fichier P++, non ?
En tout cas, dans la discussion, quelqu'un propose de faire une TypeScript pour PHP, je ne sais pas si ça serait une bonne solution. J'utilise beaucoup TS en ce moment, ça ne m'empêche pas de faire du JS. Mais les contraintes ne sont pas les mêmes, car TS « simule » un langage objet pour un langage prototypé et ajoute le typage à un langage qui ne l'a pas, alors que PHP a déjà en grande partie tout ça.
Édit : je pense que ça sera non avec 0 - 46 en faveur du non.
Pour le typage, avec 7.4 on pourra typer les variables membres d'une classe (en plus des argumentions et le retour d'une fonction). Mais on peut pas typer une variable nouvellement déclarée dans le code.
Le problème de Zeev, le dév qui a proposé l'idée, c'est que c'est un conservateur extrême, qui préfère avoir deux langages plutôt que de briser la compatibilité entre deux versions de PHP. C'est un problème récurrent, illustré par exemple avec les shorts tags qui divisent totalement la core team. Les conservateurs et les progressistes se bloquent mutuellement, et vu que faut généralement 2/3 de Oui pour qu'une RFC soit acceptée, aucun changement en profondeur peut être fait.
A titre personnel, je pense qu'il faudrait pas hésiter à briser la compatibilité entre deux versions. Y'a une majorité de site tournant encore sous PHP5 (https://w3techs.com/technologies/details/pl-php/all/all), donc ça veut dire qu'ils ne peuvent, ou ne veulent déjà pas passer à la version 7, même si le changement se fait petit à petit (https://w3techs.com/technologies/history_details/pl-php)
Si on prend le framework Symfony, ils se mettent rapidement à jour, et ils sont par exemple en train de typer la totalité des fonctions (arguments + retour) pour la prochaine version (et ils demandent déjà PHP en 7.1 minimum pour la version 4).
La core team de PHP devrait donc pas hésiter à introduire des changements majeurs, car ceux qui veulent changer de version rapidement hésiteront pas à le faire. Ils pourraient également mettre en place un système ou une feature est dépréciée/non obligatoire pour une version majeure, et enlevée/rendue obligatoire la version d'après. Ca laisse donc plusieurs années pour changer le code.
Tant qu'ils sont pas prêt à faire ça, le langage ne pourra pas aller dans la bonne direction. Mais introduire le P++, dans sa forme actuelle, c'est foncer dans le mur. (Selon moi)
Il faudra voir ce qu'ils veulent pour PHP8. Briser la compatibilité sur des version 7.x aurait était une erreur. Par contre, sur une version majeur, je pense que c'est possible, mais il ne faut pas que ça soit comme certains langage où le gap est tellement grand qu'il fait tout réécrire. C'est un peu le problème de PHP, il y a tellement de site, et beaucoup sont sans framework ou avec des frameworks qui n'ont pas le communauté de Symphony. Il y a un équilibre à avoir, c'est c'est la que c'est compliqué.
Perso j'ai un site avec mon propre framework, pour l'instant je n'ai jamais vraiment eu beaucoup de boulot à chaque monté de version, les changements sont pour l'instant assez minimes (ou j'ai eu de la chance).
Chose amusante, Zeev a aussi voté contre.
Comme quoi, avoir une bonne discussion ça peut aider voire même faire changer d'avis
- PDO++ : Une nouvelle façon d'utiliser PDO. Billet de blog || Code source
- PhpEcho : Un moteur de rendu en une seule classe ! Nouvelle version (release 2.3.2) publiée le 18/04/2020 : Billet de blog || Code source
https://externals.io/message/106605
Si vous avez un peu de temps, je vous conseille de lire au moins les messages de Zeev, mais "changer d'avis" n'est pas vraiment l'expression que j'aurais employé.
Ce n'est pas une question de langage mais de développeurs. Il y a ceux qui actualisent leurs connaissances tout en bannissant le code déprécié et les autres.
Je crois que le seul problème de compatibilité que j'ai eu sur ma carrière de développeuse, c'est quand j'ai utilisé une fonctionnalité de la 7.3 et eu besoin de faire tourner le site sur un serveur en 7.1.
Just'une question pour les fanatiques du typage fort? Cela vous arrive combien de fois, par année, d'envoyer le mauvais type à une fonction, pour de vrai ?
Je conçois que lorsque l'on apprend un langage, le type peut-être une béquille importante. Mais par la suite, ce typage devient plus un poids qu'une commodité.
Ta question revient un peu à dire "vous vous crashez combien de fois par an en bagnole pour que ça justifie des limitations de vitesse ?"
Je vais d'ailleurs la retourner : si tu codes correctement, en quoi est-ce que le typage fort est un poids ?
Ca me rappelle l'époque où l'on débattait de s'il fallait conformer son code HTML aux règles W3C ou pas. Eh bien personnellement je ne me posais pas la question, je le rédigeais correctement instinctivement, donc par défaut il les respectait.
Sur du code en cours de développement, plusieurs fois par jour. En fait, à peu près autant que des tests unitaires qui échouent. Mais tu vas peut-être nous dire que ça aussi c'est inutile...
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager