-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 17/09/2011 14:30, kaliderus a écrit :
>> Je n'ai jamais compris l'engouement vers PHP, qui est un mauvais langage.
> -> Par curiosité, peux-tu développer ce point stp ?
PHP est mauvais, et à plusieurs titres.
Déjà, à la différence d'autres langages, il est intrinsèquement mauvais,
c'est-à-dire que dès le cœur de PHP, les mauvaises décisions ont été prises.
Au pifomètre, on peut citer des API extrèmement mouvantes
(ajout/suppression de méthodes entre 3 versions consécutives de PHP), un
manque total de convention de programmation (strlen mais str_split), des
fonctionnalités hérétiques (magic_quote_gpc…), l'intégration de
fonctionnalités qui auraient plus sa place dans des libs externes que
dans le core (compression, traitement des cartes de crédit,
authentification Kerberos, tag IDv3…), ou encore le moteur non
thread-safe qui emmerde totalement le monde pour du déploiement.
Tout à été fait pour faire tout, n'importe quoi, n'importe comment et
par n'importe qui.
De l'autre côté, côté développeur, PHP est vendu la plupart du temps
comme le langage à la portée de n'importe qui, y compris du
non-professionnel.
C'est comme pour le domaine de la vente d'ordinateur, on a vendu du rève
en vendant comme quelque chose de simple une chose qui est en réalité
extrèmement complexe.
Étant donné que le core lui-même n'incite pas aux bonnes pratiques, la
plupart des utilisateurs de PHP (je n'ose trop dire développeurs) ont
fait n'importe quoi, ne filtrent pas leurs données avant l'envoi en
base, mélange très fortement PHP et HTML, n'architecture pas leurs
applications…
Et ceci d'autant plus que les paradigmes de PHP comme la programmation
objet sont développés avec les pieds. Je ne sais pas si tu as déjà
tenter de faire de la POO avec PHP, mais on s'y sent rapidement très
frustré tellement on est loin des possibilités de n'importe quel autre
langage orienté objet (héritage buggé, méthodes statiques buggées,
absence de polymorphisme…).
On retrouve au final des applications la plupart du temps totalement
non-sécuritaire (injection SQL, XSS…), bugguées, indémerdables, non
évolutives… Il y a rarement de véritable v2 pour une application en PHP,
tout au plus une v1-bis où on a tout foutu à la benne pour refaire avec
le nouveau cahier des charges.
Après, PHP souffre aussi de gros problèmes par son fonctionnement même.
Il est stateless dans son fonctionnement au sens où chaque appel relance
une réinterprétation intégrale de ton application.
À l'inverse en JEE par exemple, ta conf et ta connexion à ta base de
données est montée une fois pour toute au démarrage de ton serveur
d'application, ce qui permet de mettre facilement et proprement en place
des systèmes de pool, de cache ou de mutualisation des ressources entre
chaque client. Pas besoin par exemple de reloader 30 millions de fois ta
configuration par mois, ça sera le même objet qui transitera pour toutes
tes requètes.
Cela est très handicapant pour PHP, car du coup cela implique de faire «
light » en terme de performance. Impossible par exemple d'utiliser un
ORM type Hibernate, qui prendrait des plombes à se charger à chaque
appel. On pare au plus vite, au plus pressé, quitte à foutre des
requêtes SQL redondées dans tous les fichiers du projet.
Idem au niveau de l'interprétation, c'est au développeur de gérer le
cycle des dépendances, à gros coup d'include dans tous les sens, souvent
en dépit du bon sens, avec des tricks à la con (le tristement célèbre «
require_once('views/'.$_GET['view'].'.php') »)…
Tout ça parce qu'une méthode « propre » serait inabordable pour tout non
professionnel du développement, rendrait le système lent au possible
(stateless quand tu nous tiens…).
Donc voilà, je vais m'arréter là, sinon je pourrais encore y passer ma
journée =)
Si certains sont intéressés sur le sujet (d'accord ou non avec moi =)),
qu'ils n'hésitent pas à me contacter, c'est aussi un sujet qui me
passionne et dont je serais ravi de discuter, en particulier si
quelqu'un a une solution pour éviter de basculer dans le « bordel PHP »
tout en faisant du PHP (qui est quand même une solution qui serait
intéressant (si elle n'avait pas autant d'inconvénients) de par sa
simplicité de déploiement (à l'inverse de Java, Python, RoR ou autre).
- --
Aeris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJOdJwWAAoJEK8zQvxDY4P9hQUH/Agbnmzef+9OwtQ95wJCdl60
S1YnU/rSU42Z6o40nh08BNfEZ0OFvUR9Eu+RU16EEaYd3ysC1KjgAb1s1Lw6f/3U
jwdT9tSpo/Odi0hGQJuNCQjUYm4VY1CyPhZsdYa9szskEsDCV/qqJCdqGtZLLGia
YSRgkzdejsBNqNxUtk9lVZvLhCUjpD5Z6d88JqxWaeoydP26GThVvPMqbW9+2i4f
2ZOjlXmPU/eFVMF1mHkM2PPRX81D9ncBXFknz3gGnyto3qAnlQX3I28K+OLAlRB0
fWl4I07j6VC1/USCeW9wIBGily/ft2yqhh2I7+V3EEdMqnQMV7Bb83GfGrH+WkA=
=O4/o
-----END PGP SIGNATURE-----
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/4e749c20$0$1428$426a7...@news.free.fr
