Discussion :

[Uther]

J'ai l'impression que beaucoup viennent ici défendre leur langage chéri qui a été mis en cause par un méchant blogueur, sans avoir pris la peine de lire ledit blog.

L'auteur ne dit pas que "PHP is meant to die" dans le sens "le langage PHP doit mourir", mais qu'il a été conçu sur le modèle de "requêtes qui sont traitées puis meurent". Et que ce modèle est de moins en moins pertinent au moment ou les sites deviennent de plus en plus des applications complexes.

Il y a certes des moyen de contourner ce problème mais comme beaucoup des nouveautés en PHP, ça relève de la rustine supplémentaire, a un langage qui n'a pas été conçu pour ça.

[alex_vino]

Et la je ne parle pas du HTML5 qui est certes mieux, mais sans être aussi intéressant que le PHP

Attention a ne pas mélanger HTML5 et PHP

Parce qu'entre php4 et php5, on ne peut quand même pas dire qu'il ne s'est rien passé : un mode objet pratiquement complet, des classes et lib en tout genre : gestion des erreurs, support SQLite, fonctions sur les dates, filtres de nettoyage et validation, domdocument, SPL, PDO, namespace etc...

PHP 5 a... 9 ans. Si tu regardes Wikipedia ici tu remarqueras que ca reste bien léger, d'autant plus que tout cela est partie intégrante des langages concurrents.
Je ne critique pas le langage en lui-meme mais plutot son évolution lente, malgré une communauté gigantesque.

[Invité]

« PHP est destiné à mourir » -> Allez dire ça à Facebook, DailyMotion, ...

[Invité]

J'ai l'impression que beaucoup viennent ici défendre leur langage chéri qui a été mis en cause par un méchant blogueur, sans avoir pris la peine de lire ledit blog.

L'auteur ne dit pas que "PHP is meant to die" dans le sens "le langage PHP doit mourir", mais qu'il a été conçu sur le modèle de "requêtes qui sont traitées puis meurent". Et que ce modèle est de moins en moins pertinent au moment ou les sites deviennent de plus en plus des applications complexes.

Il y a certes des moyen de contourner ce problème mais comme beaucoup des nouveautés en PHP, ça relève de la rustine supplémentaire, a un langage qui n'a pas été conçu pour ça.

En même temps l'intitulé de la discussion amène un peu à ça...

[alex_vino]

« PHP est destiné à mourir » -> Allez dire ça à Facebook, DailyMotion, ...

Facebook comme beaucoup d'autres utilisent leurs propres implémentations ou surcouches de PHP, HipHop par exemple, idem pour la gestion des données.
Je trouve ce PowerPoint intéressant concernant facebook: (cliquer sur le lien/titre pour pouvoier le voir) [ame="http://www.slideshare.net/mozion/facebook-architecture-for-600m-users"]facebook architecture for 600M users[/ame]

[enneite2]

Par rapport à Java ou même à Python (si on veut comparer des langages de scripts) Il ne manque à PHP qu'une chose, une bonne gestion des threads .

Cela pourrait permettre d'avoir des Bootstrap se déclenchant uniquement au lancement du serveur et pas à chaque requête HTTP

Sinon, franchement on prend un framework type ZF, Django ou même Struts, et on retrouve quasiment les même structure MVC si chères au développement d'applications WEB.

Pour ce qui est de la mémoire en php, on peut la libérer quand on veut, même si tout est nettoyé à la fin du script.
D'ailleurs dans tous les langages de plus haut niveau que C / C++, le développeur n'a trop à se soucier des allocations mémoire (JAVA y compris)

Je pense qu'en SSII on préfère proposer du JAVA surtout parce que c'est un peu plus long de développer avec, donc on peut le facturer plus cher.

[Invité]

Facebook comme beaucoup d'autres utilisent leurs propres implémentations ou surcouches de PHP, HipHop par exemple, idem pour la gestion des données.
Je trouve ce PowerPoint intéressant concernant facebook: (cliquer sur le lien/titre pour pouvoier le voir) facebook architecture for 600M users

En effet pour facebook et très intéressant ce powerpoint. Cependant beaucoup de sites n'utilisent de surcouches et fonctionnent très bien : DailyMotion avec SF2, et beaucoup de sites pour adultes sachant que ce sont les plus visités du web je pense que la robustesse n'est plus à prouver et que PHP a encore de beaux jours devant lui.

[enneite2]

J'ai l'impression que beaucoup viennent ici défendre leur langage chéri qui a été mis en cause par un méchant blogueur, sans avoir pris la peine de lire ledit blog.

L'auteur ne dit pas que "PHP is meant to die" dans le sens "le langage PHP doit mourir", mais qu'il a été conçu sur le modèle de "requêtes qui sont traitées puis meurent". Et que ce modèle est de moins en moins pertinent au moment ou les sites deviennent de plus en plus des applications complexes.

Il y a certes des moyen de contourner ce problème mais comme beaucoup des nouveautés en PHP, ça relève de la rustine supplémentaire, a un langage qui n'a pas été conçu pour ça.

Oui mais des requêtes qui sont traitées puis meurent, c'est le principe des requêtes sans états du protocole HTTP 1.0 et même dans une moindre mesure de HTTP 1.1 , donc la remise en cause de ce système touche plus la conception du WEB en général que du langage PHP.
C'est ce qui a fait le succès du protocole HTTP d'ailleurs.

[Uther]

Oui mais PHP a été conçu à la base pour CGI qui fait qu'un programme meurt en même temps que la requête qu'il traite, ce qui n'est pas le cas d'autres technologies comme les servlets ou le même programme peux traiter toutes les requêtes.

[alassanediakite]

Salut
Uther, le titre dit: "PHP est destiné à mourir"!
C'est genres de critiques exagéré (guerre médiatique) ont deux objectifs:

1. faire perdre de la clientèle aux concurrents
2. ou se montrer expert de la chose pour avoir des contrats

C'est possible qu'il a perdu un contrat face à un concurrent ayant proposé PHP
Si le critiques est objectif chacun y a son compte.
@+

[enneite2]

Tant que PHP ne gèrera pas les threads, il sera dur de faire des servlets, par contre on peut utiliser PHP en Fast CGI que ce soit avec Apache, IWS ou bien Nginx ou lighthttpd, ce qui permet à PHP de gérer des pool de requêtes HTTP.

Pour Apache, en terme de performance pour un site à traffic moyen , c'est du kif-kif. Cela devient intéressant, quand le serveur arrive au bout de ses limites. Apache lorsqu'il est au max des requêtes qu'il peut traiter assumera plus facilement la charge avec PHP - Fast CGI plutôt que PHP en module.
L'autre avantage est de pouvoir coupler PHP avec lighthttpd ou nginx plutôt qu'Apache.
Mais actuellement les architectures LAMP sont quand même les plus répandues.

[gene69]

Biensur que PHP va mourrir. le 19-01-2038.

Ensuite on va rire.

Tout à une fin. Ce forum à une fin. Internet à une fin. L'humanité à une fin. Le monde à une fin. Le soleil à une fin. L'univers à une fin... Et PHP mourra comme cobol, comme le b ...

http://fr.wikipedia.org/wiki/Liste_d..._programmation

[la.lune]

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.

[coolspot]

J'ai l'impression que beaucoup viennent ici défendre leur langage chéri qui a été mis en cause par un méchant blogueur, sans avoir pris la peine de lire ledit blog.

L'auteur ne dit pas que "PHP is meant to die" dans le sens "le langage PHP doit mourir", mais qu'il a été conçu sur le modèle de "requêtes qui sont traitées puis meurent". Et que ce modèle est de moins en moins pertinent au moment ou les sites deviennent de plus en plus des applications complexes.

Il y a certes des moyen de contourner ce problème mais comme beaucoup des nouveautés en PHP, ça relève de la rustine supplémentaire, a un langage qui n'a pas été conçu pour ça.

Ben en même temps le titre de la news c'est "Le PHP est destiné à mourrir". Après peut être que le blog en anglais est différent mais bon ici on commente la news de développez.

Après si la news sur developpez n'a rien à voir avec l'article, là il faut s'en prendre au staff de developpez.com

[coolspot]

Facebook comme beaucoup d'autres utilisent leurs propres implémentations ou surcouches de PHP, HipHop par exemple, idem pour la gestion des données.
Je trouve ce PowerPoint intéressant concernant facebook: (cliquer sur le lien/titre pour pouvoier le voir) facebook architecture for 600M users

Ben euh comme JAVA. Tu fais pas des application JAVA from scratch (hibernate/ibatis, struts/jsf, etc...)

[Uther]

Ben en même temps le titre de la news c'est "Le PHP est destiné à mourrir". Après peut être que le blog en anglais est différent mais bon ici on commente la news de développez.

Après si la news sur developpez n'a rien à voir avec l'article, là il faut s'en prendre au staff de developpez.com

La news n'a pas rien à voir avec l'article mais elle reprend le titre volontairement accrocheur de l'article, mais pas l'explication de texte qui arrive juste après, ce qui change complètement le ton:

It doesn’t mean that a perfectly capable (to some extent) programming language will disappear into nothingness, it just means that your PHP code can’t run forever.

Pour moi avant de critiquer quelqu'un, il est quand même essentiel de se reporter a son texte original, surtout quand il est disponible d'un clic et pas seulement au "on m'a dit que".
D'autant plus que les news de developpez.com ressemblent malheureusement de plus en plus a du lancer de troll. Certes, le trolling permet de rapporter de visites en période d'activité creuse, mais c'est triste de devoir en arriver là.

[alex_vino]

Pour moi avant de critiquer quelqu'un, il est quand même essentiel de se reporter a son texte original, surtout quand il est disponible d'un clic et pas seulement au "on m'a dit que".

Oui mais le probleme c'est que si on ne peux plus faire confiance a l'auteur de la news alors il n'y a aucun intéret a lire quelque chose de mal interprété voir d'erroné.
De plus en lisant la news on n'a pas toujours envie de lire sa source qui est presque un copier-coller.
Par ailleurs peut-etre que l'auteur de la source a lui aussi pris ses informations d'un autre auteur, celle-ci venant encore d'un autre auteur, etc... Si pour toi on doit en arriver a ce stade alors il faut se cultiver ailleurs avec des journalistes digne de confiance et impartiaux.

D'autant plus que les news de developpez.com ressemblent malheureusement de plus en plus a du lancer de troll. Certes, le trolling rapporte permet de rapporter de visites en période d'activité creuse, mais c'est triste de devoir en arriver là.

C'est aussi l'amer constat que je fais
Mais la philosophie de dvp.com est davantage la quantité de posts a la qualité, quand je recherche une information technique je vais directement sur StackOverflow. Ce serait bien qu'un principe similaire soit mis en place sur dvp.com, meme si je l'accorde c'est extremement difficile, mais je pense que les résultats serait bien meilleurs. En tout cas ils peuvent compter sur leur communauté le jour ou dvp.com prendra enfin un second souffle

@coolspot: Et comme Ruby et .Net aussi, ce que je voulais dire c'est que dans certaines technologies ca coule de source mais en PHP pas toujours.

[Yoteco]

Je pense qu'en SSII on préfère proposer du JAVA surtout parce que c'est un peu plus long de développer avec, donc on peut le facturer plus cher.

Haha, superbe argumentation

[zecreator]

... il me semble vivant plus que jamais pourtant. Et si PHP meurt, combien de sites vont mourir avec lui ?

A moins de les repasser en JSP.... Ho non, pire, en .NET. Ha ouais, le cauchemard, ça foût les chocottes.

[enneite2]

Haha, superbe argumentation

Pour les projets WEB, je ne vois pas trop l'intérêt de se lancer dans JAVA, sauf dans certains cas particulers où JAVA est très utilisé dans le SI de l'entreprise et encore ...

Après les "ingénieurs commerciaux" des SSII entre leur pensée et leur argumentation client...