IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

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

Langage PHP Discussion :

« PHP est destiné à mourir » pour un développeur


Sujet :

Langage PHP

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Mars 2013
    Messages
    9 628
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : Mars 2013
    Messages : 9 628
    Par défaut « PHP est destiné à mourir » pour un développeur
    « PHP est destiné à mourir » pour un développeur,
    Les faiblesses du langage vont-elles le conduire vers sa fin ?

    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 ?
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre très actif
    Inscrit en
    Mars 2006
    Messages
    126
    Détails du profil
    Informations forums :
    Inscription : Mars 2006
    Messages : 126
    Par défaut
    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..

  3. #3
    Inactif  


    Homme Profil pro
    Inscrit en
    Novembre 2008
    Messages
    5 288
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Secteur : Santé

    Informations forums :
    Inscription : Novembre 2008
    Messages : 5 288
    Par défaut
    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...)

  4. #4
    Membre confirmé Avatar de Grabeuh
    Homme Profil pro
    Développeur Web
    Inscrit en
    Février 2009
    Messages
    114
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2009
    Messages : 114
    Par défaut
    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.

  5. #5
    Membre confirmé Avatar de Merfolk
    Profil pro
    Inscrit en
    Juillet 2003
    Messages
    170
    Détails du profil
    Informations personnelles :
    Âge : 45
    Localisation : France

    Informations forums :
    Inscription : Juillet 2003
    Messages : 170
    Par défaut
    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.).

  6. #6
    Membre du Club
    Homme Profil pro
    Inscrit en
    Avril 2012
    Messages
    10
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Avril 2012
    Messages : 10
    Par défaut
    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.

  7. #7
    Expert confirmé
    Avatar de Benjamin Delespierre
    Profil pro
    Développeur Web
    Inscrit en
    Février 2010
    Messages
    3 929
    Détails du profil
    Informations personnelles :
    Âge : 38
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Février 2010
    Messages : 3 929
    Par défaut
    « 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...

  8. #8
    Membre très actif
    Profil pro
    Inscrit en
    Juillet 2010
    Messages
    657
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Juillet 2010
    Messages : 657
    Par défaut
    Citation Envoyé par CocoDesBois Voir le message
    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.
    PHP n'est pas fait pour tout , mais ce qu'il fait , il le fait relativement bien. PHP reste un langage pour créer des web apps et quelques scripts , la ou les autres solutions sont plus "generalistes". j'ai vu des projets écrits 100% en python (même le serveur , les bus de messageries ,etc ... ).

    En même temps il est bien plus facile de créer une app de moyenne taille avec .net , python/django/flask , ruby/rails/sinatra voir js/node qu'en pure PHP , c'est clair ... le problème pour certains c'est l'investissement de départ.

    Honnêtement , avec tout le code PHP déployé de par le monde , je ne me fais pas de soucis pour PHP , qui évoluera de toute façon. Plutot que de crier "PHP must die" , ferait mieux d'écrire un billet sur comment on peut l'améliorer.

    je pense par exemple à l'abandon du templating par défaut.
    ainsi au lieu d'ouvrir un tag <?php pour écrire du php , un fichier php serait un fichier script par défaut sans sortie automatique, l'utilisateur devant utiliser un tag de sortie ?> si il veut écrire du HTML ou autre, cela serait une bonne idée.

    De plus , l'abandon du $ serait une bonne chose , ya plus rien qui justifie encore ça en 2013.

    Enfin le nettoyage de toute les fonctions à _ , et la création d'une API objet stricte. Les utilisateurs pourront toujours utiliser des méthodes statiques pour appeler leurs fonctions favorites : Reg::match() , ou Array::sort() ...

  9. #9
    Membre Expert
    Avatar de Seb33300
    Homme Profil pro
    Développeur Web
    Inscrit en
    Janvier 2007
    Messages
    1 564
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : Thaïlande

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Janvier 2007
    Messages : 1 564
    Par défaut
    Citation Envoyé par CocoDesBois Voir le message
    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.
    Ce n'est pas vraiment un problème lié à PHP, puisque ça sera la même problématique pour n'importe quel autre langage web coté server.

    Par contre coté client, grace au nouvelles fonctionalités HTML5 et notamment aux websocket, on devrait pouvoir arriver à quelque chose qui y ressemble.

  10. #10
    Membre du Club
    Homme Profil pro
    Inscrit en
    Avril 2012
    Messages
    10
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Avril 2012
    Messages : 10
    Par défaut
    Citation Envoyé par Seb33300 Voir le message
    Ce n'est pas vraiment un problème lié à PHP, puisque ça sera la même problématique pour n'importe quel autre langage web coté server.

    Par contre coté client, grace au nouvelles fonctionalités HTML5 et notamment aux websocket, on devrait pouvoir arriver à quelque chose qui y ressemble.
    Mon message (sorti de son contexte) ne concernait pas PHP en lui même, mais le fait que l'on puisse dire que PHP permettait de développer tous les back office, c'était un commentaire d'un précédent message.
    Il existe des BO qui nécessite un client lourd, PHP ne couvre pas ce domaine, on ne peut donc pas l'utiliser pour développer tous les BO.
    Et ce détail n'a aucun rapport avec le fait que PHP soit destiné à mourir ou pas.

  11. #11
    Membre très actif
    Homme Profil pro
    Développeur Web
    Inscrit en
    Mars 2011
    Messages
    154
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ariège (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Mars 2011
    Messages : 154
    Par défaut
    Citation Envoyé par CocoDesBois Voir le message
    Mon message (sorti de son contexte) ne concernait pas PHP en lui même, mais le fait que l'on puisse dire que PHP permettait de développer tous les back office, c'était un commentaire d'un précédent message.
    Il existe des BO qui nécessite un client lourd, PHP ne couvre pas ce domaine, on ne peut donc pas l'utiliser pour développer tous les BO.
    Et ce détail n'a aucun rapport avec le fait que PHP soit destiné à mourir ou pas.
    Au contraire, il répond exactement à ta question, on voit bien que Seb33300 connais bien ce type de problématique et que toi, tu poste n'imp sur un sujet auquel tu ne comprend strictement rien. La preuve est dans sa réponse: "une fenêtre qui se met à jour toute seule n'est pas un problème d'un langage serveur, c'est côté client que ça se joue". Toi tu réponds à ça un truc complètement à côté de la plaque. Va jouer dans le sandbox STP

  12. #12
    Membre très actif
    Profil pro
    Développeur indépendant
    Inscrit en
    Août 2004
    Messages
    377
    Détails du profil
    Informations personnelles :
    Âge : 56
    Localisation : France

    Informations professionnelles :
    Activité : Développeur indépendant
    Secteur : Transports

    Informations forums :
    Inscription : Août 2004
    Messages : 377
    Par défaut c'est son point de vue, et rien de plus
    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..

  13. #13
    Modérateur
    Avatar de grunk
    Homme Profil pro
    Lead dév - Architecte
    Inscrit en
    Août 2003
    Messages
    6 693
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Lead dév - Architecte
    Secteur : Industrie

    Informations forums :
    Inscription : Août 2003
    Messages : 6 693
    Par défaut
    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
    Pry Framework php5 | N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  14. #14
    Membre éprouvé Avatar de Zefling
    Homme Profil pro
    Développeur Web
    Inscrit en
    Avril 2007
    Messages
    1 224
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Avril 2007
    Messages : 1 224
    Par défaut
    On n'avait pas eu un discours similaire pour JS il y a quelques années ?

  15. #15
    Membre très actif
    Avatar de la.lune
    Homme Profil pro
    Directeur Technique
    Inscrit en
    Décembre 2010
    Messages
    548
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Comores

    Informations professionnelles :
    Activité : Directeur Technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Décembre 2010
    Messages : 548
    Par défaut
    Citation Envoyé par grunk Voir le message

    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 ...
    Sans pour autant être pour l'article mais je ne pense pas que c'est ça ce qu'il voulait dire par là. La suite après la phrase
    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 question ce n'est pas que les lignes de codes n'évoluent pas proportionnellement avec la complexité du problème dans les autres lagunages plus performants et plus matures, mais en comparaison avec php le coefficient de proportionnalité n'est pas le même. Avec php le coefficient est plus grand par ce que ça demande d'autres efforts supplémentaires en comparaison avec d'autres plus matures. Ces derniers permettraient d'écrire moins de ligne de code pour résoudre le même problème.

  16. #16
    Membre confirmé
    Inscrit en
    Octobre 2006
    Messages
    123
    Détails du profil
    Informations forums :
    Inscription : Octobre 2006
    Messages : 123
    Par défaut
    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

  17. #17
    Membre averti
    Homme Profil pro
    Analyste développement logiciel
    Inscrit en
    Novembre 2012
    Messages
    14
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Analyste développement logiciel
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2012
    Messages : 14
    Par défaut
    Que pensez-vous de cette analyse ? Partagez-vous son point de vue ?
    Que PHP ait de grosses lacunes, n'est une surprise pour personne. Au moins une fois par semaine, je râle sur son manque de rigueur et, parfois, les priorités des développeurs de PHP semblent impénétrables.
    Néanmoins le langage a aussi d'énormes qualités dans son domaine et est dans de très bonnes mains, j'ai vraiment confiance dans leur façon de mener la barque PHP dans le futur.
    Je me demande si une véritable cassure façon Python 3 ne serait pas profitable pour nettoyer certains héritages du passé un peu lourds. Mais c'est un jeu très dangereux, d'ailleurs j'ai l'impression que Python en a perdu des plumes (si j'ose dire )

    Pensez-vous que PHP soit destiné à mourir ?
    Si j'ai bien compris, "PHP est destiné à mourir", est un jeu de mot pour dire qu'il doit se terminer pour libérer la mémoire et qu'il ne peut pas tourner en continu. Sinon PHP a encore de longues et belles années devant lui, et ce, même avec les changements que HTML5 va provoquer dans les paradigmes de programmation.

  18. #18
    Membre Expert Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    Avril 2002
    Messages
    4 701
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : Avril 2002
    Messages : 4 701
    Par défaut
    Citation Envoyé par Zefling Voir le message
    On n'avait pas eu un discours similaire pour JS il y a quelques années ?
    Et je pense que c'est tout a fait logique car ils souffrent à peu près du même défaut : ce sont des langages faciles et très peu stricts, qui ont été conçus pour de problématiques simple. Ils ont été massivement appris par les débutants, très souvent en autodidacte et qui on voulu l'adapter au fur et à mesure à des problèmes toujours plus complexes. Le Basic rentre aussi tout à fait dans cette famille de langages.

    Il en résulte des langages qui peuvent, il est vrai, presque tout faire, mais, au prix de beaucoup de bidouillages qui conduisent souvent a pas mal d'inconsistances.

  19. #19
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par Uther Voir le message
    Et je pense que c'est tout a fait logique car ils souffrent à peu près du même défaut : ce sont des langages faciles et très peu stricts
    Encore une fois, JS n'est pas un langage facile, loin de là. L'orientation prototype ou sa gestion des scopes par exemple sont très mal compris par la plupart des développeurs JS.
    La réputation qu'a JS d'être facile est ce qui mène les développeurs à ne pas se donner la peine de le comprendre et à se plaindre après que le comportement de leur programme n'est pas celui voulu.

  20. #20
    Membre averti
    Homme Profil pro
    Développeur Web
    Inscrit en
    Avril 2012
    Messages
    55
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Avril 2012
    Messages : 55
    Par défaut
    Tous les autres langages que PHP sont destinés à mourrir.
    Je suis développeur, vous pourrez faire une news sur mon post vendredi prochain.

    PS : En effet, en lisant l'article en question en Anglais c'est beaucoup moins trollesque que ce qu'on pourrait penser, et le jeu de mot "PHP is meant to die" est tout à fait pertinent. Pour un processus destiné à tourner H24 PHP n'est clairement pas adapté (il n'est tout simplement pas fait pour ça).

Discussions similaires

  1. Les outils vraiment utiles pour les développeurs PHP
    Par RideKick dans le forum EDI, CMS, Outils, Scripts et API
    Réponses: 5
    Dernier message: 14/06/2017, 18h10
  2. Quel salaire pour un développeur PHP certifié Zend ?
    Par WebDream dans le forum Salaires
    Réponses: 11
    Dernier message: 02/10/2009, 17h13
  3. Réponses: 0
    Dernier message: 08/09/2009, 18h34

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo