avantages et inconvenient de PHP?

Mihamina Rakotomandimby a écrit :

Bonjour,

Salut R12Y

PHP fait partie des langages que j'utilise souvent.
Mais je n'ai pas encore ma petite idée de ses avantages et inconvénients.
Pour le moment, les petites choses que je fais avec (et qui de toutes
façons sont faisable dans presque n'importe quel langage) ne me
permettent pas d'en connaitre ses limites ou ses grandeurs.

Peut-être auriez-vous des liens qui en parlent dans vos bookmarks? Si
vous pouviez les communiquer pour qu'on en discute...

Rapidement, et de mon point de vue personnel à moi qui est probablement
très biaisé (en d'autres termes : si vous avez un fort attachement
affectif à PHP, ne lisez surtout pas ce post, ou alors à vos risques et
périls - voilà, vous êtes prévenus).

Les deux avantages de PHP sont
- que c'est disponible sur la grande majorité des hébergement grand public
- que ça permet à n'importe quel bricoleur d'ajouter rapidement quelques
bricoles dynamiques dans un site statique.

Quant aux inconvénients, heu, comment dire... bon, en vrac:

Déjà, ne cherche pas la moindre cohérence dans le langage, il n'y en a
pas - il n'y a jamais eu le moindre travail de conception du langage, la
syntaxe est bricolée au petit bonheur, il n'y a aucune convention de
nommage dans les fonctions de la bibliothèque standard, ni dans l'ordre
des arguments, bref même après 6 ans d'utilisation quasi-quotidienne, je
suis toujours obligé d'aller chercher dans la doc même pour les
fonctions de bases (manipulations de chaines et de tableaux entre autres).

Je ne m'étendrai pas sur le laxisme du langage en matière de typage et
de gestion des variables non déclarées (et pourtant, j'ai une expérience
certaine des langages dynamiques), ni sur l'absence totale de gestion
des espaces de nommage.

Il y a aussi le modèle d'exécution, qui fait qu'il faut reconstruire le
monde entier à chaque requête. Ce qui n'est pas un problème (et c'est
même plutôt adapté) tant qu'on reste à très bas niveau et sur des choses
simple, mais ça n'aide pas vraiment quand on souhaite factoriser /
abstraire son code, ce qui est une nécessité sur n'importe quelle appli
non-triviale (du moins si on espère pouvoir gérer la maintenance et les
évolutions...).

Enfin, les deux avantages cités plus haut ont pour corrolaire que le
niveau moyen du code PHP disponible sur le web (et donc servant
d'exemple aux débutants...) est au mieux médiocre. Sans vouloir être
méchant, sur toutes les applis PHP sur lesquelles j'ai eu à intervenir
jusqu'ici, il n'en y a pas *une* qui ne soit truffée de WTF majeurs et
d'erreurs de grand débutant (nb : lire la suite avant de réagir sur ce
point, merci).

<troll>En bref, PHP, c'est le nouveau basic. </troll>

Bon, ceci étant dit, en matière de développement web, j'aime encore
mieux PHP que Java (même si la tendance semble être de plus en plus
d'essayer de faire du Java en PHP - no comment...).

Et non, pas la peine de me le dire, je le sais : un bon développeur
arrivera à faire quelque chose de raisonnablement propre avec n'importe
quel langage, un mauvais fera de la merde de toutes façons.

Pour être honnête, et à mon grand regret, un des effets secondaires de
la popularité croissante de Python, et particulièrement de Django, est
qu'on commence à voir le même problème dans un langage / environnement
où le niveau moyen était jusque là plutôt correct. Bref, ce n'est pas
dans l'absolu un problème intrinsèque au langage lui-même (même si on ne
peut pas dire que PHP encourage spécialement les bonnes pratiques), mais
un corrolaire de sa popularité.

Bon, voilà, j'ai mon gilet pare-balles ignifugé, j'attend le retour de
flammes !-)

Mihamina Rakotomandimby a écrit :

PHP fait partie des langages que j'utilise souvent.
Mais je n'ai pas encore ma petite idée de ses avantages et inconvénients.

Bonjour,

Vaste sujet ! Pour ma part, j'ai toujours été déçu par les comparatifs.
Je pense que la réponse ne peut être trouvée que par soi-même, car cela
dépend beaucoup trop du cadre dans lequel on va utiliser le langage.

Bien sûr, PHP s'utilisera surtout dans le cadre de la programmation Web.
Mais entre un petit site Web avec 2 ou 3 pages dynamiques (voire une
seule, comme le formulaire de contact) et une grosse application Web
frontale avec un back-office, c'est le jour et la nuit.

Ces contraintes se retrouveront d'ailleurs dans le style de
programmation : du fonctionnel mêlé au Html pour les cas simples,
jusqu'au framework objet complètement séparé du contenu visuel, genre
MVC, pour les cas plus complexes.

Eventuellement, on pourrait citer comme qualité générale la souplesse de
PHP, permettant de traiter ces cas extrêmes avec le même type de
technologie. Mais pour d'autres développeurs, ce manque de
spécialisation apparaîtra comme un défaut majeur.

On en revient donc à l'expérience personnelle, seule garante d'une
réponse vraiment critique à la question.
Vous pourrez quand-même trouver quelques témoignages intéressants sur le
Web, comme à cet endroit "http://www.journaldunet.com/developpeur/php",
ou là (in english, sorry !)
"http://blogs.techrepublic.com.com/programming-and-development/index.php?cat9"
et, bien sûr, en cherchant dans l'historique de ce newsgroup où nous sommes.

Bonne chance,
Pascal

Bruno Desthuilliers wrote:

Mihamina Rakotomandimby a écrit :

Bonjour,

Salut R12Y

PHP fait partie des langages que j'utilise souvent.
Mais je n'ai pas encore ma petite idée de ses avantages et inconvénients.

...........
Bon, voilà, j'ai mon gilet pare-balles ignifugé, j'attend le retour de
flammes !-)

Ton gilet pare-balles ne devrait pas etre utile.
si quelqu'un défend inconditionnellement le PHP, oubliant tous ces
défauts, le plus probable c'est qu'il ne connaît que ce langage et n'a
jamais jeté un oeuil sur les autres solutions.


je fais d'ailleurs parti des programmeurs grand partisan des framework
"a la Struts" qui ont vu le jour depuis PHP5 (symfony pour ne pas le
citer, que j'utilise tous les jours dans mon stage).

Je pense que ce que j'aime aussi dans ce langage, bien que cela soit
aussi sa faiblesse) c'est que c'est parti de pas grand chose.

Chaque version a apporte un vrai lot de nouveautés et on est toujours
agréablement surpris (bon ok, PHP6 se limite a nous donner l'unicode, et
a devenir un peu plus strict sur certaines saletes des versions
précédentes: bye bye register globals, mais c'est un pas de plus vers un
vrai langage bien rigoureux)

Apres c'est vrai que comme dans tous les langages "grand public" on voit
tres souvent des choses effarantes qui sont écrites et publiées un peu
partout sur le net...

Mais apres tout, c'est plutôt une bonne chose, ca nous montre que ca
marche vraiment bien, et ca met la possibilité de publier du contenu a
la portee de presque tout le monde, ce qui est quand même le principe du
web.
Si on demande a un débutant en programmation de faire quelque chose de
simple en Ruby On Rails (syntaxe tres moche a mon goût) ou avec les
solutions J2E (comprendre le fonctionnement de la POO, faire marcher
Tomcat, coder sous Eclipse, et trouver un hebergeur compatible), il a
peu de chances de s'en sortir, PHP permet de tout faire en 2 secondes!


En plus, bien qu'on trouve de tout sur le net, la doc de php.net est
impeccable.

Je pense que d'ici qques annees php deviendra beaucoup plus rigoureux
sur le typage des variables (ca commence deja d'ailleurs, mais pas
encore sur les types natifs).

et pour ce qui est d'utiliser des variables non declares ou des index
non définis dans une map, c'est deja regle depuis 1 moment.

longue vie donc au PHP :p

Ce qui m'inquiete plus c'est ses défauts de base, difficiles a changer
maintenant.

Genre en effet, a chaque requete on repart de zero, tout les fichiers
sont re-pars'es, la config de l'appli qui tourne recharg'ee etc
Bon il y a des histoires pour faire du byte code avec le php je crois?
ou au moin des systeme de cache, mais c'est une fausse solution pour
recuperer d'un cote ce qu'on pert de l'autre.

Pis bon PHP c'est pas fait pour supporter des charges enormes non plus
(jme suis toujours demand'e comment ils font chez facebook d'ailleur
pour que ca tienne leur truc)

Bruno Desthuilliers a écrit :

<troll>En bref, PHP, c'est le nouveau basic. </troll>

Là je vais demander des droits ;-)

A mon avis ce qu'il manque leplus et de loin, c'est un style de
programmation recommandé.
Sur certains morceaux de code pfff on croirait du perl donc ça a beau
être en GPL de là à vouloir y mettre les pattes.

actuellement on a la syntaxe alternative et la syntaxe complexe des
chaînes qui sont sous exploitées et permettrait je pense une écriture
plus propre

Sur le langage je me contenterai de dire que je préfère et de loin
python et javascript.

Eloims a écrit :

Apres c'est vrai que comme dans tous les langages "grand public" on voit
tres souvent des choses effarantes qui sont écrites et publiées un peu
partout sur le net...

savoir que certains peuvent commettre çi ou ça avec tel langage
n'apprend pas grd chse sur ce langage - ce n'est pas un inconvénient
*de* PHP si certains codent comme des anes.

ca met la possibilité de publier du contenu a la portee de presque
tout le monde

c'est en effet une caractéristique plus significative.

comparé à des J2E, WebObjects, ou autre dotnetteries MS, PHP a
l'énorme avantage de permettre gratuitement avec n'importe quel
serveur libre d'implémenter ce qui requiert moultes dépenses ailleurs.

Genre en effet, a chaque requete on repart de zero, tout les fichiers
sont re-pars'es, la config de l'appli qui tourne recharg'ee etc

choix du langage, pas défauts du langage.

on parle ici de pages ouèbes générées par un serveur http, le module
PHP devrait-il garder un contexte (d'un des N visiteurs) en mémoire
alors que rien ne permet de savoir si la prochaine page (requête)
sera faite dans 2 sec. ou 2 heures ?
doit-on cacher ce contexte alors que le serveur apache d'une part et
l'OS d'autre part participent déjà à la gestion de mise en cache des
fichiers souvent lus ?

Bon il y a des histoires pour faire du byte code avec le php je crois?
ou au moin des systeme de cache, mais c'est une fausse solution pour
recuperer d'un cote ce qu'on pert de l'autre.

hmm, non, une compilation des définitions de classes PHP serait en
effet un truc significatif pour améliorer le traitement des scripts,
bcp plus que le cache des instances de ces classes.

Sylvain.

Le 28 Sep 2008 22:34:46 GMT, Sylvain SF <sylvain@boiteaspam.info>
écrivait dans fr.comp.lang.php:

Genre en effet, a chaque requete on repart de zero, tout les fichiers
sont re-pars'es, la config de l'appli qui tourne recharg'ee etc

choix du langage, pas défauts du langage.

on parle ici de pages ouèbes générées par un serveur http, le module
PHP devrait-il garder un contexte (d'un des N visiteurs) en mémoire
alors que rien ne permet de savoir si la prochaine page (requête)
sera faite dans 2 sec. ou 2 heures ?
doit-on cacher ce contexte alors que le serveur apache d'une part et
l'OS d'autre part participent déjà à la gestion de mise en cache des
fichiers souvent lus ?

Il y a 30 ou 40 ans, l'informatique fonctionnait de cette façon.
Quand on lançait un logiciel, c'est-à-dire quand on insérait une
pile de cartes perforées dans le lecteur, tout se faisait à partir
de zéro. Tout ? Pas vraiment car on pourrait conserver certaines
valeurs. C'est la même chose en PHP.

Un moteur de recherche peut par exemple conserver les résultats d'une
recherche précédente en mémoire. Cela a toutefois un coût, celui
d'inscrire dans la base de données ou sur le disque ces résultats.
Je pense qu'en général, le coût est moindre de recommencer à zéro
que de conserver les résultats précédents. Par ailleurs, c'est un
choix du programmeur de conserver ou pas ces résultats puisque PHP
permet de conserver des variables en mémoire. Donc, ce n'est pas
réellement un inconvénient du langage.

En fait, quand on repense à d'autres applications comme un
questionnaire sur plusieurs pages, et à leur mise en oeuvre en
PHP, je vois mal le problème de repartir à zéro puisque c'est un
bon exemple où, du point de vue des données, on ne repart pas à zéro.

Le problème restant serait alors celui de la non-compilation du PHP
et c'est une question de mise en oeuvre et non de langage...


Denis

Sylvain SF wrote:

Eloims a écrit :

Apres c'est vrai que comme dans tous les langages "grand public" on
voit tres souvent des choses effarantes qui sont écrites et publiées
un peu partout sur le net...

savoir que certains peuvent commettre çi ou ça avec tel langage
n'apprend pas grd chse sur ce langage - ce n'est pas un inconvénient
*de* PHP si certains codent comme des anes.

on est d'accord, mais ca ne change rien au faits.

Certains langages sont plus propices a faire des cochoneries que d'autres.
Bien que ce n'est plus le cas aujourd'hui vu que PHP a enormement
progresse, PHP reste l'inventeur "d'aide a la programmation" pas
forcement tres catholiques

- magic quoting: qui backslash toute les strings pour eviter l'injection SQL
Complètement stupide vu que selon la base de donnée qu'on utilise les
caractères a backslasher sont différents, et puis bon on a pas envie de
TOUT backslasher non plus.
Une fois je me suis retrouver a heberger un site perso sur un hebergeur
qui ne permettait pas de desactiver ce truc, et j'ai du mettre des
stripslahses() partout pour ne plus avoir de probleme d'affichage.

C'est fait dans le dos de l'utilisateur, et on n'y comprend rien.

- register globals: en debut de script toutes les variables en GET et
POST sont déclarées o/
l'utilisateur peut donc declarer des variables dans nos scripts.
C'est la fete!

- une variable est estimée fausse si elle vaut "", 0, null ou false ou
qu'elle n'existe pas.
Donc en gros on était tente de faire !$variable pour tester l'existence
d'une variable (oui c'est mal! mais qd on debute on debute), et se
retrouvait avec des bugs incompréhensibles....

et mention speciale a dl() qui permettait de charger des .so/.dll sur la
machine de l'hebergeur, et de s'en servir (jusqu'à que le safe mode soit
ajouté pr controler la chose, c'est vrai que c'est pratique des fois dl())

Ceci dit on est bien d'accord sur un point: depuis PHP5 et 6, tout ceci
est fini, et j'attend beaucoup des versions a venir.

Peut être aura t'on la même évolution que de Action Script 2 a 3 (AS et
PHP n'ont rien a voir mais bon):
un langage qui devient explicitement typé, perso j'ai bien aim'e, meme
si la communauté Flash a l'air d'avoir detest'e.
(je n'ose pas ecrire statiquement type, ce n'est pas le cas pour l'AS)

ca met la possibilité de publier du contenu a la portee de presque
tout le monde

c'est en effet une caractéristique plus significative.

comparé à des J2E, WebObjects, ou autre dotnetteries MS, PHP a
l'énorme avantage de permettre gratuitement avec n'importe quel
serveur libre d'implémenter ce qui requiert moultes dépenses ailleurs.

Genre en effet, a chaque requete on repart de zero, tout les fichiers
sont re-pars'es, la config de l'appli qui tourne recharg'ee etc

choix du langage, pas défauts du langage.

on parle ici de pages ouèbes générées par un serveur http, le module
PHP devrait-il garder un contexte (d'un des N visiteurs) en mémoire
alors que rien ne permet de savoir si la prochaine page (requête)
sera faite dans 2 sec. ou 2 heures ?
doit-on cacher ce contexte alors que le serveur apache d'une part et
l'OS d'autre part participent déjà à la gestion de mise en cache des
fichiers souvent lus ?

Je ne parle pas de contexte attache a un utilisateur precis ($_SESSION
qui est serialise entre chaque requete, a moin qu'on aille changer les
handler <= ca c'est bien fait par contre).

Dans le cas des framework, clairement oui.
Une grande partie du contexte est partagee par tous les utilisateurs de
l'application, et php se voit obliger de recharger le tout a chaque requête.

Je suis effare par la quantité de fichiers de config ayant toujours le
même contenu que php doit reparser a chaque requête avec Symfony (ou
autre framework php... c'est clairement pas la concurrence qui manque!
et ne parlons pas des CMS).


Rien a voir, d'ailleur, mais j'y pense maintenant.
Un avantage enorme de PHP: la quantitee de projets opensource disponible.
On a vraiment tout sous la main, frameworks, cms, bbs, blogs etc
et avec les lib qui sont fournies avec php on peut par exemple manipuler
et generer des images en quelques lignes

Quand on se lance sur un projet, la majoritee du truc est clairement
souvent deja faite.
C'est moin le cas en Python ou Ruby on Rails (frameworks mis a part,
peut etre plus, mais je me suis pas assez renseign'e)

Bon il y a des histoires pour faire du byte code avec le php je crois?
ou au moin des systeme de cache, mais c'est une fausse solution pour
recuperer d'un cote ce qu'on pert de l'autre.

hmm, non, une compilation des définitions de classes PHP serait en
effet un truc significatif pour améliorer le traitement des scripts,
bcp plus que le cache des instances de ces classes.

bon ok je vais me cacher.

Bruno Desthuilliers wrote:

Il y a aussi le modèle d'exécution, qui fait qu'il faut reconstruire le
monde entier à chaque requête.

N'est-ce pas HTTP qui est "en cause"? c'est HTTP qui est conçu comme ça.

Eloims a écrit :
(snip)

Rien a voir, d'ailleur, mais j'y pense maintenant.
Un avantage enorme de PHP: la quantitee de projets opensource disponible.
On a vraiment tout sous la main, frameworks, cms, bbs, blogs etc

La plupart de ceux que j'ai vu souffrant du problème évoqué plus plus
haut, à savoir une qualité plus que moyenne...

(snip)

Quand on se lance sur un projet, la majoritee du truc est clairement
souvent deja faite.
C'est moin le cas en Python ou Ruby on Rails (frameworks mis a part,
peut etre plus, mais je me suis pas assez renseign'e)

En ce qui concerne Python, je crains en effet que tu ne te sois pas très
bien renseigné (c'est un euphémisme).

Mihamina Rakotomandimby a écrit :

Bruno Desthuilliers wrote:

Il y a aussi le modèle d'exécution, qui fait qu'il faut reconstruire
le monde entier à chaque requête.

N'est-ce pas HTTP qui est "en cause"? c'est HTTP qui est conçu comme ça.

Non. Tu confonds le caractère 'sans état' du protocole HTTP avec le
modèle d'exécution du serveur. Si tu prend des frameworks Python comme
Django, Pylons etc, tu a généralement un (ou plusieurs, selon la méthode
de déploiement) interpréteurs Python lancés, qui restent actifs entre
deux requêtes, et conservent tous les imports (bibliothèques,
configuration etc) en mémoire. Il n'y plus guère que quelques objets à
instancier pour servir une requête. Alors qu'en PHP, il faut *tout*
recharger à chaque requête.

Après, selon le cas d'utilisation, la complexité de l'appli, le type
d'hébergement etc, l'une ou l'autre solution présentent des avantages et
des inconvénients. L'un des inconvénients du modèle PHP est qu'il ne se
prête guère à trop d'abstraction, puisque la quantité de code à charger
et parser à chaque requête peut facilement devenir prohibitive
(accessoirement, l'absence d'espace de nommage digne de ce nom n'aide
pas non plus de ce point de vue là). Essayer de copier en PHP les archi
des serveurs d'applications basés sur des long runnning process est AMHA
une erreur - ni le langage (intrinsèquement procédural malgré la greffe
façon OGM d'un modèle objet essentiellement pompé sur Java), ni le
modèle d'exécution.ne s'y prêtent. Enfin, AMTHA, n'est-ce pas...