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.

48 commentaires sur cet article

  1. Kaelig, le lundi 3 décembre 2012 à 00:43

    Merci beaucoup pour cet article qui redonne vraiment de l’espoir en cette plateforme que je comparerai presque à l’IE6 des langages.

    Ça me fait d’autant plus plaisir que je rejoins une équipe qui travaille avec Symfony. Venant d’un esprit plutôt Ruby-esque, c’était assez démoralisant (avant la lecture de cet article !).

  2. Naouak, le lundi 3 décembre 2012 à 07:35

    Ca ne corrige pas l’un des problèmes majeur de PHP : il cherche à faire tout sans bien se spécialiser dans quelque chose.

    Je crois personnellement à des cycles avec les technologies de serveur web. Il ne faut pas faire évoluer les vieux mastodontes mais faire évoluer les plus jeunes qui ne souffrent pas d’un patrimoine l’empêchant d’évoluer convenablement. PHP a vécut suffisamment longtemps, il est temps pour lui de se retirer pour laisser place aux nouveaux entrants comme node.

  3. MoOx, le lundi 3 décembre 2012 à 08:54

    Tout petite note par rapport à Assetic : pour un développeur front-end, je trouve ça assez pénible et contre productif à utiliser (je dis ça en étant l’auteur de 2 filtres), dont le filtre Compass, surcouche de Sass (et non SASS :p).

  4. Roberto Pulli, le lundi 3 décembre 2012 à 09:33

    Et sinon, ça gère l’UTF8 maintenant ? (nativement, sans s’arracher les cheveux avec ICU et les fonctions mb_*)?

  5. Capitaine Mousse, le lundi 3 décembre 2012 à 09:34

    @MoOx : non je ne trouve pas. Assetic peut très bien fonctionné avec Compass/Bourbon… sans aucun problèmes. Au lieu de faire un « compass watch », Assetic s’occupe de tout

    Très bon article sinon, mais dommage que des framework comme Fuel, Laravel ou Lithium ne soit pas présentés :)

  6. IAmNotCyril, le lundi 3 décembre 2012 à 09:40

    Voici ce que j’ai retenu de cet article : après « l’innovation à la française » où on prend des concepts étrangers (inb4 Américains à 90%) en enlevant des features qui sont cools, voici l’innovation à la PHP : traduire ce qu’il se fait en Ruby, JS/Node.js en PHP.

    Je ne suis pas convaincu que cet article aide à définir à proprement parler un « renouveau » en sens strict du terme :)

  7. Benoit, le lundi 3 décembre 2012 à 09:43

    Merci pour ton article constructif.

  8. Clement Herreman, le lundi 3 décembre 2012 à 10:35

    @Kaelig : après je te promet pas que les toutes les équipes PHP sont Ruby-esque non plus ! Mais Symfony est vraiment agréable. Certaines parties semblent (pas toujours à tort) over-engineered, mais une fois pris en main, c’est quand même très puissant.

    @MoOx : idem, je fais pas mal de frontend, et Assetic tape un peu sur le système parfois. Attendre le temps de build a chaque refresh est un peu fatiguant, mais c’est gommé par les avantages en production je trouve.

    @Naouak : c’est vrai que PHP cherche a faire un peu tout, et n’est pas forcément adapté à tout. Mais il couvre 80% des besoins, ce qui est plutôt agréable. Pour les 20% restants, il y a d’autres outils plus adaptés, et je les utilise avec plaisir :)

  9. Drhelmut, le lundi 3 décembre 2012 à 10:58

    Bravo pour ton article mais… comme tu le dit en introduction, php souffre de nombreux défaut… est-ce que ça vaut vraiment le coup, in fine, de chercher à l’améliorer là ou d’autres languages apportent du sang neuf (ruby/rails) ou de la robustesse éprouvée (java) pour le développement d’application web ?

    Tu ne cites que la rétro-compatibilité comme « poids négatif » qui pèse sur le langage : pour moi c’est la base même de sa conception qui le limite : être interprété, donc terriblement lent au runtime ; sa syntaxe objet horrible, son manque de rigueur par son typage faible… (bonheur pour les débutants, horreur pour les confirmés..)

    Bref. Ton post me servira clairement de référence si je dois un jour replonger dans du code php, mais à titre perso je n’irais plus jamais vers cette techno pour créer un site web (ou alors via un cms)

  10. Nicolas Chambrier, le lundi 3 décembre 2012 à 11:50

    Je suis d’accord avec l’essentiel de l’article. On voit effectivement bien que PHP arrive à rebondir, mais ça fait un bail qu’il n’innove plus. Les traits ? Ça existe dans Ruby depuis que le langage existe. Les closures ? JavaScript les gère « like a boss » depuis 1995. Composer ? npm. On peut continuer ainsi sur toutes les features récentes. Attention ne me faites pas dire ce que je n’ai pas dit : je ne reproche *absolument pas* à PHP de « copier », ça m’importe peu et c’est même plutôt sain à mon sens. Par contre je constate qu’il ne fait que *tenter* de rattraper son retard par rapport aux autres.

    L’analogie avec Internet Explorer est hélas de plus en plus vraie : perpétuellement à la traine, il essaie de rattraper son retard en faisant à peu près ce que font tous les autres, mais généralement moins bien. Et au final on a une espèce de blob informe, qui n’a toujours pas choisi sa voie…

    Sans compter les problèmes d’API : qu’elle soit pourrie n’est pas un problème en soit, si seulement on acceptait à un moment ou un autre de l’oublier ! Or là, on paie un problème fondamental de PHP : tout est dans le core. Donc essayer de casser une back-compat est extrêmement compliqué, voire impossible.

    Tout n’est pas noir, et je suis d’accord sur le fait que la communauté est extrêmement positive et active. C’est très plaisant quand on baigne dedans ;) mais sorti de ça… on aura beau passer des couches de peinture, les fondations restent trop mauvaises.

    @Naouak ouh la non, node ne pourra jamais détrôner PHP. Ni Ruby, ni Python, ni Java, ni personne actuellement. Pas tant qu’il sera aussi simple à faire tourner sur un Apache, qui lui non plus n’est pas prêt d’être détrôné :)

  11. morphine, le lundi 3 décembre 2012 à 14:51

    Je trouve cet article contradictoire avec l’article précédent sur la vitesse d’affichage. Je m’explique : Un site web Zend Framework, Symfony ou Cake PHP (pour ceux que je connais et testé) est lent en production (voir lent à développer aussi, même en les connaissant bien) : c’est une horreur !!! Même pour des gros extranets je préfère mille fois utiliser un framework maison, simple et amélioré avec les années. De toute manière tous les frameworks MVC sont lents. De plus, et ce serait trop long à donner mon point de vue complet, une programmation MVC est contre nature pour un projet web en PHP (je précise bien en PHP). Pour comprendre pourquoi ces frameworks sont lent, c’est très simple : faire un « get_included_files() » à la fin de la génération d’une page (généralement après l’appel au « router ») : une cinquantaine de fichiers minimum pour l’affichage d’une simple page avec base de données. On marche sur la tête.

  12. Erp Derp, le lundi 3 décembre 2012 à 17:04

    En résumé, la base est pourrie et tout le monde le sait, mais surtout surtout il ne faut pas y toucher mais faire des surcouches pour « faciliter » le développement !?

    Euh…

  13. Clement Herreman, le lundi 3 décembre 2012 à 17:39

    @Roberto : Les fonctions mb_* sont quasiment natives, puisque présentes dans 99% des cas. Il est aussi possible de remplacer les fonctions str_* par mb_* à la compilation, rendant le code précédemment écrit, compatible UTF‑8. En dehors de ça, c’est surtout de bien configurer Apache, les DB et les locales des users au niveau de l’OS qui assurent un UTF‑8 correct.

    @IAmNotCyril : je suis d’accord, PHP prend ce qu’il y a de bien chez les autres, et c’est ce qui me plait aussi. Ce billet (http://blog.astrumfutura.com/2012/04/php-innocent-villagefolk-or-a-pillagin-pirate/) résume bien mon point de vue là dessus. Tout le défi est de justement ne plus rester un blob sans roadmap, mais de se structurer.

    @DrHelmut : je n’ai pas vraiment la réponse. Je ne crois pas qu’il y ait de « meilleur » langage polyvalent, mais plutôt que certains langages sont adaptés à certaines problématiques.
    Concernant le fait qu’il soit interprété, l’interprétation n’a lieu qu’une fois. En environnement de production, le résultat de cette interprétation est caché en opcode. J’ai peur de dire des bêtises, mais à mon avis quelqu’un comme Julien Pauli répondrait mieux que moi à cette idée reçue.
    Pour la syntaxe objet, hormis les annotations et éventuellement l’équivalent des génériques en C#, je ne vois pas quels points te chagrinent. Depuis la 5.3, l’OOP est plutôt complet en PHP.

    @Naholyr : d’accord avec toi, mais cette émulation et cette communauté gomment beaucoup de ce que je reproche à PHP.

    @morphine : je suis sincèrement curieux de ce qui te pousse à dire que c’est contre nature en PHP de faire du MVC.
    En ce qui concerne les inclusions de fichier, je pense que le gain en lisibilité et en séparation des préoccupations est bien supérieur à quelque I/O, sachant que ces mêmes I/O peuvent être supprimées très simplement grâce à des cache comme APC (cf : réponse à @DrHelmut).
    L’overhead induit par des frameworks n’est, certes, pas négligeable, mais facilement gommé par d’autres facteurs. Tous les sites lents tournant sous des frameworks comme ZF ou Symfony2 que j’ai rencontré l’étaient à cause d’une mauvaise utilisation de la part des developpeurs des outils proposés par les frameworks (90% du temps à cause du lazy-loading d’un ORM).
    De plus le gain en rapidité de développement, en facilité/flexibilité de recrutement, et le fait de se concentrer sur les bugs de l’appli, et non pas ceux du framework me semblent bien supérieurs à une courbe d’apprentissage abrupte et une sensation (à démontrer) de lenteur.

  14. Clement Herreman, le lundi 3 décembre 2012 à 17:42

    @Erp Derp : au contraire, il faudrait y toucher et la changer. C’est partiellement le cas, mais c’est long vu le volume de la code base, et les répercutions sur un nombre énorme de projets en dépendant. Et surtout c’est un travail communautaire, dépendant des compétences et de la disponibilité des contributeurs.
    Pour moi les frameworks ou les bibliothèques ne sont pas des « surcouches », terme assez péjoratif, mais des outils. Le but d’un langage est différent de celui d’un framework. L’important de choisir les bons outils pour la bonne tache.

  15. Vince, le lundi 3 décembre 2012 à 18:56

    @morphine Je serais curieux de voir un de tes projets de « gros extranet » n’utilisant pas de framework MVC, ça doit être sympa à debugger.
    Je conseille la lecture de cet article qui résume assez bien mon point de vue, même si je continue à développer en PHP (en aimant ça (mais pas tout le temps)):
    http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/

  16. morphine, le mardi 4 décembre 2012 à 10:23

    @Clement Herreman @Vince, pourquoi je pense que MVC est nul en PHP : Tout d’abord je précise que je développe des extranets pour des banques (80% de javascript, 20% de php) et des programmes pro en Objective‑C (sur Mac donc).
    1) aucun designer n’arrive à se dépatouiller avec les systèmes de templates (genre Smarty) ; donc totalement inutile ; bien plus simple de mettre directement du code PHP dans le HTML (PHP étant déjà un système de template !!!).
    2) chaque fois que je reprends un projet en Zend par exemple, je vois de la logique dans la vue et non pas dans le controller ; normale, c’est trop chiant pour changer une date en FR, créer un select à partir d’une base de donnée, etc…
    3) en objective‑c je me retrouve à coder 80% dans le controller. En PHP, je me retrouve à coder même pas 30% dans le controller (car çà me gave de déclarer quinze mille variables à appeler dans la vue). Encore une fois c’est normal : en PHP on génère des pages HTML bordel, donc de la vue !!! Vouloir le séparer dans un controller, juste pour ressembler à des codeurs en C++ est ridicule. Alors oui, certains programmeurs utilisent les helpers qui est un truc bâtard entre le controller et la vue… juste pour faire style « j’ai pas mis de la logique dans ma vue ».
    4) maintenant le M de MVC : Zend ne créé pas les tables automatiquement : on se demande pourquoi les déclarer limite !!! Symfony est plus sympa, et pas besoin de créer les tables à la main une fois déclarés dans le « model ». Mais franchement, j’ai créé une class qui fait tout comme symfony en quelques heures. En objective‑c en effet je me retrouve à coder des modèles qui écrivent dans une base de donnée, d’autres dans des fichiers, d’autres sur le réseau, ok. Sur plus de 150 projets web que j’ai fait, le nombre de fois que j’ai écris ailleurs que dans une base de donnée c’est pinuts, et faire un fwrite() (pour fichier ou réseau !) est pas très compliqué, pas besoin de 15 fichiers de class PHP pour 3 lignes !!!
    5) maintenant @Clement Herreman et les caches pour accélérer ; limite je sourie gentiment ; sur un extranet (à l’opposé d’un site web) on ne peut pas stocker à la main grand chose, car tout est dynamique. Reste ce que le framework stocke pour nous… et c’est pas grand chose non plus (surtout la partie « model » en réalité, qui évite de refaire des descriptions de table à MySQL) ; le gain de rapidité est proche du néant, et encore une fois un get_included_file() te le fait vite comprendre.
    6) rapidité de codage ??? non, là faut tout arrêter et se remettre en question 2 secondes !!! Entre les mises à jour de sécurité, la compréhension pour faire des trucs simples, le temps que les mecs de ton équipe comprennent le principe du framework et respecte le schémas imposé par le framework (et perdent du coup leurs habitudes) tu passes… des années ! Pour faire un hello word, je fais echo « hello word » et çà tout les programmeurs PHP de mon équipe le comprennent. Pour faire pareil avec symfony et compiler, ce n’est pas le même temps… certaines boites se spécialisent avec un framework, ok c’est bien… n’empêche ils se spécialisent aussi à rendre des programmes lents à l’exécution… ou font gagner de l’argent à Dell.
    7) @Vince : débugger un framework maison est très simple car très petits ; encore une fois dans la pratique, c’est strictement le contraire qu’il se passe : débugger un programme sur Zend, que tu ne sais même pas comment il marche derrière, voilà l’angoisse. A sécuriser un site « à la main » n’est pas très difficile une fois que tu as compris que tu dois faire attention aux attaques sql insert, à initialiser tes variables, vérifier les fichiers envoyer par upload, crypter les mots de passe… franchement pas grand chose !!! (oui je sens que je vais me faire allumer sur cette phrase, tant pis, j’assume)
    Désolé d’avoir été long.

  17. Poppy, le mardi 4 décembre 2012 à 11:38

    @morphine tu ne sais tout simplement pas utiliser ZF, pour avoir fait du PHP de puis environs 10 ans et du ZF1 sur un très gros projet (projet international, plusieurs langues, des millions de membres) je confirme qu’il y a un gros pb de perf. comparé a la version procédural, mais niveau maintenabilité il y a pas photo, APC c’est un cache opcode ça veux dire que php cache le code et a juste a l’éxecuté du coup plus de parsing de code qui peu être long sur ce style de framework, pour le MVC tout le monde est tenté de ne pas le respecté. si dans tes views il y a du code logique, c’est pas de la faute a PHP ou ZF mais bien a toi ou ton equipe !

    de plus on choisi son langage en fonction du projet, PHP ne peu pas tout faire.

    personelement sur un gros projet sur le quel je bosse, je doit géré environ 3000 requests/s est cette parti est codé en C++ car Python, Ruby et PHP ne corresponde pas a ce besoin. un bon développeur c’est s’adapté et n’utilise pas que Ruby ou PHP pour tous !

    PHP est un très très bon langage et il est facile de faire de la merde qui « marche », encore une foi c’est le développeur qui n’est pas bon pas le langage !

  18. incomabord, le mardi 4 décembre 2012 à 12:13

    Merci pour l’article. je suis d’accords avec vous PHP a besoin d’un renouveau il est devenu lourd et niveau sécu on trouve beaucoup de sites codés avec les pieds (nombres impressionnantes de faille XSS).

    Beaucoup de dev ont préférés se tournes vers le ruby, perl.…

    Au plaisir de vous lire.

  19. morphine, le mardi 4 décembre 2012 à 13:02

    @poppy, pour appeler apc_compile_file() je n’ai pas besoin de Zend moi, je te remercie ;-) Le gain sur un de mes gros projets programmé à la main est à la limite du négligeable… c’est pas convertir en opcode qui est lent, c’est les framework qui ont des milliers de class et fonctions pour pas grand chose.
    Je suis également d’accord avec toi que si de la logique dans les vues ce n’est pas la faute de Zend ou PHP mais la mienne… mais tu as raté une idée que je voulais faire passer : quand on fait un projet web, on créé à 95% du code HTML (ou json pour ma part)… pourquoi foutre de la logique qui créé de la vue dans un controller ??? pourquoi ??? j’arrive pas à répondre à cette question. Moi je le place direct dans la vue ; çà c’est logique.
    Et je suis toujours d’accord avec toi, quand tu dis qu’il faut utiliser le bon language au bon moment. Pour ma part c’est NodeJs quand je veux faire du push (1 projet jusqu’à présent). En C, ok, mais je suppose que tu es partie de quelque chose pour au moins renvoyer le contenu statique, les sessions, gérer les multi-connexions… bref refaire un petit Apache. (à moins que tu as fait du PHP qui appel un C)

    Et tant que j’y suis je donne mon avis sur les languages web :
    – Python=aucun avantage par rapport à PHP,
    – Perl=aucun avantage par rapport à PHP (et pourtant j’ai commencé à faire tous mes sites en Perl il y a bien longtemps),
    – Java=lent d’exécution / long à programmer (j’aime Java aussi, mais pour m’amuser à programmer Android),
    – Ruby=aucun avantage par rapport à PHP (voir lent aussi),
    – framework Ruby on rail=j’aime bien, mais jamais franchi le pas pour un client et puis je ne vois pas l’avantage par rapport à PHP à nouveau,
    – NodeJS=beaucoup d’avantages par rapport à PHP !!! Le meilleur est justement une grande rapidité et le peu de ressources serveur comparé à Apache/PHP (quelques Ko pour une requete HTTP contre plusieurs Mo pour Apache) mais trop nouveau à mon avis,
    – ASP (.NET)=trop lourd/marche sur serveur windows donc cher et compliqué/lent,
    Je passe les Erlang et consort (ou Brainfuck et consort), et j’en conclu quoi ? Que PHP est le language qui répond à presque tous les projets. Donc moi, perso, je continue en PHP et je laisse les jeunes se planter en essayant leurs nouvelles techno et se faire plaisir au détriment du client.

  20. Poppy, le mardi 4 décembre 2012 à 14:41

    @morphine pour APC pas besoin d’appelé une fonction c’est automatique pour l’opcode, je suis ok avec toi sur le fait que un projet avec un framework maison est surement plus rapide que ZF et SF, enfin pas dans tous les cas.

    pour l’histoire du C++ non je ne recode pas Apache lol mais j’utilise un serveur nginx avec des modules maison qui sert d’application directement compiler dans le core d’nginx ça evite de passé par cgi/fcgi, etc…

  21. Olivier, le mercredi 5 décembre 2012 à 14:34

    « namespaces, fonctions anonymes (appelée closures en PHP), traits (semblables aux mixins en Ruby) »
    Je fais beaucoup de Ruby et il n’est pas correct d’écrire que les closures PHP sont l’équivalent de celle en Ruby. Une notion essentielle et mise de côté qui est le changement de contexte d’évaluation. Ce qui a amené les développeurs de PHP à ajouter un ”use” supplémentaire (qui pour moi en terme de design du language est une horreur sans nom, pour cela se référrer au théorie sur les languages dynamiques), mais celui-ci n’est pas suffisant.
    A ce niveau, l’élégance de Ruby est bien au dessus de celle de PHP.
    D’autre part, PHP est toujours en retard de quelques années et se contente de tenter de copier en permanence les bonnes idées venant d’ailleurs (ie : RoR et les languages dynamiques, il suffit de voir le profil qu’avait Symfony avant RoR 2004 et après). Et n’est jamais un moteur l’écosystème du web.
    Le principal problème ici en France est que nous avons une informatique de sociétés de services, encadrée, pilotée et emprisonnée par de grosses SSII qui empêchent toutes nouvelles technologies d’apparaître. Ce qui explique le peu d’utilisation de RoR (ou autres technologies) en France. On peu résumer par : Ici, c’est : PHP ou Java voir .NET. Contrairement à l’Amérique du nord/sud ou la compétition inter-technologies et la course à la solution efficace et de rigueur.
    Enfin, lorsqu’on a une réelle connaissance théorique des languages et de leurs spécificités, il ne faut pas longtemps pour se rendre compte que PHP fait tout de travers …
    PS : Ne pas confondre ce que l’on peut faire avec un language et le language lui-même. On peut avoir un language d’une élégance exécrable, sans âme et vide de concept tout en pouvant réaliser beaucoup de chose avec ce language.
    La preuve ? : PHP.

  22. Clement Herreman, le mercredi 5 décembre 2012 à 17:47

    @Olivier : exact, et c’est pour ça que je n’ai pas écrit que les closures PHP ressemblent au fonctions anonymes de Ruby, ou encore de JS. Le scope est en effet différent, principalement à cause de barrières techniques sur la portée et le shadowing.

    Je confirme que PHP n’est pas forcément « moteur », comme Erlang ou les nouveaux standard ECMA, ou ce que Ruby et RoR ont apportés, mais ce que je veux souligner c’est que PHP bouge et arrive à intégrer toute ces bonnes choses en un langage polyvalent, restant très accessible et permettant l’éclosion de nouveaux projets et de communauté très actives. La contrepartie est le WTF latent sur certains points, le laxisme du langage permettant de faire n’importe quoi, et les tellement mauvaises ressources et conseils.

  23. Flavien Metivier, le jeudi 6 décembre 2012 à 12:45

    Plutôt marrant toutes ces gueguerres de clochers, apprenez et utilisez plusieurs langages en fonctions de vos besoins et des projets.
    Tout les langages ont des lacunes. Mais la plupart du temps les problèmes ne viennent pas du langages mais de la médiocrité des développeurs.
    Le modèle MVC vous semble trop pauvre ? étendez le ! ou apprenez déjà à l’utiliser correctement…

    Bref peu importe le langage, il y aura toujours des aigris pour critiquer mais rarement pour mettre les mains dans le cambouis et essayer d’améliorer les choses…

  24. Olivier, le jeudi 6 décembre 2012 à 14:00

    @Flavien : J’ai commencé ma carrière en 1994, tu souhaites peut-être la liste de tous les languages que j’ai pratiqués industriellement ? Pas ceux, qu’on mets sur un CV parce qu’on a eu 3 heures de cours pour les partiels de licence, hein …

    « apprenez et utilisez plusieurs langages » – Merci pour le conseil constructif qui laisse paraître qu’on s’exprime sans rien connaître.

    Cela dit, ne pas reconnaître que parmi le vaste choix de languages certains sont plus élégants, plus intègres, mieux construit et plus efficace que d’autres, c’est la politique de l’autruche voire de l’ignorant.

    D’autre part, un language évolue grace aux critiques et aux souhaits exposés par les utilisateurs, sans cette dynamique, cela reste un langue mort non utilisé comme il en existe des dizaines, voire des centaines …
    En finalité, pour tout dire, je ne fais pas de « gueguerres », contre qui ? contre quoi ? Quel serait mon intérêt ?
    J’expose mon expérience et je l’étaye d’arguments.

    Désolé, mais pour qui a une bonne connaissance des théories des languages, PHP est une blague. Il faut tout de même ouvrir les yeux et voir historiquement comment il a été construit, avec toutes les erreurs de conceptions énormes ! Par exemple, la réaffectation de $this pour PHP < 5, l’histoire du late state binding, tout cela montre une très mauvaise connaissance de la théorie des languages objects de la part des concepteurs. (surtout que ce sujet du late state binding est exposé depuis très longtemps dans la littérature de l’approche SmallTalk, C++ et autres, il suffisait d’un peu de culture pour ne pas faire l’erreur) … Bref … Dire la vérité ou ce que l’on recent n’a jamais été, à mon sens, négatif.

    Toujours pareil, il ne faut pas confondre le language et ce que l’on peut faire.

    Pour ma part, quand je dois bosser en Ruby, c’est une explosion de joie tant c’est plaisant d’utiliser un language élégant efficace, c’est un réel plaisir. A contrario quand je dois faire du PHP, j’ai peu de plaisir et beaucoup de lassitude.

    « Tous les langages ont des lacunes » – Très intéressant comme affirmation brute de décoffrage et passe partout, peux-tu argumenter ?
    Que reproches tu conceptuellement à Lisp, Smalltalk, Python, Ruby et Erlang ?

  25. Olivier, le jeudi 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.

  26. Flavien Metivier, le jeudi 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.

  27. Olivier, le jeudi 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.

  28. Flavien Metivier, le jeudi 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.

  29. tzi, le jeudi 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 !

  30. Olivier, le jeudi 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é ?

  31. tzi, le jeudi 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é ;)

  32. Olivier, le vendredi 7 décembre 2012 à 03: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.

  33. Phollow, le samedi 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.

  34. Fabien, le dimanche 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

  35. Olivier, le jeudi 13 décembre 2012 à 03: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.

  36. Fabien, le lundi 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 ;)

  37. Olivier, le mardi 18 décembre 2012 à 02: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.

  38. Olivier, le mardi 18 décembre 2012 à 02: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.

  39. Olivier, le mardi 18 décembre 2012 à 02: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 …

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

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

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

    Cela reste mon opinion et cela n’engage que moi … ;-)

  42. Fdutey, le jeudi 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.….

  43. mickaelandrieu, le dimanche 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).

  44. Nicolas, le samedi 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).

  45. Lumin0u, le dimanche 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.

  46. bruno vibert, le mardi 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 23 !

    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.…

  47. Nicolas, le mardi 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).

  48. Fabien, le samedi 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).