Le PHP aurait été créé par un « faux programmeur »

il faudrait que tous les langages s'écrivent comme en windev ? (du français presque ..)

moi j'écris pas du code de façon à ce que mon boulanger puisse le maintenir.

J'entrerais dans ce débat en vous collant ici juste une citation tiré de du livre PHP IN ACTION. Désolé pour ceux qui ne seraient pas à l'aise avec l'anglais. Je pense qu'il a tout dit.

Salut les pros, puisque vous parlez des programmeurs du dimanche en voici un qui amène sa fraise
Moi je dis merci Rasmus quand je vois tout ce que j'ai réussi à faire avec PHP (+Mysql) : une dizaines de sites web (perso et pros) dont certains ont eu beaucoup de succès dans leur domaine, des applis perso et des développements pour le boulot (simples mais qui nous ont économisés des dizaines de milliers d'euros).

Les avantages énormes de PHP sont :
- la simplicité pour démarrer qui permet de faire concrètement des choses simples sans pratiquement rien connaitre de la programmation mais avec une progression possible et relativement facile vers des choses complexes.
- les ressources colossales qu'on trouve sur le web en matière de tutoriels, de forum, de code voire d'applications complètes.
- la gratuité du language lui-même et du serveur local, le très faible coût d'hébergement et son coté universel chez les hébergeurs
- l'association efficace avec Mysql (et maintenant Postgresql)

Les défauts de PHP ne pèsent pas lourds par rapport aux avantages évoqués ci-dessus.
De toutes façons je pense qu'on peut faire du très bon boulot avec PHP et qu'on peut faire du code horrible et inopérant avec JSP ou ASP (j'ai des exemples à la pelle... tous développés par des programmeurs dits "professionnels".

Cela dit par rapport à ses débuts je pense qu'il y a de moins en moins de programmeurs débutants/amateurs, ceux-ci s'orientant directement vers des solutions type CMS (Joomla, Drupal,...) qui n'existaient pas au démarrage de PHP.

salut ,

je suis dev. actionScript et viens mettre ma ptite graine dans la discussion, je peux ? Vais-je être victime d'une cabale .

Pour ce qui est du typage, j'ai pu voir mon language favori passer de typage faible, du code étalé partout ect...
a un language hyper-structuré basé sur ecmascript4. Et pour moi il n'y a pas photo.

+
- moins de perte de temps dans le débogage, le compilo travaille presque a ma place.
- l'optimisation des perfs par apport au type et a l'architecture materielle. (ceci grace a l'avm2 qui interprete as3 en JIT dans le player).
Ainsi le type "int" et 2 fois plus rapide que le type "Number" et 4 fois plus que le type "uint"(x86 MMX,SSE). Sans compter l'optimisation mémoire bien entendu.
- la quasi obligation de s'intéresser a l'architecture logiciel et donc de progresser.

-
- perte de temps a typé ses variables.
- la quasi obligation de s'intéresser a l'architecture logiciel et donc de progresser, et oui ca peut être un inconvénient selon notre implication ou notre passion pour la programmation.


Pour la montée en charge, cela est, je pense humblement, une affaire architecturale, c'est sur, mais aussi philosophique.

Je pense personnellement qu' il existe 2 philosophies:

- jm'en fous. Tout comme mon client, je veux rapidement gagner des sous et jvais pas essayer de me prendre la tête avec des "gadjets" de geek.
De toute façon il n'y aura jamais de monter en charge, et pour le moment mon "truc" rempli son rôle, le client est content, que demande le peuple?
.. des design patterns ? ...non, des sous .
Bien entendu, une partie de ces sous risque d'être perdus, lors de la maintenance, mais ca n'est pas grave, on verra, puis surtout si j'arrive a la faire casquer au client, a part la gloire, j'ai tout gagné.

- Je suis passionné, veut faire les choses bien, et donc la montée en charge, l'architecture ect... est le "premier" de mes soucis(au delà de l'implémentation pur et dur), mon application doit être : stable, solide, et agile. J'espère aussi fortement être reconnus et gagner beaucoup de sous.

Donc si une appli PHP est peu scalable ou evolutive, ce n'est pas a cause du langage PHP en lui même, mais plutôt a la culture du scripting qu'il induit.

Bon c'est caricaturale, je n'ai pas apporté grand chose a ce qui a déjà été dit, mais c'est un sujet qui me plait, donc j'avais besoin de réagir.

Oui, on peut s'en sortir dans un monde idéal où on a le temps de mettre en place tous les palliatifs à ce qu'on n'a pas.
Mais soyons réaliste. Dans la vrai vie, on a des délais de livraison à tenir.
Lorsqu'on est loin de la deadline, on a plein de grands principes, on va faire ci, on va faire ça, on va respecter toutes les règles de l'art... Bref on perds du temps pour se faire plaisir.
Et plus la deadline approche, et plus ça devient : "peut importe ce qu'on fait, ce qui compte c'est que ça marche" :
- En générale, la doc est sacrifiée en premier pour récupérer du temps pour que ça marche.
- Puis on supprime les tests unitaires, (quoique beaucoup n'en font pas de toutes façon).
- Ensuite on supprime les tests d'intégrations.
- On finit par se contenter de quelques tests fonctionnels superficiels qui ne couvriront même pas toutes les fonctions essentielles.
- Et parfois, on livre même en sachant que ça ne marche pas

Si on ajoute à celà qu'en informatique, les retards font parti des règles de l'art, et que lorsque on estime une charge, on peut être sûr qu'on l'a sous-estimée...

J'ai qu'en même tendance à dire que pour avoir une application fiable malgré tout, le meilleur moyen de ne pas avoir de bugs c'est de commencer par ne pas en faire
Et de ce côté, le typage statique est qu'en même très utile pour empêcher d'écrire n'importe quoi à la source. On détecte immédiatement bon nombre d'erreurs de conception au moment même où on écrit le code (plutôt qu'au moment des tests).
C'est con à dire, mais si on se retrouve à additionner des choux et des carottes, c'est que la formule est fausse. Donc que toute l'analyse est fausse.
Il est qu'en même dommage de devoir attendre les tests pour ce rendre compte que l'approche du problème était erronnée !

Moi je trouve que les langages sans vérification des types à la compil ne font pas gagner du temps et ne simplifient rien. Ce sont des pièges à débutant !
Je connais pas mal de développeurs PHP a qui je n'ai jamais réussir à faire comprendre la différence entre une date et son format d'affichage (idem pour les nombres et le séparateur décimal).

Il y a du vrai dans ce qu'il dit.

PHP est a peu près tout ce que je n'aurais pas fait comme vrai langage de programmation ^^

Mais s'il est aussi populaire c'est que justement il n'est pas conçu comme un langage de programmation

Par exemple, on va me dire que Java c'est super génial, et c'est sans doute vrai, mais pour expliquer à un gamin de 10 ans comment faire un Hello World en Java, il faut commencer par lui expliquer ce qu'est un objet, que c'est la méthode truc (suivant le contexte) qui démarre, puis l'évènement machin pour faire telle chose...en PHP tu tapes "Hello World"

Et les derniers ajouts sur PHP sont douteux car on veut faire d'une brosse à dents un outil professionnel...ce qui n'est pas facile !

Moi j'ai toujours été bluffé de voir ce que pouvait faire un "programmeur du dimanche"

j'ai déjà vu ce genre de code :
aucun programmeur ne ferait ça...mais ça fonctionne tout de même et n'est-ce pas le résultat qui compte ?

généralement ce qui mérite d'être fait mérite d'être bien fait.
et en informatique ce qui fonctionne n'est pas forcément correct, alors je dirai non il n'y a pas que le résultat qui compte.

Pas tout faux du tout. T'as tout dit. Tout est dans la dernière phrase.