Ce qui ne va pas dans PHP5
Mercredi 4 novembre 2009, par //
un peu de technique
Version imprimable
En ce moment la demande est beaucoup sur PHP5 notamment parce que l’on développe plus vite qu’en java, et qu’en plus les développeurs sont moins chers.
Pourtant parfois PHP peut comme beaucoup d’outil devenir le problème. Faisons un rapide tour d’horizon de ce qui peut mal tourner.
Espace de nommage de base prolixe et confus
+ de 3000 fonctions d’espace de nommage de base (contre quelques centaines pour ruby ou python ou perl), et un humain travail au mieux avec 300 mots. Ce qui est vrai en langage courant, et aussi vrai en informatique...
et l’on trouve dans le corps de PHP5 des fonctions comme
mysql-real-escape-string ;
mysql-escape-string.php ;
... dont on a du mal à voir l’intérêt.
Les fonctions contiennent parfois des "_" parfois pas, parfois commencent par get, ou se termine par get .... (isset vs is_object par exemple) ,
Et enfin, au lieu d’avoir une fonction de recherche de regexp/split, ou en a une douzaine en fonction de paramètres tel que l’insensibilité à la casse, la gestion d’UTF8...
Pourquoi avoir 10 fonctions là où les autres langages en ont une, avec des syntaxes incohérentes ?
lire ici pour une version plus détaillée
PHP est imprédictible quand on utilise UTF8
L’esprit PHP est d’offrir des bindings sur moults librairies C avec de bonnes performances. PHP ne fait pas dans la dentelle, il y a un espace mémoire avec ce qui est supposé être une chaîne de caractère, et c’est passé au fonctions.
PHP contrairement aux autres langages modernes ne travaille pas avec une représentation interne des chaînes de caractère en unicode 16. Ce que l’on a en mémoire est ce que la précédente fonction à bien voulu rentrer, ou ce qui est donné par le serveur de page web en fonction des réglages systèmes ou autres. Bref, la chaîne est présente en mémoire avec des représentations potentiellement non homogène.
Pour un langage web où l’on travaille avec les chaînes de caractères, qui sont nos interfaces, l’insécurité sur les chaînes de caractères est un problème majeur : on contrôle peu ou mal nos entrées, ce qui est la porte ouverte à tous les trous de sécurité.
Liste des fonctions non sûres avec UTF8
Symfony la solution ?
Je suis perplexe sur symfony. C’est une copie fonctionnelle du framework MVC Ruby’On Rails avec des morceaux d’emprunt à java (propel ressemble à hibernate et le framework a une syntaxe à la java). Je ne pense que du bien de ces technologies a priori.
Prenons doctrine (l’ORM montant) et regardons leur documentation. Ça semble bien.
Et, on voit paraître le prepare execute (requête SQL préparée) avec les arguments optionnels qui protègent contre pas mal d’injections SQL.
Malheureusement on voit aussi qu’il tient qu’au développeur de passer au requêtes préparées des arguments de leur jus comme :
$injectionable ="u.secure LIKE = \'%$arg%\'"
$q = Doctrine_Query::create()
->from('User u')
->where($injectionable);Par expérience par ce que cela est faisable, certains malheureusement le feront.
De plus, symfony est hyper verbeux :
sfContext::getInstance()->getRequest()->getScriptName());s’écrit en PHP normal
$_SERVER['SCRIPT_FILENAME']Et c’est là où l’on touche au défaut de symfony : symfony ne s’appuie pas sur le PHP, il impose une nouvelle syntaxe. De fait symfony c’est du PHP5 qui mime java dans son hyperverbosité, ce qui fait justement perdre tous les intérêts de PHP5. Symfony c’est une centaine de nouvelles classes, et une dizaines de nouveaux attributs méthodes par classe. Une espace de nommage contenant 4000 mots c’est du délire ! Aucun humain ne peut possiblement tous les connaitre et voir comment bien les utiliser.
Pourquoi code-t’on plus vite en php qu’en java ?
Pour cela il faut s’intéresser aux données COCOMO II (COnstructive COst MOdel) : le java est plus verbeux que le PHP d’un facteur 2. Or la productivité des développeurs est indépendante d’un langage, donc à compétence égale un développement coûter deux fois moins en PHP.
Sauf si le framework est hyper verbeux. Or une instruction (COCOMO) n’est pas une ligne de code, et dans l’exemple ci dessus, chaque call () est une opération. Donc, dans ce cas là symfony est 4 fois plus verbeux que PHP.
Autrement dit, symfony a les défauts de PHP (typage faible et chaîne de caractères explosives) et ceux de java (hyper verbosité).
Symfony est pour moi l’exemple type de professionalisation du libre : une application qui donne l’air sérieuse car elle ressemble à ce que l’on attend d’une application sérieuse, mais elle n’est pas sérieuse.
On se retrouve avec l’apparence de la qualité. Pourtant ce n’est pas en mettant une blouse blanche à un singe cela le transforme en génial savant.
La communauté PHP
Le PHP est un langage que j’aime bien pour le développement rapide web. Plus simple à déployer que d’autres il a beaucoup d’intérêt pour faire un prototype, et il peut parfois même tenir la charge. J’y reste attaché malgré ses défauts.
Cependant, ce qui fait la puissance d’un langage c’est le codeur derrière. Un langage puissant permet autant de faire des prouesses que des horreurs. PHP, ruby et Perl sont dans cette famille de langage.
Entre vieux dinosaures nos pires cauchemars sont rarement liés à PHP, mais souvent à l’idée géniale qu’on encore trouvé les nouveaux développeurs.
Un site contient un système de limitation des visites par date s’appuie sur le champs date de postgresql (qui contient aussi le temps), on demande de rajouter une limitation sur l’heure, et voilà qu’apparait dans symfony un nouvel objet qui au final consiste à stocker l’heure dans une chaine de caractère et à comparer cette chaine à l’heure système. à chaque chargement page, qui s’ajoute à l’exécution de la précédente limitation.
Diantre, que de contorsion pour faire quelque chose qui existait déjà.
Je ne compte plus les fois où la solution couramment utilisée dans le métier est discréditée parce que « trop compliquée ». Avoir un site en plusieurs langue : on utilise gettext ? Que nenni, on duplique le site autant de fois qu’il y a de langues.
Gérer la date : utilise-t’on l’une des 3000 les fonction PHP qui est correcte ? Non on recode sa fonction à base de parcours de chaîne de caractères ....
Si un défaut existe dans PHP c’est la méconnaissance d’une certaine culture informatique et la réinvention permanente. Pour preuve PHP ne dispose pas même avec PEAR de l’équivalent d’un Pypi ou d’un CPAN ou d’un GEM.
Conclusion
Un langage a parfois des défauts, il a aussi des qualités. Je crois que les défauts de PHP sont surtout les développeurs ; les codeurs expérimentés qui encore il y a 5 ans étaient sur PHP ont presque tous migré pour perl, python ruby. D’une part parce que ces langages étaient un progrès, d’autre part aussi parce que l’arrivée de nouveaux entrants attirés par la promesse d’un emploi facile plus que par le plaisir du travail bien fait ont transformé le travail en environnement PHP en roulette russe : sur le papier tout le monde met en oeuvre les meilleures techniques possibles, par contre dans le code on trouve des erreurs que l’on croyait disparues depuis 10 ans.
Depuis 1968, il est prouvé, reprouvé et rabattu que le développement est marginalement une question d’outils. Les vrais gains se font avec le cerveau.
C’est pour ça que mieux que symfony je peux vous donner une recette appelée le Tao de python qui marche bien aussi en PHP :
1. Beautiful is better than ugly.2. Explicit is better than implicit.3. Simple is better than complex.4. Complex is better than complicated.5. Flat is better than nested.6. Sparse is better than dense.7. Readability counts.8. Special cases aren’t special enough to break the rules.9. Although practicality beats purity.10. Errors should never pass silently.11. Unless explicitly silenced.12. In the face of ambiguity, refuse the temptation to guess.13. There should be one— and preferably only one —obvious way to do it.14. Although that way may not be obvious at first unless you’re Dutch.15. Now is better than never.16. Although never is often better than *right* now.17. If the implementation is hard to explain, it’s a bad idea.18. If the implementation is easy to explain, it may be a good idea.19. Namespaces are one honking great idea — let’s do more of those !
