Je connais pas beaucoup de choses en php, une lecture linière du morceaux de code (un langage non compilé contrairement à ASP NET), non orienté objet au début de son parcours.
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
Je connais pas beaucoup de choses en php, une lecture linière du morceaux de code (un langage non compilé contrairement à ASP NET), non orienté objet au début de son parcours.
Tu ne connais pas php et c'est pour cela que tu en profite pour donner ton avis ? Normal que ça te fasse malEnvoyé par Abdellah2010
Je connais pas beaucoup de choses en php, une lecture linière du morceaux de code (un langage non compilé contrairement à ASP NET), non orienté objet au début de son parcours.
Bonjour,
ll est toujours possible de compiler un code écrit dans un langage interprété si on recherche plus de performances.
Je me demande d'ailleurs si ce n'est pas facebook qui compilait ses pages PHP (?).
Sans aller dans HipHop utilisé par Facebook, qui peut rappeler à quoi servent les outils APC (et OPcache pour PHP 5.5), inclus dans la plateforme PHP pour ceux qui ne connaissent pas le fonctionnement de PHP ?
N'hésitez pas à consulter la FAQ Java, lire les cours et tutoriels Java, et à poser vos questions sur les forums d'entraide Java
Ma page Developpez | Mon profil Linkedin | Vous souhaitez me contacter ?Contacter Gokan EKINCI
Tout a fait, d'ailleurs ils en parle dans le lien que j'ai partagé dans un de mes précédent message (le diaporama sur Facebook). La performance n'est pas le seul critere de la compilation du code par Facebook, il y a de multiples avantages a faire cela.
Il y a 25 ans, un développeur a dit "Cobol est destiné à mourir". On voit ce qu'il en est aujourd'hui - la bestiole bouge encore et les profils de cobolistes sont très recherchés.
Si les langages (a fortiori un aussi bien implanté que PHP) mouraient rapidement de leurs défauts, ça se saurait.
Certains ont tendance a mélanger les langages de programmation Web avec les autres, je ne suis pas tout a fait d'accord.
Certaines entreprises comme dans la Finance développent des applications qui doivent durer au minimum des dizaines d'années, c'est pourquoi meme si le langage disparait petit a petit ces entreprises continueront a rechercher des profils pour continuer a maintenir cette application.
Dans le Web cette notion de durée est toute autre, on développe généralement un service qui peux percer aujourd'hui mais qui demain sera peut-etre abandonner, pour un effet de mode par exemple ou une concurrence trop farouche. Avec l'évolution des technologies Web il faut toujours remettre en question son application et les clients n'hésitent pas toujours a tout remettre et meme changer le langage si nécessaire.
Ce que représente PHP
71% des serveurs webs dans le monde sont sur OS Linux, avec Apache comme serveur web, et PHP comme serveur de langage de scripts servant d'interface avec MariaDB, MySQL ou PostgreSQL.
Il travaille pour quelle entreprise ce gars ?
Assez d'accord, si php n'évolue pas vers le multi thread, il va mourir. Aujourd'hui la puissance d'un serveur ce mesure au type de processeur et au nombre de coeurs : les évolutions du kernel linux sont bien en retard sur les nouvelles instructions, et quand on ne peut pas augmenter le nombre de thread utilisées dans son application, il ne reste plus qu'a passer à un autre language.
pthread est une avancée notable, mais il doit être implémenté sur une installation thread safe, qui n'est pas encore tout à fait stable, et qui est loin d'être le mode par défaut des installations de php sur les différentes distributions.
Par contre les fuites de mémoires on été largement réglées (il était temps).
Donc en gros, on attend et on croise les doigts.
Je crois que vous n'avez pas bien compris le sens de l'article original,
Quand l'auteur dit "PHP is meant to die" ça ne veut pas dire que c'est le langage qui est destiné à mourir. Il parle du fait que le workflow de php c'est la lecture des entrées, le process de ces données, et une sortie vers le client pour ensuite mourir. Car oui un procssus PHP est destiné a mourir
Je suggère à ce que cette discussion soit supprimé, étant donné que ça ne parle pas du vif sujet de l’article originale, et ça constitue un grand troll jamais publié sur ce forum, à moins que ce forum soit destiné aussi aux trolls.
C'est peut-être un peu radical, non ? D'autant plus que Uther a précisé les choses dès le début de la page 3 et que tes interventions sont situées après...
De mon côté, je reconnais que je n'avais pas pris le temps de lire l'article original avant de poster ma première réponse.
Faut dire quand même que la présentation de la news était assez longue et donc on pouvait supposer que l'essentiel avait été dit. Et en fait seuls les éléments ayant matière à troll on été repris en excluant ceux qui pouvaient les désamorcer... Alors bon faut pas vraiment s'étonner de la suite.
Après si l'on en revient par exemple sur le sujet des websocket, le sujet n'a pas l'air de rencontrer un intérêt primordial pour l'instant. Plusieurs technologies possibles, aucune définie comme un standard...
Y aura t-il finalement un standard reconnu et employé par la grande majorité des développeurs ou subsistera t-il plusieurs technologies concurrentes ?
Cette technologie est-elle amenée à être employée avantageusement pour d'autres applications web autres que celles auxquelles on pense logiquement actuellement (les jeux en lignes et les chats) ?
Je ne vois rien de radical. L'homme peut faire des erreurs, il peux oublier, il peux comprendre mal, c'est comme ça l'homme, alors quand on commet une erreur où est le problème de la rectifier? Si vous laissez les gens lire toute la discussion pour savoir que ça n'a rien n'avoir avec ce qu'on voulait dire, c'est que certaines personnes sont déjà perdu. Les erreurs on rectifie, le problème c'est de ne pas reconnaître qu'on a commis l'erreur. En tout je n'ai fais qu'une suggestion.
Code : Sélectionner tout - Visualiser dans une fenêtre à part %s/PHP/flash/g
En tout cas je reprend ce que dit une personne ici dans les commentaire, on est pas "facebook" ou "amazon", or facebook est écrit en php, le code à été réécris
Donc je pense que la mort du php est a revoir, je tourne sur mes serveur avec la même version que celle du site de facebook, qui on d'ailleurs fait un travaille énorme
Pour ceux que ça intéresse
http://fr.wikipedia.org/wiki/HipHop_for_PHP
https://github.com/facebook/hiphop-php/wiki
Bonjour, je fais du php depuis 10ans, langage simple rapide et efficace, le top ... sauf qu'il faut quand même l'admettre le synchrone c'est bien mais c'est quand même limité, on peut faire de l'ajax c'est sur mais cela ne rendra jamais le code php asynchrone, exemple de cas pratique qui me pousse à m'orienter vers d'autre langage
-Envoi mail, chargement fichier, etc .. : obligé d'attendre que le traitement se termine pour continuer le traitement (xhr qui renvoi un callback success en json)
La navigation ajax avec les ancres, un calvaire lors du refresh obligé d'attendre que la page se charge pour effectuer une redirection (ok l'html5 règle le pb mais pas sous IE)
etc etc etc ....
Du coup je me met activement à Angular & NodeJS (async, socketio) et franchement quel bonheur !! on peut tout faire et en asynchrone, cela demande une nouvelle gymnastique mais cela en vaut la chandelle.
Je ne pense pas que le PHP soit mort, mais plutôt que les langages synchrones auront beaucoup de mal à résister aux nouveaux développeurs en herbe qui souhaite utiliser des outils modernes, car il est peut probable qu'un dev qui bosse en asynchrones passe à du synchrones
(quel intérêt ?)
C'est sûr que l'asynchrone est intéressant pour certains usages mais de là à ce qu'il y ait une ruée vers l'or, cela me paraît beaucoup moins évident ou tout au moins cela va prendre un certain temps. Déjà il faudrait qu'un standard se dégage clairement et en second que cela ne consomme pas trop de ressources pour des besoins somme toute secondaires. Dans un premier temps il est fort probable que cela soit utilisé pour des besoins réels évidents tels que les chats ou les jeux en lignes.
Pour le reste, ce ne sont pas les développeurs en herbe qui orientent les choix technologiques et encore moins les futures normes.
Répondre avec citation
Partager