« PHP est destiné à mourir » pour un développeur
Les faiblesses du langage vont-elles le conduire vers sa fin ?

Le , par Stéphane le calme, Chroniqueur Actualités
Après plus d’une décennie d’expérience dans la programmation PHP, un développeur du nom de « Gunslinger » estime que les codes PHP ne pourront pas fonctionner éternellement.

Selon lui, ce modèle de programmation, notamment récupérer les données d’entrée, les traiter puis afficher la sortie est destiné à mourir. Il évoque par ailleurs les sites comme phpsadness.com qui exposent les incohérences linguistiques de PHP de « façon amusante ».

Pourtant, il reconnaît que le langage est difficile à battre dans la lecture de la base de données, l’application d’une logique ou le formatage de celle-ci, puis l’affichage d’un résultat au milieu de balises HTML. Mais la plupart des problèmes soulevés par la technique ont déjà été résolus et le reste est abordé avec des outils plus intelligents et plus modernes. Lorsque cela sera fait, PHP devrait être relégué au passé.

Pour lui, les applications complexes devraient se passer de PHP. Plus la complexité croît, plus les lignes de code s’agrandissent. S’adressant aux utilisateurs expérimentés de PHP 5.x, il fait remarquer qu’ils auront inévitablement besoin d’exécuter du code en arrière-plan. La demande pourrait atteindre un niveau de complexité tel qu’attendre une requête HTTP pour pouvoir faire quelque chose ne sera plus suffisant. Il faudrait alors par exemple prévoir un traitement des commandes en attente, ou encore mettre les informations dans le cache pour rendre un peu plus rapides les réponses HTTP. Une liste d’exemples de choses à prévoir qui n’en finit pas.

Le cauchemar devient encore plus effrayant lorsqu’il faut créer un daemon ou un processus qui ne meurt pas. Deux exemples seraient d’établir et maintenir une connexion WebSockets ou créer le composant producteur dans une implémentation producteur-consommateur.

« PHP vous abandonnera », déclare-t-il. D’abord à cause des fuites de mémoire, car le langage ne s’est jamais soucié de libérer de la mémoire non utilisée parce que tout est libéré à la fin de l’exécution du code. Dans le cadre d’un processus en continu, cela conduirait à l’augmentation de la taille de la mémoire allouée (ce qui revient à une perte de mémoire) jusqu’à ce que la valeur memory_limit de PHP soit atteinte et que le processus soit interrompu sans aucune autre forme de procès.

De plus, selon lui, PHP est plein d'erreurs cryptiques, difficiles à déboguer ou impossibles à reproduire. En guise d’exemple il parle d’une erreur que les utilisateurs aguerris de PHP ont déjà dû rencontrer :

Fatal error: Exception thrown without a stack frame in Unknown on line 0

Que traduit cette erreur ? Il affirme n’en avoir aucune idée et n’arrive même pas à trouver « la ligne # 0 dans un fichier PHP inconnu. Personne ne saurait dire ce qui provoque cette erreur. Toutefois, je peux vous donner les préconditions qui y conduiraient : des processus en cours en permanence, en collaboration avec une base de données d’une taille de l’ordre du giga-octet, sous forte charge/traitement, dans un environnement de production ».

Tous ces problèmes poussent Gunslinger à prédire la mort de PHP.

Source : blog Gunslinger

Et vous ?

Que pensez-vous de cette analyse ? Partagez-vous son point de vue ?

Pensez-vous que PHP soit destiné à mourir ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de Hesiode Hesiode - Membre régulier https://www.developpez.com
le 12/04/2013 à 14:36
C'est super facile de dire : "PHP c'est de la m..."
Mais je ne vois nulle part où il mentionne une solution de rechange..
Tant qu'il n'y aura pas de remplaçant, PHP n'est pas prêt de mourir..
Avatar de Grabeuh Grabeuh - Membre confirmé https://www.developpez.com
le 12/04/2013 à 14:47
Ah, l'article à troll du vendredi

3 choses :

1) la personne qui a écrit ce post de blog ne doit pas connaitre http://php.net/manual/fr/book.pthreads.php

2) je pense que Frédéric Hardy (qui est loin d'être une brèle dans la communauté PHP francophone) a suffisamment répondu dans ce post de blog là : http://blog.mageekbox.net/?post/2013...ci-les-faits-2

3) comme dit dans un précédent topic sur ce forum, la communauté PHP se débrouille toujours lorsqu'elle ne dispose pas de certains outils, et finit toujours par arriver à un résultat qui fonctionne.
On a pas de threads directement dans le langage ni de pools de connexions persistantes à des bases de données ?
Tant pis, on fait sans. On créera des daemons et autres workers qui communiqueront entre eux avec ZeroMQ pour remplir cette tâche.
Avatar de Merfolk Merfolk - Membre régulier https://www.developpez.com
le 12/04/2013 à 14:59
bonjour,

je suis développeur php (pro) depuis 7 ans : je ne suis pas d'accord

- c'est mondialement répandu, le plus utilisé / - "simple" - "gratuit" - "efficace", des milliers d'hébergeurs etc.. rien que pour cette raison, on a encore probablement toute notre vie devant nous avant que php ne trouve un remplaçant indiscutable

- php fonctionne très bien pour des petits sites, des sites de moyennes taille, tout ce qui est "blog" et des "boutiques"... tout ceci, ça existe, et ça existera toujours, de plus en plus même. Et ça représente énormément de "buisness" derrière. N'en déplaise à l'auteur. Tout le monde n'a pas la volumétrie de sites type "amazon" / "facebook"...avec des besoins d'importer 1 000 000 d'articles par heures ou autres.

- php est utilisable également pour des grand sites. Regardez http://www.ojd-internet.com/chiffres-internet, une bonne partie de ces sites, sont en php, et fonctionnement parfaitement. D'ici à ce que le quidam lambda dispose d'un site aussi riche & fréquenté, il y a une marge de manœuvre immensurable

- Il ne faut pas mélanger ce qui backoffice / front / tâches en cron. (php étant utilisable dans les 3)

- avant de partir dans le web, je travaillais sur un gros logiciel "erp" en c++
Aujourd’hui, je ne vois rien qui empêcherait de concevoir un backoffice équivalent à 99,9% , en pur php, fiable & stable.
Il ne faut pas oublier que le coeur de bcp de logiciels c'est : multitude de petits écrans de saisie + quelques "gros" récap... avec php on peut parfaitement faire toute la partie saisie... et "précalculer" par exemple, pour des grosses pages complexes (genre calendrier /stats des ventes / de l'année etc.).
Avatar de eomer212 eomer212 - Membre actif https://www.developpez.com
le 12/04/2013 à 15:15
oui, rien de plus, souvenez vous de ceux qui nous annonçaient la fin du monde..
et qui continuent irrégulièrement à foutre la trouille à tout le monde.(enfin pas tout le monde quand même, moi ca me met en colére..)

sérieusement, c'est qui d'abord ce quidam..??
ensuite, ses 'réflexions' prouvent qu'il est incapable d'imaginer penser autrement que le tout prédigéré pondu par les programmeurs des grands éditeurs.
on peut pas faire de threads persistants?? et ben on les chaine, pour qu'ils traitent une partie du boulot et passent la main au suivant, ça libère la mémoire à chaque fois et voila. de plus, ça garantit, en segmentant le travail, que même si un éventuel hypothétique plantage arrivait, le cron de vérification des taches pourrait reprendre à la dernière étape..
ha, cerise sur le gâteau, on peut même penser le travail a traiter pour lancer plusieurs threads en même temps, sur le même, ou sur differents serveurs.. mais pour ca, faut penser..
think differerent.. tiens, j'en prendrais presque le slogan d'apple..

ha, tiens, le "programmeur" en question, ca serait pas tout simplement un commercial de crosoft..?? c'est leur spécialité de lancer des trolls comme ca..
Avatar de grunk grunk - Modérateur https://www.developpez.com
le 12/04/2013 à 15:18
Mais la plupart des problèmes soulevés par la technique ont déjà été résolus et le reste est abordé avec des outils plus intelligents et plus modernes.

Donc un langage n'a lieu d'être que si il répond à une problématique nouvelle ou alors qu'il résoud les problème existant d'une meilleure façon. Du coup y'a un paquet de langage qui vont y passer aussi ^^

Plus la complexité croît, plus les lignes de code s’agrandissent.

Si il me propose un langage ou la taille du code est inversement proportionnel à la complexité du problème à résoudre , je promet je m'y met demain, quoi que ca risque d'être compliqué de faire un hello world ...

S’adressant aux utilisateurs expérimentés de PHP 5.x, il fait remarquer qu’ils auront inévitablement besoin d’exécuter du code en arrière-plan. La demande pourrait atteindre un niveau de complexité tel qu’attendre une requête HTTP pour pouvoir faire quelque chose ne sera plus suffisant. Il faudrait alors par exemple prévoir un traitement des commandes en attente, ou encore mettre les informations dans le cache pour rendre un peu plus rapides les réponses HTTP. Une liste d’exemples de choses à prévoir qui n’en finit pas.

Le cauchemar devient encore plus effrayant lorsqu’il faut créer un daemon ou un processus qui ne meurt pas. Deux exemples seraient d’établir et maintenir une connexion WebSockets ou créer le composant producteur dans une implémentation producteur-consommateur.

Le bon développeur c'est celui qui sait quelle sont les limites de son langage et quand il est nécessaire de passer la main à un autre programme. Ca me choque pas de voir un site php qui va aller lancer des routine c++ (par exemple) parce que c'est plus simple/plus performant de le faire ainsi.

Rendez vous est pris dans 5 ou 10 ans pour en rediscuter
Avatar de gbdivers gbdivers - Inactif https://www.developpez.com
le 12/04/2013 à 15:54
Citation Envoyé par Hesiode  Voir le message
Tant qu'il n'y aura pas de remplaçant, PHP n'est pas prêt de mourir..

Facile : le C++ !
(bon, ok, troll du vendredi...)
Avatar de Zefling Zefling - Membre émérite https://www.developpez.com
le 12/04/2013 à 15:55
On n'avait pas eu un discours similaire pour JS il y a quelques années ?
Avatar de CocoDesBois CocoDesBois - Membre à l'essai https://www.developpez.com
le 12/04/2013 à 16:08
Citation Envoyé par Merfolk  Voir le message
Aujourd’hui, je ne vois rien qui empêcherait de concevoir un backoffice équivalent à 99,9% , en pur php, fiable & stable.

J'ai un peu développé en PHP il y a 10 ans, donc je ne connais rien à ce langage.
Mais est ce qu'on peut faire en PHP pur un back office dont les infos des fenêtres se mettent à jour instantanement (qui écoute sur un tube par ex ou qui se fait appeler)? Je ne parle pas d'ajax qui push toutes les 2 secondes pour rafraichir le navigateur.
Avatar de Benjamin Delespierre Benjamin Delespierre - Expert éminent https://www.developpez.com
le 12/04/2013 à 16:16
« PHP vous abandonnera », déclare-t-il. D’abord à cause des fuites de mémoire, car le langage ne s’est jamais soucié de libérer de la mémoire non utilisée parce que tout est libéré à la fin de l’exécution du code. Dans le cadre d’un processus en continu, cela conduirait à l’augmentation de la taille de la mémoire allouée (ce qui revient à une perte de mémoire) jusqu’à ce que la valeur memory_limit de PHP soit atteinte et que le processus soit interrompu sans aucune autre forme de procès.

C'est faux depuis PHP 5.3 qui dispose d'un garbage collector. D'ailleurs vous seriez bien mal avisé de créer un daemon avec une version antérieure...
Avatar de aimad41 aimad41 - Membre régulier https://www.developpez.com
le 12/04/2013 à 16:46
Il faudrait déjà se rappeler la base de création du langage puis le contexte ! Un langage simple, dynamique mais surtout court, un process au lifetime court adapté au web, sans persistence hormis session, code métier court !

Je ne comprend pas quand on me demande de réaliser de gros traitements en php, le langage n'est pas fait pour supporter ce type de traitement, le contexte n'est pas le même, d'autres me diront peut être et le CLI tu connais ? Oui et c'est pas optimal non plus, bonjour les fuites, ou j'ai pas su faire malgré le GC bref on as créer d'autres langages pour ce type de traitement, python fonctionne très bien et adapté pour de la prog système, reseau.. (thread,process,signal,socket...) sans architecture tierce c'est compliqué oui
Offres d'emploi IT
Développeur php (H/F)
Vesperia - Nord Pas-de-Calais - Lille (59000)
Développeur Windows Mobile 3.5
SteepConsult - Ile de France - Paris Nord
ADMINISTRATEUR(TRICE) SYSTÈME H/F
PROXIMEDIA - Rhône Alpes - Lyon (69009)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil