Le langage PHP enfin disponible en version 7.0

Le langage PHP enfin disponible en version 7.0

Comme quoi, un Half-Life 3 reste possible

Avatar de l'auteur
Vincent Hermann

Publié dans

Logiciel

04/12/2015 3 minutes
165

Le langage PHP enfin disponible en version 7.0

Après plusieurs reports, la version finale de PHP 7.0 est désormais disponible pour tous les développeurs. Les deux grands axes d’amélioration du langage se situent sur la modernisation et surtout sur les performances. Un gros dépoussiérage attendu de pied ferme contre un ASP.NET devenu dangereusement concurrentiel avec le temps.

PHP 7.0 se veut avant tout beaucoup plus rapide que l’actuelle mouture 5.6, dont la révision 16 est disponible depuis le 26 novembre. En fonction évidemment des cas de figure, les performances peuvent ainsi être doublées. La nouvelle mouture 3 du Zend Engine est désormais compatible avec le 64 Bits et de nombreuses erreurs fatales lors de la compilation sont maintenant gérées comme des exceptions. Par ailleurs, la consommation de mémoire vive est annoncée comme significativement moindre.

Le langage a été également dépoussiéré et débarrassé de certaines « vieilleries », notamment d’anciennes extensions et SAPI (Server Application Programming Interface) qui n’étaient plus supportées. La modernisation se fait sur les possibilités offertes aux développeurs, avec en particulier le support des classes anonymes, l’ajout des opérateurs « null coalescing » et de comparaison combinée ou encore la prise en charge des déclarations de types de retour et scalaires. PHP 7.0 dispose aussi d’un arbre syntaxique abstrait, d’une hiérarchie améliorée des exceptions ainsi que d’un nouveau générateur de nombres aléatoires décrit comme sécurisé.

On rappellera que cette version 7.0 a mis un peu trop longtemps à arriver. Une version 6.0 était bien prévue initialement, mais des désaccords profonds sur la direction à prendre avaient finalement conduit à son abandon. De fait, PHP 7.0 arrive tard et devra notamment faire face à un ASP.NET chez Microsoft qui, au contraire, a beaucoup accéléré depuis deux ans. Signalons par exemple que la version 5, presque terminée, peut fonctionner depuis un serveur Linux grâce au .NET Core. En outre, il a fallu huit Release Candidates avant d'en arriver à la version finale, le site officiel indiquant que la compatibilité avec la version 1.0.2e d'OpenSSL a demandé plus de temps que prévu.

Mais le gain de performances avec le nouveau Zend Engine ouvre également une compétition avec la machine virtuelle HHVM, créée initialement par Facebook pour accélérer ses propres pages et disponible sous licence PHP. Il y a quelques semaines, le site Phoronix avait réalisé des tests pour suivre l’avancement du projet, et PHP 7.0 montrait non seulement d’indéniables progrès face à son précurseur, mais il distançait HHVM dans la plupart des cas, à l'exception notable de la consommation de mémoire vive.

Comme toujours, la dernière version de PHP pourra se récupérer depuis la page officielle des téléchargements.

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Fermer

Commentaires (165)


Votre conclusion est un peu mal tournée, pas de notion de temps, depuis 1 an les 2 font jeu égal



“il se faisait distancer par HHVM dans la plupart des cas.”

 http://www.phoronix.com/scan.php?page=article&item=php7-hhvm310-perf&…


“Comme quoi, un Half-Life 3 reste possible”

Ce troll <img data-src=" />


&nbsp;Hors cadre précis : prestashop, wordpress, quels sont maintenant les atous de PHP face à l’ouverture d’ASP.NET 5 et/ou node.js ?


Half-life 3 est codé en php ? <img data-src=" /><img data-src=" />


PHP 7. C’est différent.


Alléluia mes frères !








ooasix a écrit :



&nbsp;Hors cadre précis : prestashop, wordpress, quels sont maintenant les atous de PHP face à l’ouverture d’ASP.NET 5 et/ou node.js ?





Ce n’est pas la même chose, je ne crois pas qu’ASP.NET soit opensource d’une part, et node.js est un framework javascript parmi d’autre même s’il peut remplacer PHP et se passer d’Apache



<img data-src=" />&nbsp;pour le sous-titre !&nbsp;<img data-src=" />


J’ai modifié la fin&nbsp;<img data-src=" />


ASP.NET est bien open source&nbsp;








Zyami a écrit :



Ce n’est pas la même chose, je ne crois pas qu’ASP.NET soit opensource d’une part, et node.js est un framework javascript parmi d’autre même s’il peut remplacer PHP et se passer d’Apache





Asp.net est en train (ou vient) de passer en open source, et node.js est bien un environnement d’exécution d’un langage qui permet notamment de faire du serveur web dynamique. Comme php.









brazomyna a écrit :



Asp.net est en train (ou vient) de passer en open source, et node.js est bien un environnement d’exécution d’un langage qui permet nitamment de faire du serveur web dynamique. Comme php.





Oui mais asp.net ne fonctionnera pas partout, node.js si, (je travaille actuellement dessus avec NWJS), concernant php, il me semble avoir vu passer des exécutables afin de faire

des appli autonome avec BdD (le successeur de Nightrain dont je ne

retrouve plus le lien).



Et oui tu as raison, node.js est plus qu’un simple framework, c’est quasi un environement serveur à lui tout seul.



Reste python et Django que je ne maîtrise pas encore.



Enfin :) Il était temps !








Vincent_H a écrit :



ASP.NET est bien open source&nbsp;





Ho purée, j’étais sûr que c’était open source mais pas libre pour autant et après avoir cherché un poil, c’est sous licence Apache 2.0. C’est plus c’que s’était Microsoft !

&nbsp;



Bon, la grosse question c’est : faut-il faire des modifications de code pour profiter des performance de PHP7 avec un site codé avec PHP5?


Maintenant on attends les bench des sites spécialisés :)


La petite réponse c’est RTFM :http://php.net/manual/en/migration70.php <img data-src=" />




node.js est un framework javascript parmi d’autre

pardon ? &gt;&lt;


J’ai regardé vite fait, il ne semble pas y avoir grand chose de “deprecated”, au doigt mouillé ça ne devrais pas oser trop de problème.

Je vais tester avec un ou deux projets pour voir.<img data-src=" />


Ou java…








Zyami a écrit :



Oui mais asp.net ne fonctionnera pas partout encore.






    Si.          






    Après je ne faisais que rectifier ce qui me semblait incorrect ; ça n'empêche pas que pour moi non plus, Asp.net, NodeJS et PHP ce n'est pas la même chose.          

&nbsp;

Typiquement, un élément technique open-source n'implique pas pour autant qu'on a aussi l'environnement voir l'écosystème associés qui sont aussi open source ; et ce n'est clairement pas encore le cas chez Microsoft (rien qu'un outil de base comme l'IDE...), donc dans le cadre de mes petites pérégrinations techniques personelles, ce serait un formidable retour en arrière que d'adopter ce genre de techno (pour le boulot c'est autre chose: poids de l'existant, contraintes tierces, etc... on ne choisit pas une techno parce qu'elle a une bonne gueule ou qu'elle est plus attirante à un instant T).






    NodeJS est extrêmement intéressant et est l'option qui m'attire le plus en ce moment, et pas que pour des problématiques purement web, ça va bien au delà. Et même si on se cantonne juste au domaine du web, le fait d'avoir un langage unique (et les données, et...) côté serveur et côté client est un atout majeur comparé au PHP.          






    Reste PHP, qui a essentiellement pour lui les connaissances accumulées pendant les années, et l'incroyable bibliothèque de ressources à son actif.          






    Bref, si je devais résumer, pour moi:          

- php est une techno vieillissante, mais dont la base installée est énorme.

- nodeJs est l'étoile montante

- ASP.Net reste pour moi un truc "pseudo-proprio avec une vitrine open-source" tant que tout le reste de l'écosystème n'a pas migré.

&nbsp;

&nbsp;


Les personnes qui disent que Node.js est un framework !&nbsp;<img data-src=" />

Vous êtes sérieux ? …&nbsp;

&nbsp;

On parle d’un langage de bas niveau, et non d’un cadre de travail…








brazomyna a écrit :



Bref, si je devais résumer, pour moi:



   - php est une techno vieillissante, mais dont la base installée est énorme.        

- nodeJs est l'étoile montante

- ASP.Net reste pour moi un truc "pseudo-proprio avec une vitrine open-source" tant que tout le reste de l'écosystème n'a pas migré.

&nbsp;

&nbsp;







Je suis tout a fait d’accord avec toi brazomyna !&nbsp;<img data-src=" />



Le sous titre ! <img data-src=" />








TaCosS a écrit :



Je suis tout a fait d’accord avec toi brazomyna !&nbsp;<img data-src=" />






 Ca tombe bien, parce que moi je suis tout à fait d'accord avec le fait que tu sois tout à fait d'accord avec moi&nbsp;<img data-src=">  











TaCosS a écrit :



Les personnes qui disent que Node.js est un framework !&nbsp;<img data-src=" />



 Vous êtes sérieux ? ...&nbsp;       



On parle d’un langage de bas niveau, et non d’un cadre de travail…





Je plussoie. Perso, je me sers de NodeJs notamment pour:

&nbsp;




  • me concocter des chaines de ‘build’ ou de traitement pour des trucs qui ne sont pas en JS (typiquement de la génération automatisée de doc, de la collecte/aggrégation de data, du reporting, des outils de “continuous integration”, …)



    &nbsp;- faire ce qu’on fait d’habitude avec des scripts ‘bash’ (que je faisait déjà non plus en bash mais en PHP-CLI depuis quelques années, la syntaxe bash, j’ai jamais pu m’y faire).



    &nbsp;- faire du soft ‘serveur’ (genre communication bas niveau TCP temps réel)



    &nbsp;- et accessoirement … développer un peu de web (mais c’est pas ma passion)



L’avantage énorme de PHP est surtout qu’on peut apprendre des bases vite fait bien fait et se faire son site sans problème et l’héberger n’importe où. Tant qu’il permettront ça, ils seront devant. S’ils obligent à utiliser le gros potentiel (full OOP etc.), ils perdront clairement du monde en route.

&nbsp;

Node.js est super mais trop complexe pour un dev non pro (a priori, j’ai juste regardé de loin, reboot l’app tout le temps pour les modifs - on m’a dit ici qu’il y avait des parades je sais - mais ça reste un peu velu pour le quidam et les hébergeurs sont encore un peu rares).

ASP.net, ben pour les anciens, on ne peut s’empêcher de se dire que c’est le mal&nbsp;<img data-src=" />








Zyami a écrit :



Oui mais asp.net ne fonctionnera pas partout









brazomyna a écrit :



Si.







Pour préciser: Installing ASP.NET 5 On Linux (doc officielle Microsoft)



&gt; De fait, PHP 7.0 arrive tard et devra notamment faire face à un ASP.NET chez Microsoft qui, au contraire, a beaucoup accéléré depuis deux ans.



Bof… Pour moi, ils ne sont carrément pas en compétition car ils ne visent pas du tout le même marché. Ou du moins, les utilisateurs ne les utilisent pas pour les même raisons.


Reste Django. C’est du python, un langage super simple, c’est complet, tu peux commencer en lisant le tutoriel (en une demi journée c’est torché) et ça fonctionne partout aussi.

Et pas besoin de relancer la machine quand tu fais une modif, ça le fait tout seul.








jul a écrit :



L’avantage énorme de PHP est surtout qu’on peut apprendre des bases vite fait bien fait et se faire son site sans problème et l’héberger n’importe où. Tant qu’il permettront ça, ils seront devant.






  PHP n'est plus parfaitement adapté dès lors qu'on pense au web comme autre chose que des sites composés de pages ; genre les "single page applications (gmail, ...)", la comm bidirectionnelle genre websocket, les frameworks style Angular, les webservices, le REST, etc...        



&nbsp;



  Pour moi, ce qui fera tomber PHP à long terme c'est le virage que prend tout doucement (mais inévitablement) le web vers cette plus grande place laissée à la notion "d'application web", même si celle existante de "sites web" n'est pas vouée à disparaître pour autant.    

&nbsp;

&nbsp;

&nbsp;








ErGo_404 a écrit :



Reste Django. C’est du python, un langage super simple, c’est complet, tu peux commencer en lisant le tutoriel (en une demi journée c’est torché) et ça fonctionne partout aussi.

Et pas besoin de relancer la machine quand tu fais une modif, ça le fait tout seul.





Ou son cousin, Ruby on Rails ;)

Perso je suis passé de PHP à Ruby il y a 4 ans, pour rien au monde je ne ferai machine arrière pour du développement web.

Je vous invite tous à regarder les tutos Rails, franchement ça change la vie de développeur web !









Keoregh a écrit :



Ou son cousin, Ruby on Rails ;)

Perso je suis passé de PHP à Ruby il y a 4 ans, pour rien au monde je ne ferai machine arrière pour du développement web.

Je vous invite tous à regarder les tutos Rails, franchement ça change la vie de développeur web !









Ruby c’est cool mais tant que les hébergeurs industriels comme OVH ne proposeront pas d’espace à 4 balles par mois sur des mutus pour deployer des applis en Ruby, ca ne décollera pas.

Et c’est pareil pour n’importe quelle autre techno.



Normalement sauf si t’as encore du code PHP 4, non.


On est loin de l’a simplicité de l’installation de PHP sous Linux.


Je viens d’écrire un livre sur le sujet:

http://www.editions-eni.fr/livres/apprendre-a-developper-un-site-web-avec-php-et…

Effectivement, c’est bien plus performant mais on peut enfin typer les paramètres des fonctions. Les autres nouveautés sont assez marginales.








zefling a écrit :



On est loin de l’a simplicité de l’installation de PHP sous Linux.





C’est de l’ordre de la complexité de suivre pas à pas un tutoriel.

&nbsp;

Pour un truc qui n’était ni open-source ni exécutable ‘partout’ il y a 20 commentaires, ça fait déjà un sacré gap.



“Un&nbsp;langage de programmation&nbsp;est dit de&nbsp;bas niveau&nbsp;lorsque le codage de celui-ci se rapproche du&nbsp;langage machine&nbsp;(dit «&nbsp;binaire&nbsp;»), et donc permet de programmer à un degré très avancé. Les langages de bas niveau sont à opposer aux&nbsp;langages de haut niveau, qui permettent de créer un programme sans tenir compte de la façon dont fonctionne le matériel de l’ordinateur censé exécuter le programme.”&nbsp;En quoi nodeJS est un langage de bas niveau ? Je n’ai fais qu’un projet dessus, mais il me semble plus un langage de haut niveau.&nbsp;








brazomyna a écrit :



PHP n’est plus parfaitement adapté dès lors qu’on pense au web comme autre chose que des sites composés de pages ; genre les “single page applications (gmail, …)”, la comm bidirectionnelle genre websocket, les frameworks style Angular, les webservices, le REST, etc…

 



  Pour moi, ce qui fera tomber PHP à long terme c'est le virage que prend tout doucement (mais inévitablement) le web vers cette plus grande place laissée à la notion "d'application web", même si celle existante de "sites web" n'est pas vouée à disparaître pour autant.









Autant je valide totalement l’ampleur que vont prendre ces “nouvelles technos” autant le “web classique” est pas prêt de disparaître non plus :)



Je vois plus d’ajout que de remplacement.









blackdream a écrit :



En quoi nodeJS est un langage de bas niveau ?





Effectivement, le Javascript est un langage de haut niveau. Je pense qu’il voulait surtout opposer la notion de langage et la notion de framework.

&nbsp;



A mon avis c’est la fin pour PHP, les types qui cherchaient des perfs sont partis depuis longtemps sur des langages “concurrents” et plus “modernes”, et je vous invite pour votre santé mentale à éviter de jeter un œil au code de PHP7. SInon, j’en vois beaucoup se plaindre dans les commentaires de l’absence “d’hebergeur” node.js… vous êtes sérieux ?&nbsp;








jeliel a écrit :



Autant je valide totalement l’ampleur que vont prendre ces “nouvelles technos” autant le “web classique” est pas prêt de disparaître non plus :)



Je vois plus d’ajout que de remplacement.





C’est pour ça qu’il m’a paru nécessaire de préciser “même si celle existante de “sites web” n’est pas vouée à disparaître pour autant”.

&nbsp;

Reste que l’utilisation du “web” est désormais de plus en plus large, et de nouveaux besoins font très régulièrement leur apparition. Tu prends par exemple la masse énorme d’applications mobile natives qui vont faire des requêtes HTTP pour aller chercher telle ou telle info ; elle a besoin d’un serveur “type web” qui lui répond en face.

Alors je suis d’accord qu’on parle là du “web” dans un sens très global, on devrait plus parler de technos au dessus du HTTP, mais la réalité des besoins évolue largement vers ça aussi.

&nbsp;



La dessus je suis un peu mitigé, en soit le langage ça reste JavaScript non ? ou les deux ont pris des directions différentes au niveau du langage ?

Je vois plus nodeJS comme un framework orienté serveur que comme un langage totalement différent de JS. &nbsp;








blackdream a écrit :



Je vois plus nodeJS comme un framework orienté serveur que comme un langage totalement différent de JS. &nbsp;






  Non: nodeJs est juste une machine d'exécution du javascript.        

C'est ni plus ni moins que l'équivalent d'une JVM pour le langage JAVA.






 D'ailleur la landing page du site de Node l'explique très bien:       







Node.js® is a JavaScript runtime built on Chrome’s V8 JavaScript engine. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient. Node.js’ package ecosystem, npm, is the largest ecosystem of open source libraries in the world.









ooasix a écrit :



Hors cadre précis : prestashop, wordpress, quels sont maintenant les atous de PHP face à l’ouverture d’ASP.NET 5 et/ou node.js ?





ASP.NET ou Php j’aurais tendance à dire que les deux pourraient être condamné en web. Le front devient de plus en plus Javascript only. Et le backend on utilise des technos performantes. Javascript avec nodeJs peut faire son trou la aussi ou alors d’autres langages comme Go, Scala et autre.









brazomyna a écrit :





  • ASP.Net reste pour moi un truc “pseudo-proprio avec une vitrine open-source” tant que tout le reste de l’écosystème n’a pas migré.

    &nbsp; &nbsp;





    Belle tentative de troll&nbsp;<img data-src=" />









seb2411 a écrit :



ASP.NET ou Php j’aurais tendance à dire que les deux pourraient être condamné en web. Le front devient de plus en plus Javascript only. Et le backend on utilise des technos performantes. Javascript avec nodeJs peut faire son trou la aussi ou alors d’autres langages comme Go, Scala et autre.







Node.js, pour moi, c’est une défécation de développeur front qui avait besoin de bricoler 2 ou 3 trucs en back avec ses maigres compétences en développement de qualité.

Rien que le choix de js est carrément dégueulasse. Y’a pas d’autre mot. L’absence quasi complète d’outils de gestion de la qualité pour ce langage le disqualifie directement pour toute utilisation autre que faire des zigouigouis jolis sur une page web.









brazomyna a écrit :



Bref, si je devais résumer, pour moi:



     - php est une techno vieillissante, mais dont la base installée est énorme.          

- nodeJs est l'étoile montante

- ASP.Net reste pour moi un truc "pseudo-proprio avec une vitrine open-source" tant que tout le reste de l'écosystème n'a pas migré.

&nbsp; &nbsp;







&nbsp;Je suis obligé de mettre mon grain de sel là dedans ;)







  • PHP est une techno vieillissante, MAIS qui cherche activement son renouveau.&nbsp;

  • NodeJS existe surtout pour répondre a une demande du marché : faciliter l’émergence d’un maximum de dev full stack.

  • ASP.Net termine sa mutation chrysalide -&gt; papillon. Juste pour moduler ton propos, il est totalement possible et réaliste de créer et déployer une application Asp.Net sans toucher au moindre outil proprio.&nbsp;





    Pour finir , je pense que l’ensemble des langages / plateformes de tradition web convergent tous les mêmes objectifs, et qu’au final seuls ceux pouvant répondre a l’appel des SPA finiront par subsister.



    &nbsp;









Xarkam a écrit :



Belle tentative de troll&nbsp;<img data-src=" />





Quand on dit “pour moi c’est ceci cela”, après avoir argumenté et pondéré les raisons qui nous poussent à penser ça, c’est tout sauf un troll <img data-src=" />



Le Troll, pour l’occasion, c’est le comm de KP2 qui suit le tiens (don’t feed <img data-src=" />)

&nbsp;

&nbsp;



Bah jusqu’à que quelqu’un développe un outil de gestion de la qualité.&nbsp;



Tu as l’air d’avoir la haine contre le JS, et contre les développeurs front…&nbsp;


Bonne nouvelle ! Y’a plus qu’à tester <img data-src=" />


Au risque de te contredire sur l’ecosystème, Visual Studio Code est open source et permet de développer des applis web en ASP.Net.



Et concernant le “troll” sur Node.js, KP2 &nbsp;a quand même raison sur la question de qualité.

Javascript n’est pas un modèle en matière de langage fortement typé.

Quand tu programmes côté serveur, tu as quand même des contraintes de qualité, de sécurité et de fiabilité.

Si le langage que tu utilises n’est pas capable de te signaler que le contenu que tu veux mettre dans une variable n’est pas du bon type (que ces oit à la compilation comme à l’exécution), par exemple, c’est quand même un peu problématique…


“Petit joueur”



Dit t’il let point net :)








P-A a écrit :



PHP est une techno vieillissante, MAIS qui cherche activement son renouveau.



&nbsp;



Je ne dis pas le contraire, mais à l'heure où on a de plus en plus besoin d'échanger des données entre le serveur et le client (et plus seulement de générer du code HTML dans des pages, pour caricaturer), PHP est moins adapté 'by design' qu'une solution qui propose un homogénéité entre le côté client et le côté serveur.      






&nbsp;      







P-A a écrit :



NodeJS existe surtout pour répondre a une demande du marché : faciliter l’émergence d’un maximum de dev full stack



J’y ai partiellement répondu juste avant: on ne parle pas tant de “full stack” que de “code pour le front, côté client + côté serveur”. Le full stack c’est autre chose.



&nbsp;   Node est arrivé parce que plus ça avance, plus ou met de la logique et du code JS dans les pages, et qu'avoir un langage (et des types de données, des sérialisations, etc...) côté serveur différent de celui côté client est moins efficient.   



&nbsp;







P-A a écrit :



Juste pour moduler ton propos, il est totalement possible et réaliste de créer et déployer une application Asp.Net sans toucher au moindre outil proprio.&nbsp;






&nbsp;J'ai pas parlé d'impossibilité (j'ai moi-même corrigé pour expliquer que si, ASP est open source et tourne sous nunux) ; je parle d'écosystème, d'outils, et lâchons le mot de "philosophie".      






C'est une question d'intégration globale de l'ensemble des outils, et tant que la généricité et l'ouverture n'est pas intégrée dans la façon même dont sont pensés les choix techniques, ça ne peut pas coller pour moi  






Pour faire un parallèle:       

- un développeur d'un outil sous linux pensera d'abord à faire un exécutable pilotable en ligne de commande, et ajoutera éventuellement ensuite un deuxième outil pour proposer une IHM graphique (optionnelle) au dessus pour l'utilisation dans un environnement graphique.

- un développeur d'un outil sous windows pensera par défaut à faire un logiciel unique avec en premier lui une interface graphique pour le piloter, et éventuellement quelques options pour faire les fonctions basiques en ligne de commande.






(mylife) Exemple concret très précis que j'ai vécu il y a encore moins de 24 heures: trouve moi un moyen d'extraire de façon automatisée une liste des fichiers (disons au format CSV) impactés par de changesets fait dans un repository TFS pour tel ou tel user, ou telle ou telle collection de work items. Réponse: ce n'est pas impossible, mais c'est très complexe, car il faut aller fouiner dans des outils complémentaires (TFS powerTools) où taper de la requête TSQL à la mano dans la base de TFS, avec tout le côté rtisanal que ça implique. (m/mylife)      

&nbsp;

Pour moi le dev un tant soit peu pro, il a besoin de pouvoir automatiser un maximum de choses, faire communiquer ses outils ensembles, etc... Pas parce que c'est un barbu intégriste de VI, mais parce que au final ça fait gagner énormement de temps.

&nbsp;

&nbsp;








adrenalinedj a écrit :



Au risque de te contredire sur l’ecosystème, Visual Studio Code est open source et permet de développer des applis web en ASP.Net.





Quid du support natif dans les IDE et autres outils habituels de développement dans le système Gnu/Linux ?



Bonne nouvelle. me reste plus qu’à tester








brazomyna a écrit :



&nbsp;[…] un barbu intégriste d’emacs […]&nbsp;&nbsp;





<img data-src=" /><img data-src=" />









<img data-src=" />









hurd a écrit :



Quid du support natif dans les IDE&nbsp;et autres outils habituels de développement dans le système Gnu/Linux&nbsp;?





C’est aussi multiplateforme.

Et le support natif d’ASP.Net dans un IDE tiers, n’est-ce pas à la charge du développeur de l’IDE ?



On ne demande pas à l’équipe de dév de PHP, par exemple, d’apporter le support en natif dans tous les IDE…



allez on rajoute une couche de complexité pour les dev&nbsp;

(entre vielles les versions bd qui sont plus supporté les frameworks qui nécessite au moins la version X (souvent 5.3 ) ça devient un joyeux bordel de developer en php et de moderniser certaine appli)








maestro321 a écrit :



Bon, la grosse question c’est : faut-il faire des modifications de code pour profiter des performance de PHP7 avec un site codé avec PHP5?







Pour un hello world non pour des choses un peu plus spécifique , oui c’est possible









adrenalinedj a écrit :



C’est aussi multiplateforme.

Et le support natif d’ASP.Net dans un IDE tiers, n’est-ce pas à la charge du développeur de l’IDE ?





Bien évidemment, mais tant que la technologie ne sera pas bien diffusé, ça paraitra toujours “comme” un truc propriétaire .









adrenalinedj a écrit :



Javascript n’est pas un modèle en matière de langage fortement typé.



 Quand tu programmes côté serveur, tu as quand même des contraintes de qualité, de sécurité et de fiabilité.







C’est assez rigolo de parler de ça dans un article sur PHP, qui a justement démarré en étant super faiblement typé, ce qui en a fait une de ses forces (à l’époque, le PHP a émergé parce que c’était infiniment plus simple que les CGI codés en C). <img data-src=" />

&nbsp;

Au delà, pour travailler dans l’informatique financière, je peux t’assurer que la qualité, la sécurité, et la fiabilité sont infiniment moins une question de choix de tel ou tel langage que de process de développement logiciel.

&nbsp;

&nbsp;









ErGo_404 a écrit :



Reste Django. C’est du python, un langage super simple, c’est complet, tu peux commencer en lisant le tutoriel (en une demi journée c’est torché) et ça fonctionne partout aussi.

Et pas besoin de relancer la machine quand tu fais une modif, ça le fait tout seul.







Perso ce qui me gene le plus dans le python c’est l’indentation je suis plus habitué et préfère les accolades (humour: Free huis)









hurd a écrit :



Bien évidemment, mais tant que la technologie ne sera pas bien diffusé, ça paraitra toujours “comme” un truc propriétaire .





En tout cas, ils se donnent les moyens &nbsp;d’être “hype” pour les dev webs “modernes”.

Il suffit de regarder les langages supportés: &nbsphttps://code.visualstudio.com/docs/languages/overview

Sans compter, que depuis le dernier update, on peut créer des extensions pour supporter plus de langages.

Et pour les fans de Node.js, Visual Studio c’est du Node.js









adrenalinedj a écrit :



Pour les fans de Node.js, Visual Studio * CODE c’est du Node.js





<img data-src=" />




    Visual Studio c'est Visual Studio.         



&nbsp;



   Visual Studio Code, c'est une base d'Atom adaptée, un peu comme s'ils avaient pris Notepad++ ou PSPad pour leur rajouter des plugins par au-dessus.       






  Ce sont deux produits différents.        

&nbsp;

&nbsp;

&nbsp;








blackdream a écrit :



Bah jusqu’à que quelqu’un développe un outil de gestion de la qualité. 



Tu as l’air d’avoir la haine contre le JS, et contre les développeurs front…







Non, c’est pas de la haine contre les devs mais un peu contre js.

JS est un très mauvais langage. Le problème est quand un dev se forme avec ce truc, il ne peut carrément pas devenir un bon dev. Ni au niveau pratique (gestion de la qualité, gestion du cycle de vie du code, etc) ni au niveau théorique (le js est vraiment du bricolage).

Pour moi, les devs front sont les nouveaux flashers… D’ailleurs, c’est pas pour rien si une proportion non négligeable de flashers se sont reconvertis la dedans. Ca doit leur rappeler le bon vieux temps.







P-A a écrit :



[*]NodeJS existe surtout pour répondre a une demande du marché : faciliter l’émergence d’un maximum de dev full stack.







Le problème est que le JS est quand meme pas le meilleur dénominateur commun entre le front et le back… je dirais meme que c’est le pire.



Et puis, pour moi, c’est une Arlésienne de vouloir absolument unifier les choses. Les technos qui font papa-maman soit sont bonnes nulles part soit elles pechent forcement qqpart.

Je pense qu’il n’y a pas de mal a avoir des technos differentes pour des besoins different. L’important est d’avoir des interfaces de qualité.







brazomyna a écrit :



Quand on dit “pour moi c’est ceci cela”, après avoir argumenté et pondéré les raisons qui nous poussent à penser ça, c’est tout sauf un troll <img data-src=" />

Le Troll, pour l’occasion, c’est le comm de KP2 qui suit le tiens (don’t feed <img data-src=" />)







Je valide :)









brazomyna a écrit :



C’est assez rigolo de parler de ça dans un article sur PHP, qui a justement démarré en étant super faiblement typé, ce qui en a fait une de ses forces (à l’époque, le PHP a émergé parce que c’était infiniment plus simple que les CGI codés en C). <img data-src=" />

&nbsp;



Au delà, pour travailler dans l'informatique financière, je peux t'assurer que la qualité, la sécurité, et la fiabilité sont infiniment moins une question de choix de tel ou tel langage que de process de développement logiciel.     

&nbsp;

&nbsp;







Travaillant aussi dans l’informatique finanicère, je peux t’assurer que nous ne travaillons pas avec des langages qui n’assure pas un minimum de sureté : les enjeux financiers, derrière les traitements réalisés par les outils, sont autrement plus importants que le process de développement.









brazomyna a écrit :



<img data-src=" />




   Visual Studio c'est Visual Studio.        

Visual Studio Code, c'est une base d'Atom adaptée, un peu comme s'ils avaient pris Notepad++ pour lui rajouter des plugins par au-dessus.






 Ce sont deux produits différents.       

&nbsp;

&nbsp;

&nbsp;







Oups merci d’avoir corrigé la coquille.

Je parlais bien de Visual Studio Code.









brazomyna a écrit :



Au delà, pour travailler dans l’informatique financière, je peux t’assurer que la qualité, la sécurité, et la fiabilité sont infiniment moins une question de choix de tel ou tel langage que de process de développement logiciel.







Tout à fait.

Mais autant l’ecosysteme (tant au niveau outils, que process, que formation des professionnels aux process et aux outils) sont très forts dans le monde Java par exemple.

Autant sur PHP, c’est encore assez faiblard (mais ca s’améliore).

Mais alors, autour du JS, c’est le néant absolu. C’est la foire a la bricole…



Aujourd’hui, aucun editeur ou entreprise sérieux ne peut raisonnablement basé un développement professionnel sur une stack js.









brazomyna a écrit :



PHP n’est plus parfaitement adapté dès lors qu’on pense au web comme autre chose que des sites composés de pages ; genre les “single page applications (gmail, …)”, la comm bidirectionnelle genre websocket, les frameworks style Angular, les webservices, le REST, etc…



&nbsp;      

Pour moi, ce qui fera tomber PHP à long terme c'est le virage que prend tout doucement (mais inévitablement) le web vers cette plus grande place laissée à la notion "d'application web", même si celle existante de "sites web" n'est pas vouée à disparaître pour autant.

&nbsp;

&nbsp;

&nbsp;





voir aussi &nbsphttps://unhosted.org/ par exemplehttps://laverna.cc









brazomyna a écrit :



&nbsp;



 Je ne dis pas le contraire, mais à l'heure où on a de plus en plus besoin d'échanger des données entre le serveur et le client (et plus seulement de générer du code HTML dans des pages, pour caricaturer), PHP est moins adapté 'by design' qu'une solution qui propose un homogénéité entre le côté client et le côté serveur.       






 &nbsp;       

J'y ai partiellement répondu juste avant: on ne parle pas tant de "full stack" que de "code pour le front, côté client + côté serveur". Le full stack c'est autre chose.

&nbsp; Node est arrivé parce que plus ça avance, plus ou met de la logique et du code JS dans les pages, et qu'avoir un langage (et des types de données, des sérialisations, etc...) côté serveur différent de celui côté client est moins efficient.



&nbsp;






 &nbsp;J'ai pas parlé d'impossibilité (j'ai moi-même corrigé pour expliquer que si, ASP est open source et tourne sous nunux) ; je parle d'écosystème, d'outils, et lâchons le mot de "philosophie".       






 C'est une question d'intégration globale de l'ensemble des outils, et tant que la généricité et l'ouverture n'est pas intégrée dans la façon même dont sont pensés les choix techniques, ça ne peut pas coller pour moi       






 Pour faire un parallèle:        

- un développeur d'un outil sous linux pensera d'abord à faire un exécutable pilotable en ligne de commande, et ajoutera éventuellement ensuite un deuxième outil pour proposer une IHM graphique (optionnelle) au dessus pour l'utilisation dans un environnement graphique.

- un développeur d'un outil sous windows pensera par défaut à faire un logiciel unique avec en premier lui une interface graphique pour le piloter, et éventuellement quelques options pour faire les fonctions basiques en ligne de commande.






 (mylife) Exemple concret très précis que j'ai vécu il y a encore moins de 24 heures: trouve moi un moyen d'extraire de façon automatisée une liste des fichiers (disons au format CSV) impactés par de changesets fait dans un repository TFS pour tel ou tel user, ou telle ou telle collection de work items. Réponse: ce n'est pas impossible, mais c'est très complexe, car il faut aller fouiner dans des outils complémentaires (TFS powerTools) où taper de la requête TSQL à la mano dans la base de TFS, avec tout le côté rtisanal que ça implique. (m/mylife)       

&nbsp;

Pour moi le dev un tant soit peu pro, il a besoin de pouvoir automatiser un maximum de choses, faire communiquer ses outils ensembles, etc... Pas parce que c'est un barbu intégriste de VI, mais parce que au final ça fait gagner énormement de temps.

&nbsp;

&nbsp;







Sauf que t’es carrément à côté de la plaque à nous comparer un langage destiné au web et des applis standalone.



Donc oui, tu troll effectivement en étant déjà hors sujet selon ta vision qui se base sur des choix technique!!!



Alors si je comprend bien, je met asp.net + net.core sur linux et là tu ose venir nous lâcher que parce que les outils de dev (et ici tu vise directement visualstudio entre autre), ne sont pas libres alors ca ne te convient pas .



T’es bien positionné pour décrocher la médaille olympique du foutage de gueu{0}!





De vrai bon IDE sont en très grande majorité payant. Et encore, VS est free to use sous certaines conditions tant qu’on ne fait pas 1M€ de bénéfices/an par exemple.

Mais si tu veux du “mylife”, pour moi plutôt crever que d’encore utiliser Eclipse une fois que j’ai eu IntelliJ.

Quelle IDE de merde avec son support js plus que hasardeux, le support de jboss foireux à souhait, ect….



De toute manière sous linux c’est principalement VI avec une foultitude de plugins pour avoir un peux d’aide au dev comme on en trouve dans les IDE.



Tu dois surement être le seul à vouloir dev des appli web pour &nbsp;Lynx alors&nbsp;<img data-src=" />



Vous pouvez tjr suivre thetyne sur livecoding.tv qui développe une app avec ASP.NET 5 et voir qu’il ont encore pas mal de taff chez ms pour que ca soit fonctionnelle :)



Ca dépend de l’usage.



Si on ne veut pas trop se prendre la tête pour trouver des développeurs pour un gros projet, PHP est une bonne option.

Tandis que Node.JS peut être à considérer pour un projet full-JS, ou pour un projet avec une grosse montée en charge.



Il y a une multitude de points qui peuvent pencher en faveur de tel ou tel langage. Même si elles restent importantes, les questions de performances ne prédominent plus le débat avec l’existence de proxys inverses.


Justement si avec l’ouverture du .NET Framework les application ASP.NET peuvent être exécutée sur des machines Windows, Linux et Mac.








KP2 a écrit :



Aujourd’hui, aucun editeur ou entreprise sérieux ne peut raisonnablement basé un développement professionnel sur une stack js.



Oui et non:






Effectivement, j’ai vu tes réponses plus loin&nbsp;<img data-src=" />

&nbsp;

Sans vouloir lancer de débat sémantique stérile, je réitère mon avis sur l’utilité de NodeJS, bien que dev full stack puisse prendre un autre sens de nos jours. Je parle simplement du profil qui cherche les entreprises aujourd’hui, à savoir quelqu’un capable d’aller de l’alpha à l’oméga d’un projet, et on ne peut pas dire que node ne soit pas un bon candidat à l’émergence de ce type développeur.





Je vois ou tu veux en venir, et c’est là ou je ne suis pas d’accord : Utiliser un produit MS, c’est forcément adhérer à leur philosophie (et à toute leur panoplie d’outils). Mais justement, .net core apporte ce changement.

Voici ce que j’ai pu noter comme évolutions (philosophiques) notables au cours des dernières &nbsp;années :





  • &nbsp;Ils sont passés du forçage complet de Codeplex (et donc de TFS), à l’intégration de svn puis de git sur la plateforme, pour au final pousser les gens vers github.

  • Quand auparavant on était plus ou moins poussé vers TFS pour la gestion de projet, on est maintenant libre d’utiliser l’outil qui nous semble le plus adapté.

  • A l’époque d’Entity Framework 4, il était compliqué d’avoir des providers sérieux pour les autres BDD. Pour EF 7, ils travaillent main dans la main avec les dev de postgresql (et d’autres).

  • Si Docker était sorti il y a une dizaine d’année, ils n’auraient même pas pris la peine d’étudier quoique ce soit autour du produit. Aujourd’hui, ils poussent tant qu’ils peuvent à son utilisation.





    Pour finir, c’est une vraie cassure avec l’ancienne stratégie, et je pense qu’ils sont assez clair la dessus : si tu utilises .net, tu peux utiliser ce que tu veux comme écosystème, et si tu utilises des produits MS en complément, c’est pas par obligation, mais simplement parce que tu penses qu’ils sont au dessus des concurrents.

    &nbsp;








brazomyna a écrit :



Oui et non:












P-A a écrit :



Effectivement, j’ai vu tes réponses plus loin&nbsp;<img data-src=" />

&nbsp;

Sans vouloir lancer de débat sémantique stérile, je réitère mon avis sur l’utilité de NodeJS, bien que dev full stack puisse prendre un autre sens de nos jours. Je parle simplement du profil qui cherche les entreprises aujourd’hui, à savoir quelqu’un capable d’aller de l’alpha à l’oméga d’un projet, et on ne peut pas dire que node ne soit pas un bon candidat à l’émergence de ce type développeur.





Je vois ou tu veux en venir, et c’est là ou je ne suis pas d’accord : Utiliser un produit MS, c’est forcément adhérer à leur philosophie (et à toute leur panoplie d’outils). Mais justement, .net core apporte ce changement.

Voici ce que j’ai pu noter comme évolutions (philosophiques) notables au cours des dernières &nbsp;années :

&nbsp;Ils sont passés du forçage complet de Codeplex (et donc de TFS), à l’intégration de svn puis de git sur la plateforme, pour au final pousser les gens vers github.Quand auparavant on était plus ou moins poussé vers TFS pour la gestion de projet, on est maintenant libre d’utiliser l’outil qui nous semble le plus adapté.A l’époque d’Entity Framework 4, il était compliqué d’avoir des providers sérieux pour les autres BDD. Pour EF 7, ils travaillent main dans la main avec les dev de postgresql (et d’autres).Si Docker était sorti il y a une dizaine d’année, ils n’auraient même pas pris la peine d’étudier quoique ce soit autour du produit. Aujourd’hui, ils poussent tant qu’ils peuvent à son utilisation.

Pour finir, c’est une vraie cassure avec l’ancienne stratégie, et je pense qu’ils sont assez clair la dessus : si tu utilises .net, tu peux utiliser ce que tu veux comme écosystème, et si tu utilises des produits MS en complément, c’est pas par obligation, mais simplement parce que tu penses qu’ils sont au dessus des concurrents.

&nbsp;





Tout à fait d’accord.

Et d’ailleurs, c’est un peu la philosophie de Satya Nadella, dans d’autres domaines (comme le mobile), que de s’ouvrir aux autres même si c’est “timide” pour l’instant.









P-A a écrit :



Je parle simplement du profil qui cherche les entreprises aujourd’hui, à savoir quelqu’un capable d’aller de l’alpha à l’oméga d’un projet, et on ne peut pas dire que node ne soit pas un bon candidat à l’émergence de ce type développeur.






 Sur ce point précis je te rejoins, mais pour moi, l'entreprise penchera souvent en priorité pour une techno où elle trouvera facilement des gens à embaucher ; et effectivement en l'état, NodeJS n'est pas (encore) à son avantage: il y a trop peu de compétences NodeJS sur le marché de l'emploi (dans l'info de gestion notamment) ; ça devrait évoluer sur le long terme (10-15 ans, comme pour PHP ?). A ce titre, le PHP ou J2EE est - au jour d'aujourd'hui - bien plus répandu.     






 &nbsp;





P-A a écrit :



Mais justement, .net core apporte ce changement.



 &nbsp;








 Pour moi, .Net Core apporte un début, une promesse de changement à étendre au reste de l'écosystème.  






&nbsp;Ca rejoint ce que je disais dans mon premier comm:       

&nbsp;







brazomyna a écrit :





  • ASP.Net reste pour moi un truc “pseudo-proprio avec une vitrine open-source” * tant que tout le reste de l’écosystème n’a pas migré





Heroku quoi


Il fut un temps où je codais mon propre CMS basé sur mon propre framework basé lui-même sur le Zend Framework.



Aujourd’hui, avec notamment l’essor de Wordpress et des autres CMS libres, j’ai du mal à me replonger dans un dev perso extrêmement chronophage alors qu’il me “suffit” aujourd’hui de faire juste des plugins et des thèmes pour couvrir une grande majorité des besoins…








adrenalinedj a écrit :



Euh en même temps, c’est pas difficile de faire plus performants que Java…



(Désolé pour le demi-troll)







Les perfs, 99% du temps on s’en tape, c’est très rarement un critère de choix prépondérant dans le milieu pro: sauf cas spécifiques, acheter des serveurs 30% plus puissants a un coût dérisoire comparé au coût d’une équipe de développement à la journée.

&nbsp;









brazomyna a écrit :



Les perfs, 99% du temps on s’en tape, c’est très rarement un critère de choix prépondérant dans le milieu pro: sauf cas spécifiques, acheter des serveurs 30% plus puissants a un coût dérisoire comparé au coût d’une équipe de développement à la journée.



&nbsp;







30% plus puissants c’est aussi de la conso électrique, …

C’est du matériel en plus à administrer, héberger, maintenir.



Et les perfs, c’est justement un critère de choix pour les pros, notamment dans l’informatique financière que tu citais….









adrenalinedj a écrit :



Et les perfs, c’est justement un critère de choix pour les pros, notamment dans l’informatique financière que tu citais….






    Hors HFT et quelques autres besoins très spécifiques, non.          

&nbsp;

Chez nous, on tripote une centaine de milliards 364 jours par an, et la totalité du hard + coûts induits sur lequel ça tourne ne coûte pas le prix d'une semaine de ce qu'on facture juste pour les coûts bruts des dev. + testeurs.






    &nbsp;


Je me demande dans quel monde vivent ceux qui parlent de la mort du PHP.



Dans le milieu de l’entreprise, celui qui détermine le succès d’un langage, pour les entreprises lambda (i.e. pas les banques, brockers…), ce n’est pas demain la veille du jour où le PHP ne sera pas souvent le choix le plus indiqué en dehors d’usages très spécifiques. Facile à mettre en place, facile de trouver des devs, langage historique difficile à remplacer pour les entreprises existantes, suffisamment puissant, fiable et disposant d’assez d’outils pour répondre aux besoins avec un coût de dev raisonnable.



Les perfs sont un critère de moins en moins important en dehors d’usages spécifiques, la puissance des serveurs ayant très largement augmenté en même temps que leur coût a baissé ces dernières années, et ça sature souvent coté SQL bien avant de saturer coté PHP.



Quant aux applis de plus en plus basées coté client, il faut toujours un coté serveur pour donner à manger à ces clients et le PHP fait très bien le job, et est là aussi souvent tout indiqué puisqu’on implémente ça sur des applis existantes en PHP.



Ce n’est pas parce qu’il existe un langage qui a vos yeux est mieux ou plus moderne qu’il est en pratique plus adapté et qu’il devrait être adopté sans délai par les entreprises.








adrenalinedj a écrit :



30% plus puissants c’est aussi de la conso électrique, …

C’est du matériel en plus à administrer, héberger, maintenir.



Et les perfs, c’est justement un critère de choix pour les pros, notamment dans l’informatique financière que tu citais….





mais non tu loues du serveur sur azur ou amazon je pense que tu rendre dans les 1% des cas avec ton&nbsp;informatique financière car 1&nbsp;millième de seconde pour l’affichage d’une page web n’est pas forcement&nbsp;stratégique&nbsp;



sans compter que le langage à beau être ultra rapide si tu passe plus de temps à developer , si tu dois rajouter un framework qui te ralentira le truc ou encore si les dev pensent pas à optimiser …&nbsp;

au final les performance du langage ne sont que relative



Toujours pas de support de l’unicode <img data-src=" />


Il faudra voir ce que ça donnera le langage pré-compilé qui remplacera JavaScript dans les navigateurs à terme.

Node.js n’aura plus l’atout d’être le même langage côté client et serveur, ce sera le cas pour tous les langages avec un pré-compilateur. Heureusement il en a plein d’autres.



Mais clairement, PHP et Node.js sont le futur du web pour le moment.

On peut même mixer les deux avec une plateforme website en PHP et des app widgets en JS qui dialoguent avec un serveur Node.js.








Galak_ a écrit :



et ça sature souvent coté SQL bien avant de saturer coté PHP.







Perso, c’est ce que je constate le plus sur mon site. J’ai des indices d’utilisation, et c’est rare que la partie PHP soit plus lourdent que celle en SQL. Souvent, la majeur partie du temps exclusion, c’est le SQL. D’ailleurs, c’est plus là dessus que j’essaie d’optimiser et de faire de cache que le reste.



Attention : dev plus front que back pour info (mais on me demande toujours de faire les deux au final… pour des sites assez basiques, genre un théâtre avec une DB des spectacles, quelques users pour la gestion admin etc.)

&nbsp;

Perso, je pense que PHP a encore de beaux jours devant lui. Je me demande si je ne vais pas justement me mettre à jour justement.

J’ai tâté du Rails et compagnie quand c’était la grosse mode en 2007, mais dès qu’on sort un peu des sentiers battus, ça devient vite chiant.

Python et son framework, j’ai pas testé mais j’ai le même sentiment dessus.



Je comprends bien que vous parliez de trucs lourds, mais il y a encore un sacré gros marché de sites assez basiques à dév rapidement pour un ou deux freelances par exemple. Là, PHP est toujours sympa. Certes il y a ceux qui ne se font même plus chier et tweak du WordPress à gogo, mais perso, je suis du genre à tout coder à la main, léger, parfaitement adapté à la situation, au cahier des charges quoi, sans sortir ce bousin lourdingue et perpétuellement attaqué par ses failles qu’est WP.



Mais je suis d’accord, le web à l’ancienne s’éteint peu à peu, les petites boîtes se contentent d’une page Facebook, perso je trouve ça triste de perdre en identité, en design etc. Mais bon c’est mon avis perso.



Après pour du lourd, je ne suis pas qualifié pour en parler. Mais PHP est conçu à la base pour être simple et rapide à mettre en place, pour tous. C’est ça que j’aime chez lui, malgré ses défauts. Son côté ouvert à tous, la démocratisation des outils est importante pour moi. Qu’un ado puisse se faire son ptit site perso en PHP, je trouve ça cool. Pour moi, le web est avant tout fait pour tous, pas pour les grosses boîtes qui nous font chier (Facebook et Cie). L’appropriation du web est un combat que j’essaie de mener depuis le début, puisque c’est comme ça que ça a commencé et que je dois être un vieux attardé&nbsp;<img data-src=" />


Hélas, mais avec deux-trois astuces on peut faire du full UTF-8 et complètement l’oublier. Perso, ça fait plus de 3 ans que je n’ai plus eu de problème lié à l’encodage. Je me disais que ça serait mieux, puis finalement quand on a le framework qui le gère, c’est plus vraiment un problème.


Bah moi j’en ai encore et toujours…. Ces utilisateurs qui font des copier / coller depuis n’importe quoi grrrr <img data-src=" />


Ahahah, beau-gosse le troll <img data-src=" />



.net est sympa, mais pas que lui:




  • play framework

  • spring boot

  • grails

  • apache camel, apache camel rest DSL

  • spark-rest



  • Pour moi, la plateforme (pas le langage hein) java est aussi une alternative robuste au peucheupeu








Xarkam a écrit :



De vrai bon IDE sont en très grande majorité payant. Et encore, VS est free to use sous certaines conditions tant qu’on ne fait pas 1M€ de bénéfices/an par exemple.





C’est quoi un vrai bon IDE ?



Je ne vois pas le rapport avec les utilisateurs.








brazomyna a écrit :






Laul, soit t’es ignorant, soit t’es un très bon troll.

C’est vrai que PERSONNE ne fait de Js, ce serait de la folie…

Je t’invite quand même a jeter un oeilhttp://stackshare.io/nodejs&nbsp;

&nbsp;Rapidement: Netflix, Uber, DuckDuckGo, Wikipedia, FitBit, Pebble, OpenTable… et j’en passe.

Bref, sort de ta grotte ;)


Pourquoi la mort du PHP ?

Non, le PHP ne va pas mourrir demain, mais disparaitre lentement.

C’est pas forcément pratique a déployer, les perfs sont a la ramasse, pas adapté pour du scaling horizontal, et a l’argument du “C’est facile de trouver des devs”, je te corrigerais: “C’est facile de trouver de mauvais devs”.

&nbsp;

Bref, moi aussi, j’aime beaucoup PHP, mais il faut simplement admettre qu’il n’a pas sa place dans le futur du web :)








adrenalinedj a écrit :



Javascript n’est pas un modèle en matière de langage fortement typé.



[...]&nbsp;    

Si le langage que tu utilises n'est pas capable de te signaler que le contenu que tu veux mettre dans une variable n'est pas du bon type (que ces oit à la compilation comme à l'exécution), par exemple, c'est quand même un peu problématique...







C’est pas specifique a JavaScript: Ruby, Python, PHP… =&gt; meme problematique. Et pourtant il y a plein de grosses applis en Node.js, Rails, Django, PHP donc es vraiment si problematique/indispensable que ca dans bien des cas ?









tanguy_k a écrit :



C’est pas specifique a JavaScript: Ruby, Python, PHP… =&gt; meme problematique. Et pourtant il y a plein de grosses applis en Node.js, Rails, Django, PHP donc es vraiment si problematique/indispensable que ca ?







Il me semble que justement Python est fortement typée.



Effectivement, ça peut etre une force, comme un inconvenient, il faut simplement savoir choisir les outils adaptés aux problématiques rencontrés.


Performance à la ramasse ? Pas simple à déployer ?



PHP à beaucoup évolué. Avec composer, c’est franchement pas compliqué.








hurd a écrit :



Il me semble que justement Python est fortement typée.





typage dynamique fort comme tous les autres langages de ce type, exemple :




&gt; hello = 'world'    



=&gt; None

&gt; hello=&gt; ‘world’

&gt; type(hello)

=&gt; &lt;class ‘str’&gt;

&gt; hello = 10

=&gt; None

&gt; hello

=&gt; 10

&gt; type(hello)

=&gt; &lt;class ‘int’&gt;



Aucune erreur, j’ai pu mettre un nombre dans une variable precedemment de type string. Et ca fonctionne pareil en Ruby, JS…



Les variables sont typees (int, string…) mais tout est “dynamique”.

&nbsp;&nbsp;

Edit : putain de systeme de commentaire de merde









Galak_ a écrit :



Je me demande dans quel monde vivent ceux qui parlent de la mort du PHP.





Je plussoie. Je hais php, que je considère comme un très mauvais langage, mais son écosystème est exceptionnel et tant que Wordpress et quelques autres frameworks auront pignon sur rue, alors php aura de très beaux jours devant lui. Et je doute qu’ils soient délogés de sitôt.



Là jour où ce sera fait, alors seulement php commencera à entrer en mode maintenance et n’aura plus que quelques décennies à vivre.



Mais ça arrivera, les cool kids finiront par nous sortir un framework rival sur le cool language du moment (JS aujourd’hui, qui n’est pourtant pas meilleur que php).



Regarde la consommation mémoire d’un Symfony 2, si tu scale verticalement, ça passe, mais la mode est à l’horizontal ;)


Écosysteme exceptionnel ?

Compare npm à Composer :/



Je sais que je troll un peu la, mais je ne vois aucun bon argument en faveur de PHP.


C’est sûr que c’est une habitude à prendre, et c’est très relou quand tu fais un copier coller d’un long code qui avait le malheur de pas être indenté pareil que le tien <img data-src=" />



On s’y fait, et je trouve la syntaxe très simple à prendre en main et à mémoriser pour faire des choses déjà relativement avancées. Bon après j’ai pas passé beaucoup de temps dessus.



Le python + le framework django c’est assez puissant quand même. C’est probablement pas le seul framework puissant et intéressant du marché, mais il est pas mal du tout et a l’avantage de tourner partout.








jojofoufou a écrit :



Écosysteme exceptionnel ?





Besoin d’un CMS ? Les meilleurs sont en php.

Besoin d’une plateforme d’e-commerce ? Les meilleurs sont en php.

Besoin d’un outil de discussion ? Les meilleurs sont en php.

Etc…





Bon, cela dit je ne résiste pas à un petit troll :




  • Et sinon, le support Unicode est enfin complet et par défaut ?

    (réponse : probablement pas)









KP2 a écrit :



JS est un très mauvais langage.

[…]&nbsp;Le problème est quand un dev se forme avec ce truc, il ne peut carrément pas devenir un bon dev.









KP2 a écrit :



l’ecosysteme (tant au niveau outils, que process, que formation des professionnels aux process et aux outils) […]&nbsp;autour du JS […] C’est la foire a la bricole&nbsp;



Aujourd’hui, aucun editeur ou entreprise sérieux ne peut raisonnablement basé un développement professionnel sur une stack js.





Oui JS est un langage bricolé mais pour le reste t’es completement a cote de la plaque, vraiment.

De toute facon il va falloir t’y faire : la croissance de l’ecosysteme JS est juste exponentielle (http://www.modulecounts.com/ ) et draine toutes les innovations actuelles.



Wordpress (+ de 50% des sites web …) est en train de migrer petit à petit vers d’autres technos. Ils ont notamment réécrit l’interface d’admin sans PHP.

Ca ne m’étonnerait pas qu’ils s’en éloignent aussi pour le reste de l’appli, du coup. La transition sera longue, surtout avec la tonne de plugins qu’il faudra ré-écrire, mais si elle se produit réellement le PHP sera un peu dans la “merde” je pense. Mais comme tu dis il ne lui restera “que” quelques décennies à vivre.


Euh, tous les gros développeurs de ce monde l’utilisent ou l’ont utilisé pour l’un de ses projets.



Le langage peut permettre des choses bof, si tu mets un bon développeur dessus le code sera propre. Et tant que les performances sont au rendez-vous derrière…








tanguy_k a écrit :



Oui JS est un langage bricolé mais pour le reste t’es completement a cote de la plaque, vraiment.

De toute facon il va falloir t’y faire : la croissance de l’ecosysteme JS est juste exponentielle (http://www.modulecounts.com/ ) et draine toutes les innovations actuelles.









Si la quantité etait un gage de qualité, ca se saurait… Moi, quand je vois pleins de modules comme ça, ça me donne surtout l’image d’une communauté extrêmement dynamique mais surtout extrêmement mal organisée et qui aime réinventer la roue sans consolider l’existant.

C’est l’apanage d’un milieu jeune et moyennement compétent (globalement, j’entends).









KP2 a écrit :



Si la quantité etait un gage de qualité, ca se saurait…





Proportionnellement il y a autant de packages JS de bonne/mauvaise qualite que dans les autres langages.







KP2 a écrit :



[…] une communauté […] extrêmement mal organisée et qui aime réinventer la roue sans consolider l’existant





hein ?







KP2 a écrit :



C’est l’apanage d’un milieu jeune et moyennement compétent.





Pas plus, pas moins que dans les autres langages. Faut faire du Fortran pour etre un homme ?



D’après à peu près tous les dictionnaires et encyclopédies, NodeJS répond bien à la définition du framework.








jul a écrit :



les petites boîtes se contentent d’une page Facebook, perso je trouve ça triste de perdre en identité, en design etc. Mais bon c’est mon avis perso.



+1&nbsp;&nbsp;



mais d’un autre coté il vaut parfois mieux juste une page Facebook (ou si possible autre chose pour une meilleur visibilité) à jour (adresse tel horaire correct) une un site vieillot limite avec des gif & pas à jour&nbsp;

genre un coiffeur ou l’épicier du coin n’a pas forcement besoin d’un site vitrine



En tout cas, sur les données du lien fourni la croissance n’est pas exponentielle



(et oui, ça m,énerve d’entendre sortir ce terme à tort et à travers&nbsp; <img data-src=" />)


php-cgi est un framework ?








BabyAzerty a écrit :



D’après à peu près tous les dictionnaires et encyclopédies, NodeJS répond bien à la définition du framework.





Chez java, la jvm est un framework ? <img data-src=" />









tanguy_k a écrit :



Faut faire du Fortran pour etre un homme ?





Du cobol, tu voulais dire ? <img data-src=" />









brazomyna a écrit :



Du cobol, tu voulais dire ? <img data-src=" />





de l’assembleur&nbsp;

mov eax ,ebx&nbsp;

mov eax,11&nbsp;

add eax,5









jojofoufou a écrit :



Pourquoi la mort du PHP ?

Non, le PHP ne va pas mourrir demain, mais disparaitre lentement.

C’est pas forcément pratique a déployer, les perfs sont a la ramasse, pas adapté pour du scaling horizontal, et a l’argument du “C’est facile de trouver des devs”, je te corrigerais: “C’est facile de trouver de mauvais devs”.

 

Bref, moi aussi, j’aime beaucoup PHP, mais il faut simplement admettre qu’il n’a pas sa place dans le futur du web :)







S’il disparait, ce ne sera pas avant longtemps. Le PHP est arrivé lors de la démocratisation du web, il a été facilement adopté parce qu’il n’y avait pas grand chose avant et pas de langage sérieux en face (et ne me dites pas l’ASP, à l’époque il n’avait aucune chance ne serait-ce que parce qu’il nécessitait Windows), les boites n’utilisaient pas encore le web.



Aucun nouveau langage ne pourra jamais être adopté aussi vite et représenter une part de marché aussi importante, simplement parce que le PHP est déjà installé et que beaucoup de boites ne pourront simplement pas migrer sur une autre langage comme ça. Même si un langage arrivait à s’imposait, il faudrait le temps que les étudiants switchent dessus, que les nouvelles boites l’adoptent, puis quelques décennies pour que les anciennes ferment ou finissent par migrer dessus avant que le PHP disparaisse, c’est illusoire de penser que ça peut arriver en peu de temps.



Et pour le reste, comme d’hab ça reste du bashing de PHP classique.



Les perfs ? Non seulement elles ne sont pas ridicules mais encore une fois, elles n’ont de réelles importances que dans des projets bien spécifiques et largement minoritaires.



Le déploiement ? Les outils ne manquent pas et on peut se faire ses propres outils, je ne vois pas où est le problème, et en tout cas en aucun cas de quoi justifier de migrer vers un autre langage.



Les mauvais devs ? Bah oui, le PHP de par son coté accessible et sa part de marché attire beaucoup d’incompétents, mais il y a fort à parier que les bons devs PHP, même si minoritaires parmi l’ensemble des devs PHP, restent plus nombreux que les bons devs des langages que vous préférez au PHP.



Je ne comprendrai jamais ce bashing envers le PHP, manque d’objectivité ? Déconnecté de la réalité du monde de l’entreprise et des besoins les plus courants ? Hype des autres technos ? Opinion basée sur PHP3 ou 4 qui a la vie dure ?



Aujourd’hui le PHP permet de faire un peu tout et de belle manière si on s’en donne les moyens, et il essaye à chaque version de se débarrasser un peu plus de ses tares des débuts, tares qui au passage ont fortement contribué à son succès.

Ce n’est pas parce qu’on peut faire du code dégueulasse et qu’il y a plein de devs pourris que ça en fait un mauvais langage.

Ce n’est pas parce que node.js sera plus adapté pour des applis spécifiques à très forte charge représentant un pourcentage négligeable des applis que PHP en devient obsolète pour autant.

Ce n’est pas parce que tel outil ou telle fonctionnalité est meilleur (ou a votre préférence) dans un autre langage que ça en fait un langage pourri. Aucun langage n’est meilleur partout, vous trouverez pour tous les langages certaines fonctionnalités ou certains outils mieux implémentés dans un autre langage. C’est de la mauvaise foi que de prendre chaque fonctionnalité ou outil vaguement mieux implémenté ailleurs pour descendre le PHP, on peut descendre n’importe quel langage comme ça.



Je ne dis pas que le PHP est mieux, ni même forcément aussi bien que d’autres langages, mais faut arrêter de prétendre qu’il est pourri et que votre petit préféré est top. La plupart des applis pourraient être réalisées avec une qualité de code similaire et des différences de perfs imperceptibles en pratique (je ne parle pas de bench pour se palucher devant les perfs de votre chouchou) avec tous les langages utilisables.









KP2 a écrit :



JS est un très mauvais langage. Le problème est quand un dev se forme avec ce truc, il ne peut carrément pas devenir un bon dev. Ni au niveau pratique (gestion de la qualité, gestion du cycle de vie du code, etc) ni au niveau théorique (le js est vraiment du bricolage).





JS n’est pas forcément un mauvais langage. Perso je le vois comme l’assembleur pour le web. Ca permet de faire plein de trucs sympa mais c’est vrai que pour un projet conséquent c’est juste une tannée à maintenir et il vaut mieux passer à des langages de plus haut niveau. Perso, en ce moment je surkiffe GWT : développement client et serveur en Java et la partie client est compilée en Javascript. Pour moi on a un peu le meilleur des deux mondes: la puissance du Javascript, la rigueur de Java.









monpci a écrit :



de l’assembleur 

mov eax ,ebx 

mov eax,11 

add eax,5







bref mov eax,16









levhieu a écrit :



En tout cas, sur les données du lien fourni la croissance n’est pas exponentielle



(et oui, ça m,énerve d’entendre sortir ce terme à tort et à travers  <img data-src=" />)





Camarades ! Trop longtemps nous avons subi l’ignorance crasse des exponentialistes !



Ensemble introduisons dans notre enseignement les notions de superlinéarité et sublinéarité.









le-gros-bug a écrit :



bref mov eax,16





<img data-src=" /><img data-src=" /><img data-src=" />









Pochi a écrit :



JS n’est pas forcément un mauvais langage. Perso je le vois comme l’assembleur pour le web. Ca permet de faire plein de trucs sympa mais c’est vrai que pour un projet conséquent c’est juste une tannée à maintenir





Pour moi, JS est un excellent langage qui offre une souplesse inégalée et une efficience dans le dév. que peu d’autres langages sont capables d’offrir. Mais cette souplesse s’accompagne de beaucoup de liberté, et c’est là que le problème peut se situer:





  • mettre le JS dans les mains d’un dev. médiocre, c’est la cata assurée, tendance “plat de spaghettis” du temps des devs. habitués au GOTO.

    &nbsp;

  • a contrario, mettre le JS dans les mains d’un dev. chevronné, qui a déjà pratiqué en long en large et en travers d’autres langages beaucoup plus stricts (C/C++, …), qui a appris la rigueur, a parfaitement intégré à la fois les bonnes pratiques et pris l’habitude de comprendre ce qui se passe “sous le capot”, et vous avez alors un des langages les plus efficients qui soit en terme de coding.









levhieu a écrit :



sur les données du lien fourni la croissance n’est pas exponentielle&nbsp;





C’est pourtant a s’y meprendre (courbe en bleue) :http://s16.postimg.org/qi9ftiv1x/Screen_Shot_2015_12_04_at_16_04_39.png

En tout cas c’est clairement pas lineaire (contrairement a Ruby gems et Go pkg).



Attention, j’aime beaucoup PHP, mais objectivement, je ne vois pas réellement l’avantage par rapport aux techno “a la mode en ce moment”.

Je parle ici pour moi, et cela sera surement completement different pour chacun d’entres nous mais:

J’ai fait “pas mal” de PHP (Vanilla, Code igniter, Laravel, Symfony 2, sur des proj qui sont encore en prod a l’heure actuelle) et “un peu” de Node.js (egalement sur des trucs en prod). Et pourtant, je suis BEAUCOUP plus productif sur du Node.

De même concernant le deploiement, je peux m’amuser a faire des trucs custom si j’ai le temps.

Et si j’ai la flemme: github -&gt; travis -&gt; heroku. en 2 minutes j’ai un hello world avec une prod et un staging et un pipeline d’integration continue complet, scalable en 1 clic.

Finalement coté perf, quand je vois des serv node.js en prod avec un nombre de visites “conséquentes” consomment autant que la moindre jointure SQL avec Doctrine sur Symfony 2 en env de dev, ça fait peur.



Pour conclure, pas mal d’industries ont fait l’erreur de rester il y’a 10-20 ans sur des technos “qui marchent”, et sont maintenant en train de mettre a jour avec douleur sur des trucs plus récents. Je pense qu’elles ne re-feront pas la même erreur et que PHP sera beaucoup plus rapide a disparaitre que l’on peut l’imaginer.


ton message me fait penser que selon moi un des gros atout pour “l’adoption du php” c’est ça doc qui est centralisée, ultra simple d’accès en souvent dans plusieurs langues&nbsp;&nbsp;



autre remarque vous parlez tous de bon ou mauvais dev (je te vise pas spécialement Galak_)&nbsp;&nbsp;&nbsp;

&nbsp;un “dev null” peut être nul aussi à code d’une mauvaise intégration à l’équipe …. (mauvaises explications des process au delà des compétences du dev vous savez sur les projet à finir pour hier)

et allez Osez dire que vous n’avez jamais (fait/torcher) du code déguellasse

&nbsp;&nbsp;

enfin je voudrai finir mon commentaire sur une citation histoire de faire bien&nbsp;



&nbsp;

Le bon sens est la chose la mieux partagée car chacun pense en être si bien pourvu, que même ceux qui sont les plus difficiles à contenter en toute autre chose, n’ont point coutume d’en désirer plus qu’ils en ont. En quoi il n’est pas vraisemblable que tous se trompent ; mais plutôt cela témoigne que la puissance de bien juger, […..] [Descartes, Discours de la méthode, (1637)]



n’en est-il pas de même pour le fait d’être un bon dev … ?








brazomyna a écrit :



JS est un excellent langage qui offre une souplesse inégalée et une efficience dans le dév. que peu d’autres langages sont capables d’offrir.&nbsp;





Perso, plus je développe et plus la souplesse est pour moi une source de problèmes. Rien que d’avoir deux syntaxes pour le if en java (if et if{}) est une grosse erreur (oui le if normal est à bannir). Avoir de la souplesse sur un projet perso qui fait 3 pages, ok. Avoir de la souplesse sur un projet avec des dizaines de dev sur plusieurs années, des centaines voire milliers de classes, c’est du suicide.

&nbsp;



brazomyna a écrit :



&nbsp;



- a contrario, mettre le JS dans les mains d'un dev. chevronné, qui a déjà pratiqué en long en large et en travers d'autres langages beaucoup plus stricts (C/C++, ...), qui a appris la rigueur, a parfaitement intégré à la fois les bonnes pratiques et pris l'habitude de comprendre ce qui se passe "sous le capot", et vous avez alors un des langages les plus efficients qui soit en terme de coding.







C’est quoi pour toi le coding ? Compacité du code ? Capacité d’un IDE à détecter un erreur à l’écriture ? autre ?



Et c’est quoi la proportion de ces bons codeurs que tu décris ? 10% ?









jojofoufou a écrit :



Pour conclure, pas mal d’industries ont fait l’erreur de rester il y’a 10-20 ans sur des technos “qui marchent”, et sont maintenant en train de mettre a jour avec douleur sur des trucs plus récents. Je pense qu’elles ne re-feront pas la même erreur et que PHP sera beaucoup plus rapide a disparaitre que l’on peut l’imaginer.





à l’heure de oracle nosql big data il y a encore plein d’AS400 & de cobolistes (surtout dans la grande distrib)

Pour le coup je ne pense pas comme toi sur le point “&nbsp;PHP sera beaucoup plus rapide a disparaitre que l’on peut l’imaginer.”









Pochi a écrit :



Rien que d’avoir deux syntaxes pour le if en java (if et if{}) est une grosse erreur (oui le if normal est à bannir).





N’exagérons pas. <img data-src=" />



Moi ça ne m’a jamais posé aucun problème, que je lise des sources du projet X de 1M de lignes ou du projet Y.





Perso, plus je développe et plus la souplesse est pour moi une source de problèmes.



Lorsque la souplesse permet des conceptions très différentes pour aboutir au même résultat, alors cela créer des difficultés de lecture, oui.



Mais cette souplesse-là fait aussi économiser beaucoup de code. Or ce code inutile, cette complexité accidentelle, cette vulgaire plomberie, est un obstacle majeur lors de la lecture, un surcoût important lors de la refactorisation et la première contribution à l’explosion combinatoire de la complexité d’un logiciel.



Le langage naturel est extrêmement souple et deux auteurs différents peuvent produire des explications très différentes. Mais à niveau de détail équivalent le langage naturel est cinq à dix fois plus concis que nos langages de prog actuels.



Et pourquoi la courbe bleue ne serait pas une parabole ?

À l’oeil, on ne peut pas juger.



Sur le lien dans le commentaire auquel je répondais, il y avait des données.

Sur ces données, on pouvait vérifier:

Tant que l’augmentation n’est pas proportionelle à la quantité déjà présente, la croissance n’est pas exponentielle.








monpci a écrit :



à l’heure de oracle nosql big data il y a encore plein d’AS400 & de cobolistes (surtout dans la grande distrib)

Pour le coup je ne pense pas comme toi sur le point “&nbsp;PHP sera beaucoup plus rapide a disparaitre que l’on peut l’imaginer.”





La grosse différence c’est que le cobol par exemple c’est du back-end, souvent bien moins jettable que du front-end surtout si c’est pour avoir la nouvelle fonctionnalité bling-bling du moment.









KP2 a écrit :



Node.js, pour moi, c’est une défécation de développeur front qui avait besoin de bricoler 2 ou 3 trucs en back avec ses maigres compétences en développement de qualité.

Rien que le choix de js est carrément dégueulasse. Y’a pas d’autre mot. L’absence quasi complète d’outils de gestion de la qualité pour ce langage le disqualifie directement pour toute utilisation autre que faire des zigouigouis jolis sur une page web.





Ces outils existent&nbsp;: ESLint, JSLint, Closure…

Et on peut même les pluggué avec des solutions bien connu comme sonarQube.

&nbsp;

&nbsp;



adrenalinedj a écrit :



Au risque de te contredire sur l’ecosystème, Visual Studio Code est open source et permet de développer des applis web en ASP.Net.



Et concernant le “troll” sur Node.js, KP2 &nbsp;a quand même raison sur la question de qualité.

Javascript n’est pas un modèle en matière de langage fortement typé.

Quand tu programmes côté serveur, tu as quand même des contraintes de qualité, de sécurité et de fiabilité.

Si le langage que tu utilises n’est pas capable de te signaler que le contenu que tu veux mettre dans une variable n’est pas du bon type (que ces oit à la compilation comme à l’exécution), par exemple, c’est quand même un peu problématique…





Comme je le disais, y’a une flopée d’outils de linting et de qualité pour JS, et c’est encore plus stricte avec ECMAScript 2015.



L’utilisation de JSDoc permet ce type d’avertissement avec le bon IDE, ou bien on peut passer par des choses comme Dart ou Typescript pour un typage plus fort.&nbsp;



Tous les ORM à ma connaissance pour JS sont livré avec des validators, &nbsp;et il reste bien facile de checker le type d’une variable soit même.&nbsp;



Un language à &nbsp;typage dynamique offre d’autre avantage, c’est une autre manière de travaillé. Ca évite plein de problème lié au typage qu’on peut trouver en Java : création d’interface juste pour résoudre un problème de type, implémentation multiple d’une méthode avec des signatures différentes…



Puis si un typage fort était suffisant, aurait-on eu besoin de pondre ça =) :&nbsp;

http://beanvalidation.org/1.0/spec/ &nbsp;



C’est aussi une histoire d’équipement. Un mainframe c’est une fiabilité à des années lumières des modèles d’équipement plus récents.



Pour avoir bossé dans une grande compagnie aérienne, un mec Dell passaient presque tous les jours pour changer des racks qui pétaient pour X ou Y raison. L’indisponibilité de certains services n’était pas énorme mais assez pour que ça soit dangereux sur des fonctions critiques (même avec un data-center secondaire).

Le mainframe, c’était 8 secondes d’indisponibilités cumulées sur 10 ans.



Pour avoir vu les ventes récentes de ces équipements (banques, assurances, …) c’est clairement pas prêt de s’arrêter.








monpci a écrit :



autre remarque vous parlez tous de bon ou mauvais dev (je te vise pas spécialement Galak_)&nbsp;&nbsp;&nbsp;&nbsp;





Alors tu vois, le bon dev, il a son éditeur, il tape du code, et c’est bon dev !

Le mauvais dev, il a son éditeur, il tape du code, mais c’est un mauvais dev, c’est pas pareil….



Bin, étant donné que PHP est TRES largement la techno la plus utilisée actuellement, se demander quel est son avantage actuellement pour annoncer qu’elle va disparaître rapidement, c’est poser la question à l’envers.&nbsp;



Il faudrait plutôt se demander, pour justifier des prédictions de migration massive et rapide vers une autre technos, quels sont ses désavantages par rapport au autres technos.&nbsp;



D’après les commentaires, j’en ai distingué deux principaux :&nbsp;




  • les perfs. Déjà, si l’on en croit la news, la version 7 apporte principalement un gain en perf, et ensuite cela n’impact que quelques projets. Pour la très grande majorité des projets en PHP, la volumétrie et donc les perfs sont anecdotiques. Pour les rares projets ou la volumétrie est vraiment un problème, il existe des solutions sans changer de technos, et donc réécrire la totalité. Par exemple, sur un projet avec Zend + Doctrine, on a géré une partie des traitements directement dans la base, avec PL/SQL. On aurait pu passer sur du nodeJS et tout réécrire, au bas mot 200 jours de dev, mais on s’en est sortie avec moins de 10 jours.&nbsp;



  • le typage faible, ou plutôt dynamique. Pour moi c’est un faux problème, puisque les dev PHP chevronnées savent très bien comment éviter les problèmes avec ça (“===” au lieu de “==”, forcer le typage, etc). Et comme dis plus haut, le typage dynamique a ses avantages.&nbsp;

    Après pour ce qui est des bon IDE, outils de déploiement et autres, c’est soit du troll soit un manque de recherche.



    Je pense que d’autres technos feront leurs place petit à petit, mais je suis persuader que PHP gardera facilement 30% de part de marché pour les 20 ans à venir.&nbsp;








blackdream a écrit :



Pour les rares projets ou la volumétrie est vraiment un problème, il existe des solutions sans changer de technos, et donc réécrire la totalité. Par exemple, sur un projet avec Zend + Doctrine, on a géré une partie des traitements directement dans la base, avec PL/SQL.





Devoir en arriver là ne parle pas en faveur de php. Mais comment se fait-il que les compilateurs php soient si mauvais ? Il n’y a pas apparemment de raisons pour que JS puisse obtenir de meilleures perfs que php.







  • le typage faible, ou plutôt dynamique.



    Typage faible/fort et statique/dynamique sont deux concepts distincts, merci de ne pas les mélanger.



    Si 5 et “5” sont égaux, c’est un typage faible.

    Si tes méthodes ne spécifient pas le type des arguments, c’est un typage dynamique.



Symfony c’est “une” philosophie. Un peu comme Laravel.



Les micro framework ont de bien meilleures performances.








jojofoufou a écrit :



Finalement coté perf, quand je vois des serv node.js en prod avec un nombre de visites “conséquentes” consomment autant que la moindre jointure SQL avec Doctrine sur Symfony 2 en env de dev, ça fait peur





En même temps Doctrine, c’est se tirer une balle dans le pied.

&nbsp;

Un peu comme Eloquent et tous les autres ORM (et pas limité qu’a PHP,&nbsp; - oui je pense à Hybernate&nbsp; - ), de grosses usines à gaz qui te sortent des requêtes hyper pas optimisé sous des couverts de facilité.

&nbsp;

Parler de performances sans vouloir mettre les mains dans le camboui, c’est un peu facile.



&nbsp;D’autant plus que ces ORM se calent sur MySQL et sont incapable de profiter des fonctionalités hyper pratique et accessoirement beaucoup plus performantes des SGBD modernes. C’est ballot !



PHP est un langage. CGI est une interface. Lapalissade non fonctionnelle.


Java est un langage. La JVM, ba c’est comme son nom l’indique.



Au lieu de faire des comparaisons qui ont peu de sens, peux-tu à la place expliquer pourquoi ce n’est pas un framework ?

NodeJS n’est pas un langage, il définit l’architecture des app et propose des “modules” (dans le sens plugins), soit la définition même de framework.


Ce qui a fait tiquer Gromsempai surtout, c’est la partie “framework javascript parmi d’autres” (sous-entendu, d’autres frameworks Javascript). Sauf que je ne connais pas vraiment d’autre framework Javascript dont le but principal est la conceptions d’applications serveur (donc exit Angular, React, Backbone…).


Des nouvelles du front nous informent que la pourriture Javascript s’étends tous les jours un peu plus comme une tumeur maligne incurable. Le pronostic vital est engagé, les chances de survie sont maigres.



Comment après tant d’années d’informatique avons nous pu en arriver la ?



Le premier facteur qui vient à l’esprit, ce sont tout ces développeurs qui suivent les modes sans aucune capacité de réflexion. Et surtout sans aucunes connaissances de bas niveau. Pourquoi utilisez vous Node.js ? Parce que le voisin l’utilise, tout simplement. Tout le monde en parle, donc ça doit forcément être bien…



Regardez plutôt ce qu’en disent des vrais développeurs expérimentés.



Déja, à la base, le Langage Javascript est mauvais de chez mauvais. Bricolé et sur-bricolé, pas de typage fort. C’est vraiment tout sauf l’idéal. Oui, le changement, pourquoi pas. Mais certainement pas pour ça…



Alors que vous penseriez logiquement qu’un bidule médiocre, on l’abandonne pour en créer de meilleurs, ce n’est pas du tout le réflexe des développeurs modernes.



Non, eux, quand un truc est mauvais, ils y ajoutent des couches et des couches de framework pour cacher la misère, fragmenter la base de code et bouffer de la puissance. Et puis, tant qu’on y est, on met la maladie à toutes les sauces, on commence à voire du Node.js dans des microcontrôleurs. Et bientôt ils vont repeindre les murs avec… Voila résumé en quelques mots les symptômes de la maladie Javascript.



Enfin, NodeJs est fondé sur un paradigme à mourir de rire : le multitâche coopératif. Et oui, rappelez vous ce cache misère qu’on utilisait au début des années 80 dans les Os qui n’avaient pas encore de vrai noyau multitâche.



Si tant est que ce concept avait eu le moindre intérêt technique(ce dont beaucoup de programmeurs expérimentés doutent) à l’heure ou l’on multiplie le nombre de coeurs , n’importe quel étudiant en informatique devrait être capable d’imaginer que le langage pourrait facilement l’appliquer de manière transparente.



Mais non, c’est tellement plus amusant de bousiller la structure de votre code pour la transformer en plat de nouille de “callbacks”. En plus, ça vous donnera un petit côté “roots” pour impressionner vos copains.



Parfois je me demande si dans quelques années, la programmation spaghetti a coup de Goto ne reviendra pas. Ca pourrait faire fureur…



Comme si des années d’évolution des langages ne nous avaient pas appris que la structure devait compter avant tout et que c’est le langage qui devait s’occuper des aspects techniques.



Oh, j’entends venir les experts autoproclamés venir nous asséner d’un ton docte qu’on ne sait pas programmer et qu’un bon programmeur saura faire un truc structuré, qu’en fait ça parait mauvais, mais que c’est bon… blablaba blabla.



Outre que les exemples que j’ai pu voir ne m’ont jamais convaincu de cette affirmation, on sait tout comment cela se terminera en pratique, c’est à dire “in real life” quand vous, programmeur devrez reprendre un programme écrit par un stagiaire. Je vous souhaite d’avance un bon courage. Et surtout, n’abusez pas de l’aspirine.



Quand on connait le monde informatique, on connait le cynisme de sa réalité et du fait que personne ne se préoccupe réellement d’avoir de bons outils, ni de faire les choses bien.



Après tout, plus un logiciel deviendra incompréhensible, immense et bogués, plus il fournira de travail à une armée d’informaticiens pendant très longtemps.



D’avance un grand merci pour vos réponses pleines d’insultes…


Comme je ne connais pas assez Javascript, je ne peut pas aller à 100% ds le sens de sr17, mais là où je le rejoins, c est qu un code “pro” se doit d avoir une maintenance relativement simple..

En fait,&nbsp; j ai vraiment jamais été tenté par JavaScript.

Ptet la flemme de s’y mettre, je suis essentiellement développeur Desktop/WinForms et surtout Serveur en .NET et python, j apprécie la “beauté” d un Framework OO cohérent. Si j ai fait du PHP à l occasion, pas non plus de quoi être excité.

PHP7 est une bonne nouvelle, en espérant que cela amène un peu de professionnalisme à ce milieu fourre tout.

En Python, j ai un peu essayé Django mais préférais la simplicité de Flask.

&nbsp;DRY (dont repeat yourself) and KISS (keep it simple and stupid) sont des principes de base de tout bon développeur… cfhttps://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29

&nbsp;


Je te dirais que le web est aussi une mauvaise plateforme : pas de typage fort des arguments, tout ce qui transite est du texte… non, je ne vois vraiment pas pourquoi tu l’utilises aussi. Ceux qui l’ont créé devraient vraiment être des buses.



Bon, à titre perso, je navigue entre Java (typage fort), Js (typage faible), SQL (typage faible, pour les requêtes), PHP (typage faible), bash (pas de typage). Et perso, je trouve que chaque philosophie à ses avantages et ses inconvenants. En tout cas, il y a plein de petits trucs de PHP que j’aimerais avoir en Java et vise versa.



Ça fait plus de 10 ans que je fais du dév, et je n’ai pas du tout le même ressentis sur les langues à typage faible. Je n’ai pas l’impression d’être un expert pour autant.


Tient y’en a ici qui ont bien peur de la complexité des langages orientés prototype…(la rigidité de la poo est certes rassurante)

Si vous voulez bien coder en javascript. Bien commencer est possible , gratuit et trouvable avec une simple recherche google si on s’y intéresse vraiment :

http://addyosmani.com/resources/essentialjsdesignpatterns/book/

on peut facilement trouver plein de ressources encore une fois si on s’intéresse au sujet et qu’on surfe pas sur le stéréotype pour faire briller un autre langage sur lequel on plus d’expérience.

Souvent quand il y a problème ca vient plus souvent de ceux qui l’utilisent (ou ne veulent pas l’utiliser correctement pour x raisons) que du langage lui même.

Et surtout&nbsp;il y a tout autant de développeurs “alimentaires” sur tous les langages mais étrangement certains ne voient que ceux sur les autres.








martino a écrit :



&nbsp;

&nbsp;http://addyosmani.com/resources/essentialjsdesignpatterns/book/








 Excellent lien, j'en cherchais justement que je pourrais facilement refiler quand on m'en demande. Merci <img data-src=">  





Pour le reste, le comm de sr17 est soit un bon vieux troll, soit le bonhomme est bien trop arc bouté sur ses certitudes pour espérer le voir évoluer. Dans les deux cas, je doute que ça vaille la peine d’y perdre son temps amha.

&nbsp;









zefling a écrit :



Je te dirais que le web est aussi une mauvaise plateforme : pas de typage fort des arguments, tout ce qui transite est du texte…







Heu le web ça à été conçu pour acceder à des documents hypertextes, rien de plus, rien de moins. Le bricolage à commencé dès qu’un illuminé à décidé qu’on pourrait aussi y afficher des images, et n’à jamais cessé d’empirer encore et encore depuis. JS est un digne héritier de cette philosophie : des strates de pansements sur des jambes de bois qui fonctionnaient bien mieux sans ça.



Le bon et le mauvais développeur donc ?

Et pour toi le bon developpeur il developpe comme à l’époque ou tu avais encore envie d’apprendre.

Du coup on se complaît dans ses acquis, on survole &nbsp;et chie sur le reste.


You can’t be serious.gif










zefling a écrit :



Je te dirais que le web est aussi une mauvaise plateforme : pas de typage fort des arguments, tout ce qui transite est du texte… non, je ne vois vraiment pas pourquoi tu l’utilises aussi. Ceux qui l’ont créé devraient vraiment être des buses.







En tant que programmeur, peux tu réellement affirmer que tu utilises ces technologies par choix ?



N’ayons pas peur de le dire, un certain nombre de technologies sur lequel est basé le web, c’est carrément de la merde. Et beaucoup des sites web tiennent en réalité plus de l’immonde bricolage que du programme sérieux. On peut toujours accuser les programmeurs, mais sont t’ils vraiment les seuls responsables ?



Ceux qui ont développé ces technologies n’étaient pas des buses. Ils n’avaient simplement pas prévu leur extrapolation à un tel point.



Quand ils ont pondu sur un coin de table ce qu’ils imaginaient être des petits langages de scripts ou un petit format de présentation de document, ils n’imaginaient pas un instant que tout une génération de codeurs construiraient un jour des choses très ambitieuses avec.



Et au lieu de s’autoriser à penser que cette base est mauvaise, beaucoup de programmeurs se contraignent mentalement à s’y adapter.



Ils transforment idéologiquement la merde en or avec de la propagande pour esclave : “les bons y arrivent”.



Ils écrivent des framework pour encapsuler la merde. Comme si cacher la merde sous le tapis était une bonne façon de procéder.





Bon, à titre perso, je navigue entre Java (typage fort), Js (typage faible), SQL (typage faible, pour les requêtes), PHP (typage faible), bash (pas de typage). Et perso, je trouve que chaque philosophie à ses avantages et ses inconvenants. En tout cas, il y a plein de petits trucs de PHP que j’aimerais avoir en Java et vise versa.





Il y a de bonnes idées dans tous les langages.



Mais l’absence de typage fort est simplement une hérésie pour écrire de vraies applications. Trop d’effets de bord qui ne valent pas les maigres avantages.



Outre la longue liste de problèmes que cela pose à haut niveau, on pourrait également parler du manque d’optimisation à bas niveau.



Car il est plus lent de traiter une opération sur des variables non typées.





Ça fait plus de 10 ans que je fais du dév, et je n’ai pas du tout le même ressentis sur les langues à typage faible. Je n’ai pas l’impression d’être un expert pour autant.





Et pour une bonne raison, tu fait partie d’une génération formatée pour travailler avec ça.



Je te prédit que dans 20 ou 30 ans, ton avis aura changé, quand tu aura plus du recul sur les choses.



Comme tu le verra plus tard, les modes, ça change.







martino a écrit :



Le bon et le mauvais développeur donc ?

Et pour toi le bon developpeur il developpe comme à l’époque ou tu avais encore envie d’apprendre.

Du coup on se complaît dans ses acquis, on survole  et chie sur le reste.







D’un point de vue de la science informatique, rien de tout cela n’est nouveau.



Pour le reste, chaque époque de l’histoire de l’informatique à eu sa mode à la con.




Que pensez vous d’un couple Symfony 2 pour une API REST avec un client riche avec AngularJs ?



Je me suis essayé à NodeJS, il n’a rien de surpuissant pour moi. Sympa mais tellement pas intuitif, et encore ce n’est pas le souci, le plus gros problème est son hébergement. Je n’ai pas envie d’héberger par moi même, pour de nombreuses raisons. Il y a trop peu d’hébergeur NodeJS et ce n’est pas non plus excellent ce qui est proposé.



A part pour certain cas mais les tarifs sont prohibitif.





D’où ma question, API REST en SF2 pour l’automatisation et un client riche en javascript ? Serait-elle la combinaison gagnante?


Pour le Java non, par contre pour le PHP oui, c’est un choix vu que c’est surtout à titre perso que j’en fait.



Et le trop d’effet de bord, je le vois aussi souvent en PHP qu’en Java. Quand c’est mal codé, peu importe que ça soit bien typé ou non. Du code de merde, j’en vois souvent en Java (et je dois aussi parfois en faire). Si on va part là, il faudrait aussi interdire « null » qui est pour certains une hérésie. Ensuite, ça devient aussi assez compliqué de typer quand on fait de la programmation fonctionnelle. Bref, on ne peut pas tout avoir, où il faut faire comme Mozilla, refaire un langage pour un but précis : Rust c’est la sécurité avant le reste.


Pour ce qui est des perfs, je pense la raison (dans mon cas) est plus à voire coté Zend et doctrine. Mais pour répondre à ton “en arriver là”, non, en fait c’était clairement une erreur de conception de passer par PHP pour les traitements dans la base. C’était un intermédiaire inutile. Et au passage, le PL/SQL c’est très bien pour des traitements assez complexe sur une volumétrie énorme. Je ne comprend pas pourquoi ce n’est pas plus répandu.&nbsp;



Merci pour ton rappel sur le typage cela dit. Mais comme je disais, le typage faible est facilement contournable : un égal de plus et hop, typage fort&nbsp;<img data-src=" />








zefling a écrit :



Pour le Java non, par contre pour le PHP oui, c’est un choix vu que c’est surtout à titre perso que j’en fait.





Tu devrais essayer GWT. Tu codes des applications web en Java et GWT compile tout ça en Javascript très rapide. Perso j’avais essayé de faire quelques sites en PHP/JS avant de connaître GWT et je n’était jamais allé assez loin. Depuis que je suis sur une mission en GWT j’ai enfin fait le site que je voulais et j’en suis super content. C’est bien meilleur que les classiques Struts/JSF.





zefling a écrit :



Si on va part là, il faudrait aussi interdire « null » qui est pour certains une hérésie.&nbsp;





C’est pas totalement faux. Java (et aucun langage en général) n’est pas exempt de défaut.&nbsp;









Fuinril a écrit :



Toujours pas de support de l’unicode <img data-src=" />





Ils l’avaient promis pourtant. Je sens que je vais rester en version 5.5 ou 5.6 longtemps encore.



Clairement. L’unicode est vraiment le point le plus bloquant du langage aujourd’hui, bien plus que les quelques déclarations syntaxiques qui ont été ajoutés.



Après reste le gain de perf, mais c’est déjà très satisfaisant avec OPcache….


Faut reprendre un peu PHP avant d’écrire n’importe quoi.



Effectivement y a pas de typage fort, par contre tu peux très bien typer tes arguments, simplement pas avec des types natifs. Mais soyons sérieux, dans une vraie appli, dans 99% des cas, les types d’arguments ne sont pas natifs. En majorité on retrouve des objets abstraits ou des interfaces…. ce que PHP permets….



Pour le temps de traitement on est sur de l’interprété donc c’est pas le typage fort ou faible qui fait la différence, et les pré-compilo déterminent un typage fort (ce qui entraine des bugs étranges d’ailleurs parfois).



Bref, PHP part d’un langage écrit sur un coin de table, mais aujourd’hui il y a vraiment peu de différences avec des langages plus élaborés…



Quant à la merde que l’on peut retrouver, il y en a plus en PHP parce qu’il y a plus d’amateurs. Mais de la merde j’en ai vu en C#, en Java, en PHP, en VB, etc….



Edit : d’ailleurs la plus grosse bouse que j’ai eu à reprendre c’était un projet en Java…








Fuinril a écrit :



Faut reprendre un peu PHP avant d’écrire n’importe quoi.







Voyons cela…





Effectivement y a pas de typage fort, par contre tu peux très bien typer tes arguments, simplement pas avec des types natifs. Mais soyons sérieux, dans une vraie appli, dans 99% des cas, les types d’arguments ne sont pas natifs.





Le but du typage fort, c’est de s’assurer que le type de toutes les variables utilisés tout à long de la chaîne est bien fixé pour tout et surtout, en tout point et à tout moment. C’est très différent du fait de simplement vérifier le type d’une variable à un point donné, celui ci n’étant pas fixé dans intervalle.



D’un point de vue technique, quand on ignore le type d’une variable, le doute subsiste sur la façon dont elle doit être traitée. Le problème impacte aussi bien la façon de stocker les variables que leur traitement tout à long de la chaîne. Et cela est valable aussi bien pour les types natifs que pour ceux qui ne le sont pas.





En majorité on retrouve des objets abstraits ou des interfaces…. ce que PHP permets….





Et qui n’est pas du tout l’idéal au point de vue traitement avec ce langage…





Pour le temps de traitement on est sur de l’interprété donc c’est pas le typage fort ou faible qui fait la différence,





Justement, la question qu’il faut se poser, c’est pourquoi un langage aussi utilisé a une aussi large échelle n’est même pas compilé….



Imaginez vous seulement ce que cela coûte en cycles CPU et donc en énergie à l’échelle du monde entier…





et les pré-compilo déterminent un typage fort (ce qui entraine des bugs étranges d’ailleurs parfois).





C’est justement la tout le problème. En l’absence de typage fort, il est impossible d’être certain du type d’une variable. D’ou un énorme problème quand on veut rendre ces langages plus rapides en allant vers la compilation.

Et tout cela sans compter certaines structures du langage qui se prêtent assez mal à l’optimisation, comme par exemple les tableaux associatifs. Et cela, la compilation n’y changera rien.



Il serait bon que les jeunes apprennent plus comment fonctionnent les langages à l’intérieur et pas seulement apprendre leur utilisation.



Cela étant dit, PHP dispose d’une marge de progression possible sur le plan des performances. Il est bon de constater que PHP 7 va dans cette direction.





Bref, PHP part d’un langage écrit sur un coin de table, mais aujourd’hui il y a vraiment peu de différences avec des langages plus élaborés…





Malheureusement, il s’avère qu’un langage ne s’affranchit jamais réellement de ses orientations de départ.



Les langages qui sont les plus efficient sur le plan de la vitesse d’exécution sont ceux qui ont été conçus au départ pour cela. Les autres ne le deviennent jamais.



D’ailleurs, il faut oublier le mythe du compilateur magique qui pourrait transformer avec la même efficacité n’importe quel langage.



Essaye C/C++ tu verra la différence de puissance et de rigueur. Même si ce langage n’est pas parfait et n’est pas adapté à tout, il montre un certain nombre de voies qui n’auraient jamais du être abandonnées. Et la première d’entre elle, celle de la rapidité d’exécution.





Quant à la merde que l’on peut retrouver, il y en a plus en PHP parce qu’il y a plus d’amateurs. Mais de la merde j’en ai vu en C#, en Java, en PHP, en VB, etc….





Certes, il faut se montrer juste, PHP n’est pas du tout le pire langage dans la pratique.



Je suis persuadé que les stagiaires arriveront à faire pire avec Node.js.





Edit : d’ailleurs la plus grosse bouse que j’ai eu à reprendre c’était un projet en Java…





Cela ne m’étonne pas une seule seconde.



Un certain nombre de concepts très utilisés en java aboutissent en pratique a une forte tendance à produire de la déstructuration et des plats de nouille…

Par contre, d’un point de vue performance, le langage lui même est plus facile à optimiser.

Reste que Java est un langage qui possède des carences, certaines complètement ridicules comme l’absence de type entier non signé.



Mais le plus amusant, c’est que l’évolution de tous les langages semble aller vers le pire. Je vous laisse deviner la prochaine révolution, celle qui pourrait bien cumuler les tares de Java avec celles de PHP… <img data-src=" />










tmtisfree a écrit :



Ils l’avaient promis pourtant. Je sens que je vais rester en version 5.5 ou 5.6 longtemps encore.





Ils n’avaient rien promis à AFAIK.

Quels sont les raisons pour lesquelles tu serais forcé à rester sur PHP5 ? (vraie question).



Sinon, considérant la quantité de message évoquant le typage ou les performances de Node.js, je suis étonné que personne n’est mentionné le support d’asm.js et ES6.



Pour les plus barbus extrémistes d’entre-nous, il reste l’option de développer votre application dans un langage compatible LLVM et générer votre code JS via Emscripten. Ça promet des heures de bonheur <img data-src=" />



On ne se connait pas, mais pour info j’ai plusieurs années de pratique de PHP dans les pattes (avec une belle mention senior sur mon CV), un peu moins d’années (mais années quand même) de C#, un peu de Java, un peu de C++…. bref, je ais de quoi je parle.



Dans l’absolu je suis d’accord avec toi, mais de façons réaliste ce que tu souhaites c’est :





  1. Pas réalisable. Coder un site en C++ ça m’est arrivé une fois, je ne le souhaite à personne.



  2. Excessivement dangereux. Stack overflow, memory limit… tout ça. Il y a bien assez de failles de sécurité sur le web avec un langage “sécurisé”….. Le fait que ce soit les devs les fautifs ne change rien à la donne.



  3. Il existe des tas d’outils pour “optimiser” la vitesse de rendu d’un site (websocket, varnish, etc…). Les gains constatés (que ce soit en terme de temps de traitement ou de charge) sont infiniment supérieur à tout ce que le compilé peut apporter. D’ailleurs c’est intéressant de noter que PHP va dans cette direction avec l’intégration d’OPcache en natif dans PHP 5.6…. ce qui permet de ne pas perdre la flexibilité de l’interprété tout en gagnant en perfs



  4. L’absence de type fort est une vraie tare. Sur ce point on est parfaitement d’accord, spécialement quand on fait du bas niveau. D’un autre côté comme bien 90% du dev PHP se fait sur framework et qu’à l’usage on utilise pratiquement que des structures en paramètre ca se gère…. Et pour le reste…. il y a des fonctions de vérification de type. C’est crade mais ça fait le job



  5. Même si la structure de l’objet array est immonde en PHP comparé à d’autres langages il y a moyen de ruser pour optimiser grandement les temps de traitement. Typiquement, sur de grosses structures, inverser le tableau et faire une recherche par clé (= adresse mémoire = indépendant de la taille du tableau) plutôt que de boucler sur du in_array



  6. Parfaitement d’accord sur le fait que les jeunes dev devraient apprendre à coder avant d’apprendre un langage. La plupart n’ont aucune idée de ce qui se passe derrière leurs lignes de code et c’est problématique pour la fiabilité, la performance, la propreté, etc….

    D’un autre côté quand on voit les “formations” prodiguées par l’ANPE “devenez dev en 3 semaines même si vous n’avez jamais allumé un ordi”, c’est malheureusement plus que compréhensible








sr17 a écrit :



Justement, la question qu’il faut se poser, c’est pourquoi un langage aussi utilisé a une aussi large échelle n’est même pas compilé….






  Parce que sur un site web, les contraintes en terme de performances dûes au choix du langage sont infiniment moindres comparé aux autres contraintes.        






  Tu fais manifestement partie des devs. avec option 'oeillières techniques' ; ceux qui n'ont toujours pas compris qu'un logiciel en informatique c'est une somme de contraintes et de compromis. Et que les performances sont très rarement les contraintes prépondérantes.        



&nbsp;



  Si par exemple la différence en perfs est compensable par un serveur 5k€ plus cher, il est totalement idiot de choisir de perdre 10k€ de productivité de par l'utilisation d'un langage plus performant mais plus strict et plus verbeux, qui demande des outil de compilation, d'intégration continue, etc..., et encore 10k€ de remunération supplémentaire pour rémunérer des 'experts' capables de pondre le code le plus optimisé qui soit (ou tout simplement parce que le marché de l'emploi fait que telle compétence est plus facile à trouver et donc moins chère que telle autre).        

&nbsp;

&nbsp;








Fuinril a écrit :



On ne se connait pas, mais pour info j’ai plusieurs années de pratique de PHP dans les pattes (avec une belle mention senior sur mon CV), un peu moins d’années (mais années quand même) de C#, un peu de Java, un peu de C++…. bref, je ais de quoi je parle.







Je n’ai jamais émis de doute sur tes compétences. C’est une simple discussion.



Pour ma part, je code depuis une époque très ancienne que la plupart ici n’ont pas connu.





Dans l’absolu je suis d’accord avec toi, mais de façons réaliste ce que tu souhaites c’est :





  1. Pas réalisable. Coder un site en C++ ça m’est arrivé une fois, je ne le souhaite à personne.





    Tout à fait réalisable. Mais logiquement pas du tout confortable pour l’instant. Pas la faute du langage, mais surtout du manque d’environnement adapté à cela.



    Pour ma part, je ne vois aucun obstacle sérieux pour que C/C++ ne puisse pas être un langage idéal pour cela dans le futur.





  2. Excessivement dangereux. Stack overflow, memory limit… tout ça. Il y a bien assez de failles de sécurité sur le web avec un langage “sécurisé”….. Le fait que ce soit les devs les fautifs ne change rien à la donne.





    Attention aux légendes.



    Ces problèmes concernaient principalement les vieilles applications développées en C. Avec les vieilles fonctions strxxx et la manipulation directe des pointeurs a tout bout de champ, la moindre erreur d’inattention suffisait à créer une faille.



    La médiatisation sur des failles en C (type Hearthbleed) concernent précisément des codes qui étaient écrites “à l’ancienne”, donc particulièrement sujettes à ce type de souci.



    Mais le style de programmation moderne C++ est beaucoup plus sécurisé. Par exemple, quand on utilise une classe validée pour manipuler les chaines, le risque de débordement est inexistant.



    D’ailleurs, si l’on ne pouvait pas écrire de programmes “surs” en C, on ne pourrait pas prétendre que PHP serait plus sûr… puisque PHP est écrit en C.



    Je suis totalement d’accord qu’il ne faille pas se fier au développeur. Mais un débutant ne se dirigera certainement pas vers une programmation “à l’ancienne” bien difficile quand on lui présente de jolies classes bien faites et simples d’utilisation.



    D’ailleurs au passage, attention à ne pas surestimer l’importance de failles de type buffer overflow. C’est en pratique bien plus difficile à exploiter que la plupart des failles de type SQL injection qu’on peut trouver assez souvent sur du PHP mal écrit.



    Ajoutons à cela que ces dernières années, les processeurs et les système d’exploitation ont ajouté de nombreuses protections pour augmenter notablement la sécurité du code natif et compliquer sérieusement l’exploitation des failles.





  3. Il existe des tas d’outils pour “optimiser” la vitesse de rendu d’un site (websocket, varnish, etc…). Les gains constatés (que ce soit en terme de temps de traitement ou de charge) sont infiniment supérieur à tout ce que le compilé peut apporter.





    Ce sont des outils utiles, mais ça ne fait pas tout. Il y a bien un moment ou il faut créer les pages, surtout quand elles ne sont pas strictement statiques.



    Certains géants du web n’auraient pas travaillé autant à l’optimisation de code PHP s’il suffisait de mettre en place des outils.





    D’ailleurs c’est intéressant de noter que PHP va dans cette direction avec l’intégration d’OPcache en natif dans PHP 5.6…. ce qui permet de ne pas perdre la flexibilité de l’interprété tout en gagnant en perfs[quote]



    Opcache ne fait que mettre en cache le bytecode. On reste encore très loin d’un langage compilé.



    Certes, on ne peut que saluer cette optimisation. Mais pour ma part, je dirais plutôt que c’était juste la moindre des choses.



    Comment as t’on pu utiliser aussi longtemps un langage qui n’avait même pas en standard une optimisation aussi triviale…. Un bon BASIC d’il y a 30 ans permettait déjà de sauvegarder/recharger les programmes sous forme d’opcodes…



    [quote]4) L’absence de type fort est une vraie tare. Sur ce point on est parfaitement d’accord, spécialement quand on fait du bas niveau. D’un autre côté comme bien 90% du dev PHP se fait sur framework et qu’à l’usage on utilise pratiquement que des structures en paramètre ca se gère…. Et pour le reste…. il y a des fonctions de vérification de type. C’est crade mais ça fait le job





    Je suis totalement d’accord que ça se gère. Mais c’est un obstacle pour devenir un langage optimal. Ceux qui ont voulu développer des outils pour accélérer PHP s’en sont rendu compte.



    Pour le reste, je ne suis pas totalement négatif sur PHP. Il a aussi ses points forts.



    Mais il est plus simple d’améliorer un langage qui est intrinsèquement performant.





  4. Même si la structure de l’objet array est immonde en PHP comparé à d’autres langages il y a moyen de ruser pour optimiser grandement les temps de traitement. Typiquement, sur de grosses structures, inverser le tableau et faire une recherche par clé (= adresse mémoire = indépendant de la taille du tableau) plutôt que de boucler sur du in_array





    Il y a toujours moyen d’optimiser pour les bons programmeurs. Mais au niveau vitesse de manipulation des structures et des objets, à côté de C++, c’est quand même bien la misère.



    Et d’ailleurs, quand on veut vraiment optimiser pour la vitesse en PHP, ça demande des modifications structurelles majeures. On perd alors tout ce qui fait le confort d’un langage comme PHP…





  5. Parfaitement d’accord sur le fait que les jeunes dev devraient apprendre à coder avant d’apprendre un langage. La plupart n’ont aucune idée de ce qui se passe derrière leurs lignes de code et c’est problématique pour la fiabilité, la performance, la propreté, etc….





    C’est clair.



    On ne peut pas écrire correctement un code de haut niveau si l’on a pas la moindre idée de ce que cela engendre à bas niveau.





    D’un autre côté quand on voit les “formations” prodiguées par l’ANPE “devenez dev en 3 semaines même si vous n’avez jamais allumé un ordi”, c’est malheureusement plus que compréhensible





    Je plains sincèrement ceux qui passent par ce genre de formation autant que ceux qui vont les employer…



    Mais ça ne sera pas la première, ni la dernière fois qu’on fait n’importe quoi dans l’illusion de se passer de vrais codeurs.



    Comme d’habitude, on va bien se marrer…



…suite





D’ailleurs c’est intéressant de noter que PHP va dans cette direction avec l’intégration d’OPcache en natif dans PHP 5.6…. ce qui permet de ne pas perdre la flexibilité de l’interprété tout en gagnant en perfs





Opcache ne fait que mettre en cache une forme d’opcodes. On reste encore très loin d’un langage compilé.



Certes, on ne peut que saluer cette optimisation. Mais pour ma part, je dirais plutôt que c’était juste la moindre des choses.



Comment as t’on pu utiliser aussi longtemps un langage qui n’avait même pas dans sa version standard une optimisation aussi triviale…. Un bon BASIC d’il y a 30 ans permettait déjà de sauvegarder/recharger les programmes sous forme d’opcodes…


Marrant au final on est parfaitement d’accord même si on appréhende pas les choses de la même manière. Dev desktop de métier je suppose ?