Le renouveau de PHP

PHP souffre d’une mauvaise image : ringard, vieux, rempli d’incohérences, utilisé par des étudiants qui bricolent des sites web entre deux réparations du PC de tata Suzanne, ou par des agences mange-stagiaires produisant des sites vitrines de mauvaise qualité et d’autres choses inavouables.

Soyons très clair. Tout cela est vrai (ou presque). Oui, PHP traîne une backward-compatibility titanesque ralentissant son évolution. Oui, c’est le langage le plus prisé par des gens développant médiocrement et pour qui la simple conclusion « ça marche » est suffisante. Oui, la gestion des dates peut être vraiment fatigante. Oui certains bugs reportés font peur. Oui, récupérer un WordPress ou un Drupal de 5 ans d’âge fait pleurer même le plus aguerri des développeurs. Non, personne ne se souvient jamais de l’ordre entre $needle et $haystack.

Mais pourtant, depuis un an ou deux, un vent nouveau semble souffler sur PHP et sa communauté. De nouveaux outils, bibliothèques et frameworks, d’excellente qualité, émergent, rendant de nouveau le développement en PHP rapide, agréable et fiable – qualités qui avaient causé sa forte adoption à l’origine.

Le langage en lui-même évolue, et de façon rapide et régulière : namespaces, fonctions anonymes (appelée closures en PHP), traits (semblables aux mixins en Ruby). L’organisation de la core team s’est également améliorée, vers plus de transparence, avec la mise en place de RFC permettant d’impliquer plus fortement la communauté, ou encore le déplacement du code source de PHP vers un dépôt Github.

Cependant, le plus important reste probablement l’écosystème qui a éclos et qui s’est structuré autour de PHP. Dans le but de faciliter l’interopérabilité, un groupe de projets avec des acteurs comme Zend Framework, phpBB, Symfony ou encore Cake PHP, s’est regroupé afin de proposer des standards cherchant à résoudre les problèmes récurrents lors de l’intégration de dépendances dans un projet : autoloading des classes, encodage, organisation logique du code. Ce collectif, nommé PHP Framework Interoperability Group (PHP FIG), comporte pour l’instant trois standards : PSR‑0, PSR‑1 et PSR‑2.

Bénéficiant de l’interopérabilité rendue simple, de nombreux projets se sont développés.

Le plus connu est sûrement le framework Symfony2, via ses « components » sur lesquels il est structuré. Chaque composant répond à une problématique technique précise et récurrente dans quasiment toute application web : centraliser et distribuer des événements, récupérer la requête HTTP demandée et construire la réponse adaptée, charger les classes, etc. Le but de ces composants est d’être le plus découplés et réutilisables possible, afin de pouvoir les intégrer « à la carte ».

Composer est un gestionnaire de dépendances pour projet PHP, ressemblant fortement à npm sur node.js. Grâce à un fichier JSON, il est possible de spécifier ses dépendances et leurs versions de manière très simple et rapide.

// composer.json
{
    "require": {
        "monolog/monolog": "1.2.*",
        "symfony/http-foundation": "v2.1.*"
    }
}

Un simple curl -s https://getcomposer.org/installer | php && php composer.phar install, et toutes les dépendances spécifiées sont téléchargées, proprement rangées et autoloadées dans votre projet. Un dépôt centralisé, Packagist, propose des zillions de packages, mais on peut également créer son propre repository grâce à Satis.

On peut aussi citer Silex, un micro-framework inspiré de Sinatra en Ruby, ou encore Express sur node.js.

<?php 
$app = new Silex\Application();    
$app->get('/hello/{name}', function($name) use($app) { 
     return 'Hello '.$app->escape($name); 
}); 
$app->run(); 

Le testing fourmille d’excellents outils comme atoum, framework ayant pour but de rendre les tests unitaires simples et rapides, ou encore Behat/Mink, permettant de tester ses applications web aussi simplement que :

Scenario : I can log in
  Given I am on '/'
  When I click on "Login"
  And I fill in "Username" with "John"
  And I fill in "Password" with "foo"
  Then I should see "Welcome aboard John! You're successfully connected"

Lancez un simple behat /feature/login.feature et vous pouvez voir votre navigateur préféré se lancer, cliquer sur le bouton de login et vérifier que votre fonctionnalité d’identification fonctionne correctement.
D’autres projets sont encore plus bluffants, comme React-php qui fournit une API d’I/O non bloquantes « orientée événement », très similaire à node.js.

<?php 
$loop = React\EventLoop\Factory::create(); 
$socket = new React\Socket\Server($loop); 
$http = new React\Http\Server($socket, $loop); 
$http->on('request', function ($request, $response) { 
     $response->writeHead(200, ['Content-type' => 'text/html']); 
     $response->end('Hello World!'); 
}); 
$socket->listen(1337); 
$loop->run();

La liste de ces excellents projets étant réellement longue, en voici déjà une palanquée.

  • Guzzle : PHP HTTP client et framework pour webservice.
  • Faker : Générateur de jeux de données aléatoires : nom, adresse, dates, etc. Finie la tâche ingrate de remplir la base de données de test manuellement.
  • Geocoder : Transforme des adresses postales ou IP en coordonnées GPS (geocoding) via différentes API telles que GoogleMaps, Bing Maps ou autres.
  • Assetic : Mini-framework manageant les assets, inspiré de webassets (Python), Assetic concatène et minifie CSS et JS, compresse les images, ou encore compile LESS/Sass afin d’obtenir des performances optimales côté client.
  • Gaufrette : Abstraction du système de fichiers, Gaufrette permet d’écrire sur le disque, mais aussi en RAM, sur FTP, GridFS, Amazon S3, Rackspace ou encore sur Dropbox, à travers une unique API unifiée.

Un dernier point, très souvent reproché à PHP, est le volume absolument titanesque de mauvais tutoriels, de mauvaises recommandations et de pratiques à éviter qu’on trouve sur internet. C’est, là aussi, très vrai, mais même cela change. PHP The Right Way est un recueil de bonnes pratiques qui essaye de proposer une documentation facile à lire, permettant de donner les bonnes habitudes à tout nouveau développeur PHP, et fournissant une liste de ressources et de liens de qualité. Créé par Josh Lockhart, le projet est actif et compte de nombreuses contributions de la communauté.

Ne soyons pas fous, tout n’est pas rose, mais PHP se renouvelle et bouge beaucoup, et ce dans le bon sens. Entre cet écosystème qui a vraiment posé la barre haut en termes de qualité, la simplicité du langage et la taille de la communauté des développeurs PHP, je pense que PHP a beaucoup à proposer et encore de beaux jours devant lui.

24 commentaires sur cet article

  1. Olivier, le 6 décembre 2012 à 14:15

    @Clément Oui PHP bouge ! Mais il tourne en rond ! C'est un language qui évolue au grès du vent, sans une réelle vision conceptuelle donnant une ligne directrice. On entends parler d'objets, hop on ajouter des trucs, on entends parler de modules, hop on ajoute des namespaces, on entends parler de closures, hop on ajoute des trucs ... Ainsi de suite ce qui fait qu'on arrive devant un patchwork décousu, on a un language object mais qui n'est pas 100% object, on a un language fonctionnel, mais qui n'est pas 100% fonctionnel, on a un language compilé mais qui voudrait être dynamique ... and so on.

    J'attends avec impatience, le jour où les concepteurs vont se poser est réfléchir réellement à une re-structuration du language avec un break de compatibilité obligé pour tout remettre à plat et léver les abérations. La notoriété de PHP et son utilisation massive montre qu'il mériterai bien un lifting force 7.

  2. Flavien Metivier, le 6 décembre 2012 à 14:26

    @Olivier mes remarques ne concernent en rien les critiques étayées mais les critiques à l'emporte pièce du type "java c'est lent", "php c'est sale", "le MVC c'est mal", "c'est pas objet c'est mal", la plupart du temps formulées par des personnes n'ayant jamais ou peu utilisaient le/les langages ou concepts. Quand je parle de lacunes des langages, ce que je voulais exprimer c'est que chaque langage n'est pas adapté à tous les besoins. Par exemple, je ne vois pas utilisé du C pour faire un site web même si c'est possible, ni faire une appli en client lourd en php.

  3. Olivier, le 6 décembre 2012 à 14:37

    @Flavien Je te rejoins sur les remarques à l'emporte pièce. Mais ce type de critiques vident de sens sont démasqué au premier coup d'oeil.

    Alors il vaut mieux utiliser le mot "spécificité" que "lacune" car ça n'a pas du tout le même sens sinon :)

    Et pour te taquiner un peu, toutes les interfaces de paiement électronique web son en général développées en C ou C++ ... Ah ah, bon je l'avoue je taquine un peu car j'ai bien compris le sens de ta dernière remarque.

  4. Flavien Metivier, le 6 décembre 2012 à 14:48

    @Olivier oui, elles sont vite démasquées mais usantes, parce que les remarques constructives et/ou étayées sont noyées dans leur flot.

  5. tzi, le 6 décembre 2012 à 18:22

    Impressionnant ce que PHP lance comme débat !

    Je rejoins complètement l'article, ce qui fait la force de PHP n'est pas intrinsèque, ma c'est sa communauté.

    Ce ne sera plus jamais un langage jeune. PHP a de nombreux défauts lié à son historique, ce que node ou Ruby n'a pas ! Mais PHP regroupe beaucoup de monde. Notamment parce qu'il est simple à faire tourner et héberger. Sa communauté est active et fait plein de choses intéressantes.

    Donc les défauts de PHP, selon moi, est un débat un peu inutile. Puisque ce n'est pas ce qui m'intéresse dans le langage ;)

    Merci pour cet article !

  6. Olivier, le 6 décembre 2012 à 21:13

    @tzi : Coluche en son temps avait dit : "Ce n'est pas parce qu'il sont nombreux à avoir tort qu'ils ont raison"

    Elle a quoi de si extraordinaire la communauté PHP ? Quel concept, approche innovante ou idée motrice est issue de la communauté PHP ? (au sens intéressant pour d'autres communautés, je parle ici de conceptualisation du développement web)

    Par contre, quand je regarde ailleurs, d'autres communauté, principalement python, ruby (et pour le mvc web java), je vois l'émergence de :

    • MVC (java 2000-2004)
    • DRY, Routing, Rack (Ruby)
    • Generator (au sens: du framework)
    • TDD
    • Testing, Rspec (Ruby : aucune lib et dev web sérieux sans tests)
    • Compass, LESS, SASS, SCSS (Origine Ruby, meilleure gestion css)
    • Asset pipeline avec Sprockets (intégré dans le framework depuis RoR 3 / tentative de copie en php avec Assetic)
    • Cucumber (ruby tests BDD très innovants / tentative de copie en php : Behat)

    Etc ... Quelques exemples de concepts et idées ayant émergés et eu un impact sur le développement web en général. Je fais du PHP depuis quelques temps maintenant (98) et honnêtement j'ai rien vu de remarquable émerger autour de php ou qu'il soit copié ailleurs ... ça donne une idée ...

    Peux-tu m'indiquer ce que tu observes avec intérêt dans cette communauté ?

  7. tzi, le 6 décembre 2012 à 22:51

    @Olivier : Tu rentres dans des concepts techniques. Je dirais même d'innovation. Je pense qu'il y a aussi de l'innovation en PHP, sûrement moins, de toute façon c'est difficilement mesurable. Et je ne pense pas que ce soit là l'intérêt de la communauté PHP :)

    Comme dit tout le monde, il y a assez de gens dans le communauté PHP pour copier toutes les bonnes idées qui se passent ailleurs. C'est déjà énorme ! Les exemples de @naholyr sont très bien : les traits, les closures, Composer, etc.

    Un autre bon exemple, tu peux regarder le nombre de CMS, de Framework, d'outils, de ressources qui existent pour PHP. Ils ne sont peut-être pas tous innovant, mais la plupart sont intéressants.

    Alors ce n'est pas un langage jeune, ce n'est pas le plus innovant, mais on ne peut pas dire qu'il n'y a pas d'émulation dans sa communauté ;)

  8. Olivier, le 7 décembre 2012 à 3:51

    @tzi : Il faut rentrer dans les concepts, c'est ça le dév, sinon c'est ctrl+c ctrl+v toute sa vie ;)

    "Comme dit tout le monde, il y a assez de gens dans le communauté PHP pour copier toutes les bonnes idées qui se passent ailleurs. C'est déjà énorme !" Personnellement, cette idée est plutôt à l'opposé de ma philosophie de vie, je préfère la créativité et l'imagination.

    "Un autre bon exemple, tu peux regarder le nombre de CMS, de Framework, d'outils, de ressources qui existent pour PHP." Justement, c'est le thème du post de Clément, trop de ressources de basse qualité. Evidemment tu as des centaines de framework, mais ça sert à quoi ? Surtout quand tu as 95% presque tous les mêmes ou de basse qualité, quel est l'intérêt ? Cela dit, le dernier qui m'a intéressé est Laravel, c'est le premier que je trouve vraiment intéressant sur la reprise de certaines idées utilisant avec finesse les dernières versions de PHP. (je fais beaucoup de veille techno aussi, c'est une passion ;)

    Les traits et les closures, sont empruntés à des languages dynamiques (ou interprétés), forcément lorsqu'on souhaite appliquer les concepts sur un language compilé ou non dynamique ça coince et on tombe sur des implémentations bancales. Toujours à cause du scope (ou contexte d'évaluation). J'ai du mal a saisir comment on peut se réjouir d'avoir quelque chose de bancal.

    A vrai dire si je m'insurge, c'est tout simplement parce que je suis un utilisateur du language PHP depuis très longtemps. Surtout forcer par l'industrie, européenne et française (SSII) qui pose des oeillères technologiques pour se simplifier la vie (d'où la fameuse expression qu'on a pu entendre : la dette technique). C'est très dommageable surtout pour les développeurs que l'on enferment dans deux ou trois technologies à vie, c'est triste. De plus cela ne créé pas de compétitivité inter-technologies et pousse au conservatisme.

    Mon souhait réel et d'avoir un meilleur language exempt d'aberrations, de casseroles et surtout qui part dans tous les sens au grès du vent. Mais aussi, une communauté qui arrête de tourner en rond et se plait dans la copie et l'a peut prêt du language. Il faut un break de compatibilité et cleaner le language, lui donner une vrai direction et arrêter de prendre des bouts de concepts à droite à gauche est empiler tout ça ... PHP et les devs ont tout à gagner à faire ça.

  9. Phollow, le 8 décembre 2012 à 19:49

    Je dirais juste “Amen” à Olivier qui voit les choses de la même façon que moi. Sauf que j’ai même plus le courage de dire aux développeurs PHP d’aller voir ailleurs. Depuis que j’ai regardé le code source du langage en fait.

  10. Fabien, le 9 décembre 2012 à 13:31

    Salut à tous,

    super intéressant ce débat.. même si je ne comprends pas tout (exemple "namespaces, fonctions anonymes (appelée closures en PHP), traits (semblables aux mixins en Ruby). L’organisation de la core team s’est également améliorée, vers plus de transparence, avec la mise en place de RFC").

    Je pense faire partie de la catégorie de ceux qui "bricolent des sites web entre deux réparations du PC de tata Suzanne..." mais je suis désireux d'en savoir un peu plus ! Notamment à partir cette phrase "pour qui la simple conclusion « ça marche » est suffisante."

    En deux mots assez simple, on lui reproche quoi à PHP : d'être lourd et pas élégant c'est ça ? Aux niveaux des utilisateurs des sites concernés, cela se traduit par une certaine lenteur ?

    Bon.. de toute façon j'avais bien l'intention de me former sur Ruby. Vous me le conseillez ou je me fourvois encore ?

    J'espère que mon côté béotien ne vous agacera pas trop... Cordialement

  11. Olivier, le 13 décembre 2012 à 3:44

    "Koman khe je peut t'espliker la diff ?" -> ça marche et c'est suffisant.

    "Comment pourrais-je t'expliquer la différence ?" -> ça marche aussi, mais je trouve ça plus joli :)

    Blague à part, pour saisir pourquoi certains argumentent sur l'élégance ou non des languages, il est nécessaire d'avoir un bagage théorique est une longue pratique de plusieurs languages de types différents.

    Un bagage théorique qui implique d'avoir des notions sur les principaux concepts des languages, les différents types de languages ainsi que sur les façons de les implémenter. Languages statiques, dynamiques, interprétés, fonctionnels, procédurals, objets, mais aussi de nombreuses autres notions, AST, homoiconicity etc ... C'est un sujet très complexe.

    Aujourd'hui le problème et que l'industrie à adopté principalement les languages objets ...

    On ne peut se risquer à comparer un language ou valider un langage sans avoir les notions nécessaires requises pour la bonne analyse.

  12. Fabien, le 17 décembre 2012 à 13:17

    Merci pour ta réponse... Ton exemple me parle plus que l'explication elle-même ;) Je manque sans doute de bagage théorique mais je suis assez sensible à l'argument esthétique.

    "le problème et que l'industrie à adopté principalement les languages objets" Ce n'est un problème que si l'on veut travailler dans l'industrie non ?

    Parce que si finalement le défaut du php concerne essentiellement un certain confort, voire un certain esthétisme, cela regarde le développeur... S'il travaille seul, personne n'ira voir dans son code. Pour reprendre ton exemple, personne ne va aller dénicher les fôtes d'ortaugraf dans ma liste de course ou mes brouillons.

    PS : "Aujourd'hui le problème EST... " désolé , je n'ai pas pu résisiter ;)

  13. Olivier, le 18 décembre 2012 à 2:09

    @Fabien,

    On peut faire une analogie avec les langues parlées, mes exemples ne sont pas choisit au hasard :) Le premier est pauvre en grammaire et sémantique, orthographe hasardeuse et dans ce language il y a fort à parier qu'il y aurait peu de temps de conjugaisons.

    Et à mon sens, l'impact si tu écrit un roman avec ce language pauvre, tu auras plus de problèmes pour exprimer avec finesse et subtilité tes idées, images, métaphores, etc. Car la langue, manque elle même de construction. Je pense que l'on écrirait pas les mêmes livres, essais et poèmes ...

    A mon avis, si tu étudie et t'amuse un peu avec Ruby quelques jours, tu vas vite découvrir, une grammaire claire, une syntaxe propre, une consistance et une intégrité, un pouvoir expressif élégant (qui donne parfois cette impression de lire le code comme on lit on livre). Le language en devient plaisant et on prend réel plaisir à s'exprimer avec des lignes de code.

  14. Olivier, le 18 décembre 2012 à 2:20

    @fabien,

    "le problème et que l'industrie à adopté principalement les languages objets" Ce n'est un problème que si l'on veut travailler dans l'industrie non ?

    Il ne faut pas le regarder sous cet angle.

    Il faut envisager cela en termes de performance du secteur, le fait que le lobby des SSII impose en grande majorité php, java ou .net cela fait perdre de la compétitivité au secteur français et en partie européen par rapport au marché Amérique du Sud et Nord ou il n'y pas d'informatique de services. Donc pas de lobby pour imposer des technologies et une vraie compétivité inter-technologies. C'est ce que nos politiques commencent à appeller la "dette technique".

    Il suffit de regarder le code source de 80% des startup US pour voir qu'il y a une chute énorme de l'utilisation de php au profit de RoR, à méditer ...

    Et puis, aujourd'hui quand on voit la réussite des languages dynamiques, on ne devrait pas se permettre de passer à côté de technologies comme celle de Ruby On Rails. C'est la compétivité complète de notre secteur d'activité qui en dépend.

  15. Olivier, le 18 décembre 2012 à 2:25

    "Parce que si finalement le défaut du php concerne essentiellement un certain confort, voire un certain esthétisme, cela regarde le développeur... S'il travaille seul, personne n'ira voir dans son code. Pour reprendre ton exemple, personne ne va aller dénicher les fôtes d'ortaugraf dans ma liste de course ou mes brouillons."

    Cette approche ne tient pas, par le seul fait que plus personne ne travaille seul en faisant 100% du code. On est en plein dans l'âge d'or de l'open source, tout le monde utilise au moins une librairie ou un framework qu'il n'a pas écrit. A vrai dire aujourd'hui même plusieurs ...

  16. Fabien, le 28 décembre 2012 à 15:59

    ok, très intéressant, merci pour les réponses ;)

  17. Olivier, le 29 décembre 2012 à 12:55

    Cela reste mon opinion et cela n'engage que moi ... ;-)

  18. Fdutey, le 28 février 2013 à 10:18

    Comme d'hab, on prend les memes et on recommence.

    Aaaah php. Le langage qui veut evoluer. Le langage est a l'image de ceux qui le developpent et ceux qui l'utilisent:

    Tout n'est traite qu'en surface. Chaque fois qu'on decouvre une nouvelle biblio php, on se rend compte tres vite que celui qui l'a code ne s'est absolument pas appuye sur une RFC (webservices rest par exemple) mais sur ce qu'il avait compris au moment ou il en avait besoin. En general il n'y a pas de tests unitaires (ou tres sommaires qui ne verifient surement pas le netier) donc aucune garantie sur le code livre, mais ca colle plutot bien avec le fait que le mec n'ait pas lu la RFC => il ne sait pas ce qu'il doit tester ni a quoi s'attendre mais osef, ca marche pour ce qu'il a a faire (ce qui est l'argument recurrent pour justifier l'utilisation de php).

    Php veut evoluer mais php traine toujours ses millions de bugs et bizareries a la con qui en font un langage totalement inconsistant (intransitivite des operateurs par exemple). Php est a la base un langage procedural a typage faible. Puis on y a ajoute une couche objet batarde en version 4 reecrite sur le modele de java (en apparence, on est en php ne l'oublions pas!!!) en version 5. On a donc introduit des concepts sortis d'un langage a typage (interfaces, typehint...) strict pour les introduire dans un langage a typage faible... Ca commence a etre n'importe quoi. Et depuis php 5.3 / 5.4 on ajoute des choses (mixins, closures) qui viennent de langages prototypes, donc totalement incompatibles avec un typage strict. Php est un langage prototype sous le capot mais cela est masque. Et on livre a des developpeurs qui sont bien souvents ceux qui ne comprennent absolument rien aux mecanismes mis en oeuvre par la prog objet (desole de le dire mais c'est vrai) une sorte de couscous boulette de tous les mecanismes de tous les types de langages en se disant que si on prend tout ce qui est bien partout et qu'on met tout ensemble, ca fera un truc bien.

    Ceci dit, c'est coherent avec php. Langage no brain. On n'est pas foutu d'implementer l'utf8 correctement apres 6 ans d'efforts (on est bientot a l'utf16 les mecs) mais on se touche grave la nouille sur des concepts qu'on n'a pas vraiment compris et qui ne nous servent a rien comme les mixins...

    Et on retrouve ca dans toutes les biblios qui "marchent".

    CakePhp => rails 1 (le 4 vient de sortir pour info) Symfony 1 => espece de copie pourrie de rails toute moisie Symfony 2 => on est passe de rails a spring, donc de ruby a java, en introduisant le IOC en php. C'est cool, sauf que faire du IOC demande certaines notions assez specifiques pour l'utiliser correctement. Dois je preciser que je n'ai jamais vu un developpeur php qui connaissait le mot IOC et encore moins sa signification Silex => on a copie sinatra, ni plus ni moins, avec toutes les limitations de php evidemment Composer => tiens, on n'aurait pas copie bundler des fois?

    Un vrai langage de programmation est construit autour d'un paradigme. Un ensemble de conventions que l'on va retrouver partout et qui vont aider l'ensemble des contributeurs a se comprendre en quelque sorte. Je suis un Rubyiste et j'ai fait pas mal de Java. Quand je regarde les sources d'un projet Java ou Ruby, je percois tres vite les grandes lignes parce qu'on retrouve tout de suite les paradigmes qui entourent le langage. En php, il n'y a pas de paradigme. Le paradigme c'est "j'y comrpends rien et je veux surtout pas faire l'effort de". Du coup personne comprend personne. Rien ne marche ensemble. Chaque framework recode l'univers. Installer une dependance demande des heures de lecture de doc et surtout des sources pour parvenir a ses fins sans janais etre sur de rien. Rien n'est maintenu... bref, l'horreur =))))

    A bon entendeur.....

  19. mickaelandrieu, le 10 mars 2013 à 14:20

    don't feed the troll :) l'IOC, c'est donner le contrôle de ton programme au framework.

    Un dev' PHP (mais pas que).

  20. Nicolas, le 16 mars 2013 à 12:33

    Le problème avec PHP ce n'est pas PHP mais les développeurs, surtout ceux qui s'y penchent par obligation alors qu'ils sont plus à l'aise avec d'autres langages nativement structuré tel que Java.

    Beaucoup d'ingénieurs sorti d'école après quelques notions de Java ou autre, attendent que PHP offre une organisation et un pragmatisme figé alors que c'est eux de créer cette surcouche (ou d'en utiliser une existante tel qu'un framework)... Ce n'est pas le cas alors ils en déduisent que PHP c'est pourri par ce qu'ils confondent typage dynamique avec faible typage tel que notre ami Fdutey, ne vérifient pas leur code (variable indéfini, respect du typage, sécurité, ...), etc

    PHP permet de partir de 0 pour créer une surcouche d'organisation, par exemple Symfony2 qui apporte une approche Java à PHP (perso je trouve anti-productif mais bon ...). Silex / Slim / Laravel une approche très Javascript avec des déclarations en closure. A chacun son approche, pour ma part même si parfois je suis obligé de développer avec des usines telles que Symfony2, j'évite autant que possible surtout pour des projets à forte audience.

    @Fdutey : si tu cherches php IoC sur Google tu verras que de nombreux développeurs connaissent le mot et utilisent abondement l'IoC même hors de Symfony2.

    Tu trouveras même de l'AOP en PHP ... Bref PHP n'est que le socle, à chacun de choisir son organisation et son pragmatisme avec PHP ...

    Un autre dev' PHP (mais pas que).

  21. Lumin0u, le 14 avril 2013 à 21:57

    @Nicolas

    "ils en déduisent que PHP c'est pourri par ce qu'ils confondent typage dynamique avec faible typage"

    le typage de PHP est faible (en plus d'être dynamique), il n'y a aucun doute là dessus.

  22. bruno vibert, le 30 avril 2013 à 14:28

    PHP représente à ce jour 78,9% du code (serveur) exposé sur internet (source http://w3techs.com/technologies/overview/programming_language/all). En regard, environ 30% des failles de vulnérabilités connues sont liées à PHP, non pas au langage lui-même, mais plutôt à l'utilisation qui en est faite par les développeurs (source https://en.wikipedia.org/wiki/PHP#Security).

    Pourquoi un langage si peu "élégant" (ce n'est plus à démontrer) séduit-il tant : certes, il est facile à appréhender, on peut presque tout faire avec (plus ou moins efficacement), mais je pense qu'il s'agit plus, de nos jours, d'une raison économique, je m'explique.

    Le développeur autodidacte, qui a fait ses premières pages web à la fin des années 90 pour se promulguer "webmaster" puis "ingénieur" pour des startup cherchant de profils bidouilleurs/multi-tâches est aujourd'hui beaucoup moins cher qu'un ingénieur Java certifié. Ne cherchez pas de développeurs RoR en France : j'ai essayé, il y en a 12 en France et ils côutent 3 000 €/jour (j'exagère à peine).

    Ceci vient également du fait que la concurrence est plus grande : je ne sais pas combien il y a de développeurs PHP dans le monde, mais si l’hégémonie est la même que pour les langage de script serveur, ils doivent dépasser en nombre le total de tous ceux des autres langages !

    Pour parler de la communauté, il suffit de regarder le nombre de scripts partagés sur HotScripts. A eux seuls, ils représente près des 2/3 !

    Alors certes, vous pouvez qualifier ce langage de "pourri", le fait est qu'il plait aux clients (pas tous bien sur) qui cherchent à serrer un peu le budget et de la réactivité pour leurs évolution (on peut faire vite ET crade en PHP, même si je ne préconise clairement pas la méthode).

    Alors professionnaliser PHP, apporter + de contraintes (sécurité, développements, tests, etc.) au niveau des dév, d'accord, mais ceci n'aurait-il pas pour effet de réduire très fortement le nombre de personne maitrisant réellement la technologie, d'augmenter le prix jour x homme, au profit d'autres langages ?

    Tout est affaire d'équilibre....

  23. Nicolas, le 4 juin 2013 à 13:05

    @Lumin0u : effectivement, je me suis mal exprimé :) Je ne voulais pas parler du typage fort dont le type est stoqué avec la variable, typage faible pas de type stoqué.

    Je parlais surtout de l'amalgame souvent rencontré du style typage faible = absence de typage ou typage fouareux, par rapport à la remarque de @Fdutey qui tend dans ce sens dans son commentaire :

    ""On a donc introduit des concepts sortis d'un langage a typage (interfaces, typehint...) strict pour les introduire dans un langage a typage faible... Ca commence a etre n'importe quoi.""

    Alors qu'il s'agit de liberté offerte par PHP (typage strict ou pas selon le besoin).

    Liberté qu'on peut reprocher bien sûr mais il faut voir où est le besoin (si besoin de typage fort, alors d'autres langages sont plus appropriés, inutile de cracher sur PHP et les dev PHP).

  24. Fabien, le 10 août 2013 à 19:08

    PHP souffre incontestablement de pas mal de lacunes lorsqu'on le compare à d'autres langages modernes : incohérence dans le nommage des fonctions, syntaxe verbeuse et peu élégante, fonctions redondantes, modèle objet atypique, gestion des erreurs chaotique, etc., et les projets récents qui tentent d'apporter un peu de sérieux et de rigueur à son utilisation sont à mon sens une bonne chose.

    Toutefois, en dépit de tous ses défauts, PHP reste encore, notamment grâce à sa facilité d'accès et à sa grande souplesse/permissivité, le langage de prédilection pour toute personne qui souhaite réaliser rapidement un site Web avec un rapport coût/performance acceptable. Les RoR et autres Django (qu'on compare erronément à PHP alors qu'il s'agit de frameworks) amènent indéniablement à de meilleures pratiques de programmation, mais leur complexité les rend peu apte à la gestion de petits projets, sans compter les problèmes associés à leur mise en place (rareté des hébergeurs, configuration des serveurs, compatibilité Ruby/Windows, etc.). PHP reste, et probablement restera, un langage avant tout conçu pour le Web (contrairement à Ruby ou Python) et pour les non-programmeurs de métier, et c'est là sa plus grande force (mais aussi ses limites).

Il n’est plus possible de laisser un commentaire sur les articles mais la discussion continue sur les réseaux sociaux :