Zerosquare (./16287) :
Le problème, c'est que le monsieur c'est pas un mec qui bricole un site web dans son coin pour présenter sa collection de coquillages, mais le créateur d'un langage de programmation largement utilisé...
le créateur des 2 à 3 premières versions d'un langage de programmation, qui a été largement utilisé ; et qui ne l'est pour ainsi dire plus, si tu te limites aux versions du langages pour lesquelles il n'y avait pas grand monde de plus que Rasmus.
Depuis PHP 3, il y a eu pas mal de changements, quand même ; ne serait-ce qu'avec l'arrivée du Zend Engine avec PHP 4 ; et sa seconde version avec PHP 5.
Tu prends PHP 5.4
(dernière version stable ; ou même PHP 5.3, la version précédente, encore maintenue), c'est plus tout à fait la même chose que le PHP-FI que Rasmus avait créé à l'époque.
J'ajouterais que ce n'est pas parce que Rasmus a créé "personnal home page" à l'époque que tous ceux qui font du PHP
(voire même qui "font PHP") sont nécessairement d'accord avec l'ensemble de ses idées, que ce soit sur le langage, son usage, les frameworks, ... j'aurais même tendance à dire que, petit à petit, le processus de développement du langage en lui-même
(disons du core, de la syntaxe de PHP, et des extensions fournies par défaut) se "démocratise" doucement, laissant peu à peu leur chances à des évolutions qui n'auraient pas été envisageables à l'époque pas si lointaine où deux-trois personnes étaient à même de dire "oui" ou "non" et "c'est comme ça".
Zerosquare (./16291) :
robinHood (./16290) :
ca fait 10 ans que j'en fait je n'ai jamais eu de mauvaises surprises 
Toi peut-être, mais tes clients ? 
Les clients ont la bonne surprise de trouver "relativement facilement" des gars qui sont capable de maintenir leur site / leur application en PHP ; que ce soit parce que c'est basé sur un langage pour lequel il y a pas mal de développeurs
(j'ai pas dit que tous étaient bons... c'est un des problèmes de PHP, aussi, son apparente facilité d'accès) ou parce que c'est basé sur des logiciels open-source fortement répandus avec une communauté forte derrière
(ça aussi, ça peut être un problème, avec de la résistance aux changements, du "ça marche donc on fait pas évoluer" et autres).
robinHood (./16292) :
même si libreOffice est un firewall il n'est pourtant pas écrit en php 
oué, enfin, PHP, à la base, c'est quand même un langage "pour le web"
(en soit, le langage pas forcément, mais les extensions fournies par défaut, de même que la plupart des extensions, en fait, c'est pour le web) ; prendre PHP pour développer une suite bureautique... heu... voila quoi
Le langage PHP en soit le permettrait, il y a même des extensions pour faire de l'interface graphique en GTK ; mais autant partir sur un langage / une techno pour laquelle il y a un peu plus d'outils et de support ^^
flanker (./16293) :
Sauf que PHP est censé être orienté objet, maintenant 
Sauf que PHP permet de développer en orienté objet, comme en procédural ; comme en "sql dans le code html" ou en "36 couches frameworkisées MVC ORM REST buzzwords blah blah"
robinHood (./16294) :
php est souple car en 2 secondes tu fait un script de traitement de données vers autre chose etc ... l'api est vraiment bonne quant tu la connais un minimum
j'ai des souvenirs d'une époque où je faisais pas mal de manipulation de données textuelles ; et je disais ça de Perl
(qui est un langage fait pour ça, manipuler du texte, le transformer, et recracher la sortie).
Même maintenant, quand j'ai besoin de petits scripts de traitement de données
(genre prendre une paire de fichiers texte en entrée, générer un fichier texte combiné en sortie), il m'arrive encore de me dire "ça irait tellement mieux en Perl" -- ne serait-ce que pour la syntaxe...
Nil (./16295) :
(ça fait assez peur, parfois, de voir certaines API d'interfaces avec des librairies extérieures dont la documentation est inexistante)
C'est assez peu fréquent sur les extensions fournies par PHP même ; par contre, rien n’empêche n'importe quel développeur de sortir une extension sans la documenter... là encore, pas la faute du langage, mais du développeur.
Encore que dans le cas des extensions faisant office d'interface avec une lib externe, elles reproduisent souvent au plus proche l'interface de la lib en question, ce qui facilite un peu les choses -- et explique en partie les jolies incohérences de l'API, du genre camelcase vs underscores, du genre paramètres pas dans le même ordre, ...
