/* Topic des codeurs couche-tard [5] */

The Uploader · Le 14/06/2011, à 21:39

tshirtman a écrit :

J'ai pas la source, mais plusieurs personnes relativement indépendantes m'ont fait cette citation, donc je la crois vraie, et c'était plus "anybody wanting to do nice code in php should fucking get out" ou un truc du genre.

+1, vu sur developpez.com, mais je ne l'ai pas retrouvé jusqu'ici.

grim7reaper · Le 14/06/2011, à 21:40

Bah regarde mon post précédent…
Il dit bien des choses dans ce sens (et ça reviens au même, je vous l'accorde), mais pas la fameuse citation

Dernière modification par grim7reaper (Le 14/06/2011, à 21:41)

tshirtman · Le 14/06/2011, à 23:05

hum… zed shaw a encore frappé…

http://programming-motherfucker.com/

Pylades · Le 14/06/2011, à 23:11

Ben ouais, il dit qu’il n’aime pas programmer, que PHP est fait pour programmer moins, que PHP s’adresse aux non-programmeur, que PHP n’est pas conçu comme un langage de programmation mais comme un outil au sens le plus basique du terme, que les gens qui veulent faire du code propre ne devraient pas utiliser PHP…

Donc oui, il que PHP n’est pas prévu pour que l’on développe quelque chose de sérieux avec.

nathéo · Le 14/06/2011, à 23:19

;

The Uploader · Le 14/06/2011, à 23:20

plop;

@t'man : impossible de trouver le serveur.. c'est bon maintenant.
Par contre les tests unitaires restent utiles... (quant au TDD j'ai jamais pratiqué, mais ça me semble loin d'être idiot, tout comme l'XP).

Dernière modification par The Uploader (Le 14/06/2011, à 23:27)

tshirtman · Le 14/06/2011, à 23:35

Non, mais zed shaw est un peu dans son trip, "je suis le plus fort, je fais comme je veux, ça marche et vous moquez pas de moi alors que vous êtes pleins a bouffer graçe à moi", un peu trop desfois ^^.

Après, ce sont des outils, il faut les mettre en place quand ils sont nécessaire, mais comme d'hab, ils ne sont pas un fin en soit…

je lirait bien le bouquin, mais bon, 11€ le pdf quoi…

Elzen · Le 14/06/2011, à 23:44

tshirtman a écrit :

J'ai pas la source, mais plusieurs personnes relativement indépendantes m'ont fait cette citation, donc je la crois vraie

Plusieurs personnes relativement indépendantes m'ont affirmé qu'Einstein était l'auteur de la fameuse citation sur les abeilles

Après, que PHP ne soit pas prévu pour les vrais bon trucs bien sérieux, c'est probable : après tout, un ordinateur, matériellement comme logiciellement, c'est juste un gros tas de trucs qui ne sont pas du tout prévus pour ça à la base, non ?

D'où les divers changement de protocoles et de versions que nous connaissons tous, et le fait que certains trucs, dans à peu près tous les langages, restent dépréciées un bon moment parce qu'ils sont juste complètement nazes, mais qu'on doit les garder pour assurer la rétro-compatibilité.

Esthétiquement, PHP, ça dépend du sens de l'esthétique de chacun (moi j'aime bien ; mais j'aime bien aussi le Shell, le C, le Java, le Python, le Lisp, et à peu près tous les langages que j'ai essayé jusque là, à part le Pascal et les regexp).

Dans l'utilisation, j'affirme haut et fort que ç'pas pire qu'autre chose (mais je suis d'accord pour dire que faire de l'objet avec, ç'pas forcément une super idée. Ça peut éventuellement être pratique d'avoir des objets à manipuler pour certains trucs, mais ça reste un truc à utiliser principalement en impératif, je pense).

The Uploader · Le 14/06/2011, à 23:55

Dans l'utilisation, j'affirme haut et fort que ç'pas pire qu'autre chose

*KOF*

Quand PHP te donne 0 au lieu d'une erreur, que tu peux faire planter l'interpréteur, que le langage est inconsistant, que tu peux déclarer des functions dans des if (WTF ?), etc... (voir notamment le site "phpsadness", et "lolphp" sur reddit).

Tout cela rend PHP inutilisable, à moins de ne connaître que ça (donc de n'avoir aucun point de comparaison). Même le GFA Basic c'est mieux..

Personellement je connais pas pire que le PHP, et de loin.

Dernière modification par The Uploader (Le 14/06/2011, à 23:55)

tshirtman · Le 14/06/2011, à 23:59

Non, c'est cool de pouvoir déclarer des fonctions dans des if ce qui est mal c'est que la fonction soit déclarée même si le code ne rentre pas dans le if!

Dernière modification par tshirtman (Le 15/06/2011, à 00:00)

Pylades · Le 15/06/2011, à 00:17

Euh, t’es sérieux ? O_o'
À part si tu parles de faire des définitions conditionnelles avec le préprocesseur, là OK. Mais sinon, WTF !

Édit avant post : je me suis rendu compte que je raisonnait pour un langage compilé. Pour un langage interprété, hum admettons… Mais je ne suis pas sûr du tout de voir l’intérêt…

Elzen · Le 15/06/2011, à 00:32

Déclarer des fonctions n'importe où, on peut le faire aussi en python (après, si la fonction est effectivement crée même quand on ne rentre pas dans le if, ç't'autre chose… je n'ai jamais rencontré le cas, n'ayant que rarement recours à des créations conditionnelles de fonction, mais c'est effectivement moche)

Récupérer zéro plutôt que déclencher une erreur quand on essaye de récupérer une valeur numérique à partir d'une chaîne de caractère qui ne l'est pas n'est pas franchement une bêtise, à mon sens. D'ailleurs, je suis à peu près certain que c'est le comportement dans d'autres langages aussi.
Ceci dit, si j'avais à choisir, je dirais que cette fonction devrait dans ce cas renvoyer faux, afin de pouvoir faire la distinction, mais que faux serait lui-même utilisable comme la valeur numérique zéro, ce qui reviendrait au même en étant juste un peu plus propre.
Quoi qu'il en soit, tant que le comportement attendu est clairement défini dans la spécification, je ne vois pas où est le problème. Et puis baser son code sur le déclenchement et la récupération d'erreurs, à titre personnel, je ne trouve pas ça propre du tout, et je préfère l'éviter quand c'est possible.

Après, pour l'addition d'une chaîne de caractère à autre chose, c'est un autre problème. PHP part du principe que l'addition et la concaténation sont deux actions distinctes, ayant donc des opérateurs différents, ce qui, de mon point de vue, est un excellent comportement, pour moi, c'est un point sur lequel PHP est nettement mieux conçu que la plupart des autres langages.
Ensuite, qu'il y ait un « cast » automatique au cours de l'opération, c'est effectivement discutable, mais sur un langage à typage faible et dynamique, ça ne me choque pas. Je ne dis pas que c'est le meilleur comportement, mais c'est un comportement dont la logique se tient et est tout à fait recevable (on peut, en C, utiliser un pointeur ou un caractère comme étant un entier sans aucun cast explicite, après tout : râle-t-on contre le C à ce propos ?)

Faire planter l'interpréteur, je n'ai jamais rencontré le cas non plus… mais si ça arrive, j'aurais tendance à considérer que c'est la faute de l'interpréteur, pas du langage. Le langage JavaScript lui-même est-il à blâmer si on peut produire un code tellement pourri que le navigateur peut crasher ?
Certains TdCCTistes se sont amusés (ou pas), il y a quelques temps, à coder des interpréteurs BrainFuck : si d'aventure l'un de leurs interpréteur se cassait la tronche en cours de route, était-ce la faute du BrainFuck ?

Pour l'inconsistance, je crois bien que je ne vois pas du tout quel peut être le sens de ce mot.

Dernière modification par ArkSeth (Le 15/06/2011, à 00:35)

Pylades · Le 15/06/2011, à 00:55

ArkSeth a écrit :

Récupérer zéro plutôt que déclencher une erreur quand on essaye de récupérer une valeur numérique à partir d'une chaîne de caractère qui ne l'est pas n'est pas franchement une bêtise, à mon sens. D'ailleurs, je suis à peu près certain que c'est le comportement dans d'autres langages aussi.

Nan, des erreurs manifestent passent silencieusement, mais ce n’est pas grave, dormez tranquilles…

ArkSeth a écrit :

Ceci dit, si j'Ceci dit, si j'avais à choisir, je dirais que cette fonction devrait dans ce cas renvoyer faux, afin de pouvoir faire la distinction, mais que faux serait lui-même utilisable comme la valeur numérique zéro, ce qui reviendrait au même en étant juste un peu plus propre.

Donc en gros ça ne change rien, trop bien.

ArkSeth a écrit :

Quoi qu'il en soit, tant que le comportement attendu est clairement défini dans la spécification, je ne vois pas où est le problème. Et puis baser son code sur le déclenchement et la récupération d'erreurs, à titre personnel, je ne trouve pas ça propre du tout, et je préfère l'éviter quand c'est possible.

Le problème c’est que la spécification elle ne le sait pas. Qu’attendre d’un langage qui supporte l’octal par accident ?

ArkSeth a écrit :

Après, pour l'addition d'une chaîne de caractère à autre chose, c'est un autre problème. PHP part du principe que l'addition et la concaténation sont deux actions distinctes, ayant donc des opérateurs différents, ce qui, de mon point de vue, est un excellent comportement, pour moi, c'est un point sur lequel PHP est nettement mieux conçu que la plupart des autres langages.

En C, les opérateur de déréférencement et de multiplication ont le même symbole. Le C est nettement moins bien conçu que les autres langages ?

ArkSeth a écrit :

Ensuite, qu'il y ait un « cast » automatique au cours de l'opération, c'est effectivement discutable, mais sur un langage à typage faible et dynamique, ça ne me choque pas. Je ne dis pas que c'est le meilleur comportement, mais c'est un comportement dont la logique se tient et est tout à fait recevable […]

Ben, oui, une chaîne se transforme en entier comme par magie, c’est vrai que c’est parfaitement logique.

ArkSeth a écrit :

[…] (on peut, en C, utiliser un pointeur ou un caractère comme étant un entier sans aucun cast explicite, après tout : râle-t-on contre le C à ce propos ?)

Un caractère est un entier, donc pas de raison de reprocher quoi que se soit. Et non, on ne peut pas se servir d’un pointeur comme d’un entier comme si de rien n’était, en tous cas avec un compilateur civilisé (et si on peut passer outre les warnings, c’est seulement car le pointeur est aussi un nombre, à la base). En revanche on peut faire de l’arithmétique des pointeurs, mais c’est justement car le pointeur n’est pas casté en entier.

ArkSeth a écrit :

Faire planter l'interpréteur, je n'ai jamais rencontré le cas non plus… mais si ça arrive, j'aurais tendance à considérer que c'est la faute de l'interpréteur, pas du langage. Le langage JavaScript lui-même est-il à blâmer si on peut produire un code tellement pourri que le navigateur peut crasher ?

Ce n’est pas hyper joli non plus le JavaScript, mais PHP ce n’est pas que le langage, c’est le langage plus l’interpréteur (comme Python, par exemple), sinon il ne supporterait pas l’octal par accident.

ArkSeth a écrit :

Certains TdCCTistes se sont amusés (ou pas), il y a quelques temps, à coder des interpréteurs BrainFuck : si d'aventure l'un de leurs interpréteur se cassait la tronche en cours de route, était-ce la faute du BrainFuck ?

Non, ça serait de la fait du TdCTiste. Le brainfuck rempli correctement le rôle pour lequel il a été créé, et il n’est utilisé que pour ça, lui. :]

ArkSeth a écrit :

Pour l'inconsistance, je crois bien que je ne vois pas du tout quel peut être le sens de ce mot.

Par exemple, en C, l’ordre des argument de f* versus fscanf et fprintf ; ça c’est inconsistant.

Désolé, mais PHP et code propre ou sérieux, c’est incompatible.

Dernière modification par Pylade (Le 15/06/2011, à 00:56)

tshirtman · Le 15/06/2011, à 01:11

Pylade a écrit :

Euh, t’es sérieux ? O_o'
À part si tu parles de faire des définitions conditionnelles avec le préprocesseur, là OK. Mais sinon, WTF !

Édit avant post : je me suis rendu compte que je raisonnait pour un langage compilé. Pour un langage interprété, hum admettons… Mais je ne suis pas sûr du tout de voir l’intérêt…

Hum, si tu veux deux versions très différente d'une fonction, selon un cas? Après, je dis pas que c'est indispensable, mais dans certain cas, ça peut servir, je ne vois pas le mal à pouvoir le faire. (notamment si tu veux faire de la méta programmation, des décorrateurs, des trucs un peu abstrait quoi).

ArkSeth a écrit :

Déclarer des fonctions n'importe où, on peut le faire aussi en python (après, si la fonction est effectivement crée même quand on ne rentre pas dans le if, ç't'autre chose… je n'ai jamais rencontré le cas, n'ayant que rarement recours à des créations conditionnelles de fonction, mais c'est effectivement moche)

oh, j'invente pas http://codepad.org/VtHkYei7

Récupérer zéro plutôt que déclencher une erreur quand on essaye de récupérer une valeur numérique à partir d'une chaîne de caractère qui ne l'est pas n'est pas franchement une bêtise, à mon sens. D'ailleurs, je suis à peu près certain que c'est le comportement dans d'autres langages aussi.
Ceci dit, si j'avais à choisir, je dirais que cette fonction devrait dans ce cas renvoyer faux, afin de pouvoir faire la distinction, mais que faux serait lui-même utilisable comme la valeur numérique zéro, ce qui reviendrait au même en étant juste un peu plus propre.

Je préfère les cast explicites… quand t'as plusieurs cast implicites comme ça qui peuvent s'enchainer, les typos peuvent faire des dégats considérables…

Quoi qu'il en soit, tant que le comportement attendu est clairement défini dans la spécification, je ne vois pas où est le problème. Et puis baser son code sur le déclenchement et la récupération d'erreurs, à titre personnel, je ne trouve pas ça propre du tout, et je préfère l'éviter quand c'est possible.

Les exceptions? c'est ce qu'il y a de plus propre et de plus souple, si on ne les gère pas a un niveau, elles remontent, jusqu'en haut si personne s'en occupe, ou jusqu'à la couche ou on peut sainement prendre une décision en fonction du type d'erreur remonté, c'est juste parfait quoi… devoir checker tout le temps la valeur ou le type d'un résultat pour savoir si tout c'est bien passé, ou juste prier pour que ça marche, en sachant qu'on aura rien d'autre que des résultats incohérents pour s'en rendre compte si ce n'est pas le cas, j'aime pas trop beaucoup ça…

Après, pour l'addition d'une chaîne de caractère à autre chose, c'est un autre problème. PHP part du principe que l'addition et la concaténation sont deux actions distinctes, ayant donc des opérateurs différents, ce qui, de mon point de vue, est un excellent comportement, pour moi, c'est un point sur lequel PHP est nettement mieux conçu que la plupart des autres langages.

C'est un choix acceptable, discutable, mais acceptable, l'addition de deux chaines de caractères n'a guère de sens hors de la concaténation, mais bon, ce sont deux opérations différentes, j'accepte… par contre…

Ensuite, qu'il y ait un « cast » automatique au cours de l'opération, c'est effectivement discutable, mais sur un langage à typage faible et dynamique, ça ne me choque pas. Je ne dis pas que c'est le meilleur comportement, mais c'est un comportement dont la logique se tient et est tout à fait recevable (on peut, en C, utiliser un pointeur ou un caractère comme étant un entier sans aucun cast explicite, après tout : râle-t-on contre le C à ce propos ?)

oui, le cast automatique, c'est le principe d'un typage faible, on donne le type qui nous arrange selon l'humeur, c'est une mauvaise idée, ça ne l'empèche pas d'être cohérente, c'est juste dangereux quand on tente par ce moyen de pouvoir faire n'importe quelle opération avec n'importe quel type de donnée, en faisant les conversions qui conviennent de façon transparente, ça encourage le développeur à ne pas se soucier de ce qu'il se passe, et à ne même pas bien comprendre ce qu'est un type de donnée. Pour le C, ça tiens plus du détail d'implémentation, et ça génère warnings ou erreur la plupart du temps, et oui, on peut raler sur cet aspect du C, par ce que ça peut faire des bugs qui piquent bien (genre addition d'un entier a un pointeur au lieu de la variable associée) qui sont inhérent à son mode de fonctionnement, mais demandent de comprendre mieux ce qu'on fait pour pas faire du code catastrophique…

Faire planter l'interpréteur, je n'ai jamais rencontré le cas non plus… mais si ça arrive, j'aurais tendance à considérer que c'est la faute de l'interpréteur, pas du langage. Le langage JavaScript lui-même est-il à blâmer si on peut produire un code tellement pourri que le navigateur peut crasher ?
Certains TdCCTistes se sont amusés (ou pas), il y a quelques temps, à coder des interpréteurs BrainFuck : si d'aventure l'un de leurs interpréteur se cassait la tronche en cours de route, était-ce la faute du BrainFuck ?

Ouais, mais on parle de l'interpréteur de référence là… et moi j'ai eu le cas plus d'une fois, sur du code en production, je t'assure que c'est pas rigolo (et quand c'est l'application qui gère les réservation de vacances pour le syndic d'EDF pour toute la france, je t'assure que tu ne veux pas avoir ce genre de choses qui plante en juin… pour l'annectode). Donc pour info, quand tu as une page blanche, alors même que la première ligne de ton code php est un "echo 'plop';" c'est que l'interpréteur a crashé en parsant ton code, et ça peut être n'importe ou dans le fichier de 12000 lignes que t'as laissé le mec qui bossait avant).

Donc, en plus de mes reproches au langage lui même, c'est un reproche purement technique, à l'implementation elle même…

Elzen · Le 15/06/2011, à 01:45

Pylade a écrit :

Nan, des erreurs manifestent passent silencieusement, mais ce n’est pas grave, dormez tranquilles…

Ç'pas plus une erreur manifeste que de diviser par zéro.
Et il me semble bien qu'il existe plusieurs langages dans lesquels diviser par zéro ne cause aucune erreur, mais renvoie juste la constante NaN.

La programmation à base de levées d'exceptions, c'est bien, mais seulement dans certains cas. Exactement comme d'autres concepts, genre l'objet.

Pylade a écrit :

Donc en gros ça ne change rien, trop bien.

Ça changerait qu'il serait possible de vérifier (avec un ===, d'ailleurs au passage, c'est aussi une bonne idée de fournir une comparaison « au type près » et une autre « en tenant compte du type ». Je ne sais pas trop ce qu'il en est avec d'autres langages pour lesquels le cas est théoriquement possible, genre Python) s'il y a eu erreur ou pas, mais sans avoir besoin de recourir à des levées d'exceptions, ce qui à mon sens est la plus propre des trois approches.

Pylade a écrit :

Le problème c’est que la spécification elle ne le sait pas. Qu’attendre d’un langage qui supporte l’octal par accident ?

Hmm, sur le support accidentel de l'octal, j'en sais rien, j'me sers rarement de l'octal, mais je suppose que je veux bien des explications à ce sujet.
Si vraiment la spec n'est pas définie à ce sujet, même a posteriori maintenant que le comportement est connu, c'est en effet assez grave. Mais c'est un truc pour lequel je ne te croirai pas sur parole

Pylade a écrit :

En C, les opérateur de déréférencement et de multiplication ont le même symbole. Le C est nettement moins bien conçu que les autres langages ?

Sur ce point là bien particulier, oui.
Ça n'en fait pas une généralité du tout (j'ai précisé explicitement dans le post que tu citais que cette appréciation ne portait que sur ce point-là), mais que deux opérations sans rapport l'une avec l'autre disposent de deux opérateurs différents, ça devrait juste être évident, je trouve.
(Après, il y a aussi le fait que sur les deux opérations en question, l'une d'elle n'est pas forcément présente dans beaucoup d'autres langages)

Pylade a écrit :

Ben, oui, une chaîne se transforme en entier comme par magie, c’est vrai que c’est parfaitement logique.

Pas par magie, par cast implicite.
C'est parfaitement logique, oui, à partir du moment où l'on prend en compte les points entraînant cet état de fait (langage permissif, typage faible et dynamique, opération portant uniquement sur des entiers, et non-levée d'exceptions quand elles sont évitables. Partant de ces différents points, quel autre comportement que celui-ci proposerais-tu ?)

Pylade a écrit :

Un caractère est un entier, donc pas de raison de reprocher quoi que se soit. Et non, on ne peut pas se servir d’un pointeur comme d’un entier comme si de rien n’était, en tous cas avec un compilateur civilisé (et si on peut passer outre les warnings, c’est seulement car le pointeur est aussi un nombre, à la base). En revanche on peut faire de l’arithmétique des pointeurs, mais c’est justement car le pointeur n’est pas casté en entier.

Un caractère est un entier en C. En PHP, un entier est une chaîne de caractères. Ces deux choses ne sont pas plus ou moins évidentes l'une que l'autre : ce sont simplement les spécifications du langage (et l'habitude d'utiliser ce langage) qui les rendent normales ou anormales.
Je n'active peut-être pas autant de warnings que toi, mais je crois n'avoir encore jamais rencontré de compilation qui râlait parce que j'ai tapé ptr + i. C'est la base du fonctionnement des tableaux, d'additionner des pointeurs avec des entiers, et pourtant, sur le principe, ce n'est pas moins aberrant que d'additionner des entiers avec des chaînes de caractères (au lieu de prendre des choux et des tomates, on prend des choux et des concombres, mais ça reste une addition de légumes différents).
Sinon, sur les affaires de casts automatiques, on peut aussi considérer les pointeurs sur un type qui peuvent devenir des pointeurs sur un autre type « comme par magie » (c'est vous qui m'avez fait remarquer qu'il n'y avait pas besoin de caster le résultat d'un malloc, par exemple).

Pylade a écrit :

Ce n’est pas hyper joli non plus le JavaScript, mais PHP ce n’est pas que le langage, c’est le langage plus l’interpréteur (comme Python, par exemple), sinon il ne supporterait pas l’octal par accident.

Ç'pas un langage privatif non plus, hein : certes, il y a un interpréteur « de référence », mais rien n'empêche d'en coder un autre. Et si tu en codes un autre et qu'il est mieux que l'autre, il est même possible que le tien devienne plus utilisé.
Dire qu'un truc est mal pensé parce qu'il y a un problème dans son implémentation, c'est juste de la mauvaise foi : le fait que ce problème existe sur l'interpréteur php est effectivement un mauvais point (encore que, je le répète, même si je vous crois sur parole sur le fait que ça arrive, j'aimerais quand même bien avoir un peu plus de précisions sur les cas dans lesquels ça arrive). mais ça ne peut pas, honnêtement, être considéré comme un problème du langage PHP.

Pylade a écrit :

Par exemple, en C, l’ordre des argument de f* versus fscanf et fprintf ; ça c’est inconsistant.

…ce qui ne me renseigne pas le moins du monde sur le sens de ce mot, mais bon ^^

Pylade a écrit :

Désolé, mais PHP et code propre ou sérieux, c’est incompatible.

Désolé, mais PHP et code propre ou sérieux selon Pylade, c'est incompatible.
Et comme dans les critères de propreté et de sérieux de Pylade, il y a en toutes lettres « pas PHP », bah, dire ça ne sert juste à rien.
Propre et sérieux, c'est tout ce qu'il y a de plus subjectif, comme notion.

Bref, voilà, quoi : le langage PHP est loin d'être parfait, présente quelques problèmes, et ressemble sans doute plus à un gros bricolage qu'à un truc bien pensé, mais tout de même, les trois quarts de vos dénigrements sont juste des avis purement subjectifs ou de la mauvaise foi (parce que vous ne reprocheriez pas les mêmes choix faits dans d'autres langages qui vous plaisent plus). Reconnaissez-le, au moins

Presque edit, pour une fois j'ai pensé à regarder si quelqu'un avait posté entre temps avant de valider mon message : l'argumentation de tshirtman est recevable, elle, au moins : il reconnaît lui-même les points (casts, exceptions, …) sur lesquels il donne un avis personnel, et accepte de concevoir que la logique, si elle ne lui convient pas à lui personnellement, est quand même logique. Donc un gros +1 même si on est pas d'accord ^^

Et ç'malin : avec tous ces trolls, j'ai quasiment pas codé, même en Python

tshirtman · Le 15/06/2011, à 01:52

Presque edit, pour une fois j'ai pensé à regarder si quelqu'un avait posté entre temps avant de valider mon message : l'argumentation de tshirtman est recevable, elle, au moins : il reconnaît lui-même les points (casts, exceptions, …) sur lesquels il donne un avis personnel, et accepte de concevoir que la logique, si elle ne lui convient pas à lui personnellement, est quand même logique. Donc un gros +1 même si on est pas d'accord ^^

Ouais, mais j'ai raison quand même hein

et moi avec toutes ces lectures (a cause de stackoverflow, je suis partis loin), c'est mon rapport qui n'a pas avancé, pour dans 10 jours même pas, et qui est à 1/30eme de l'avancement >_<.

Dernière modification par tshirtman (Le 15/06/2011, à 01:53)

Elzen · Le 15/06/2011, à 01:57

Ou pas : t'as un point de vue qui se tient même si on n'est pas d'accord avec, comme les choix techniques de PHP dont on parlait plus tôt

Arf… courage. J'propose qu'on arrête de troller sur PHP (voire même sur d'autres langages) jusqu'à ce que tshirtman ait fini son rapport ^^

cm-t · Le 15/06/2011, à 02:01

'Nuit;

samυncle · Le 15/06/2011, à 02:02

.

nesthib · Le 15/06/2011, à 02:06

plop

tshirtman · Le 15/06/2011, à 02:06

Et j'ai pas dit logique, j'ai dit cohérent… faut bien que le langage respecte ses propres choix quoi… logique non, car c'est un choix qui apporte plus de désagréments que d'agréments.

Cela dit, on peut faire du PHP de meilleur qualité quand on a passé du temps sur d'autres langages entre temps, et qu'on ne dépends que de son propre code… c'est faisable… c'est juste que l'environnement PHP est constitué de pleins de bidouilleurs sans consciences et de pratiques de codes plus que douteuses, pour faire du bon code PHP il ne faut pas s'insipérer de la communauté php.

Pylades · Le 15/06/2011, à 03:34

tshirtman a écrit :

ArkSeth a écrit :
Quoi qu'il en soit, tant que le comportement attendu est clairement défini dans la spécification, je ne vois pas où est le problème. Et puis baser son code sur le déclenchement et la récupération d'erreurs, à titre personnel, je ne trouve pas ça propre du tout, et je préfère l'éviter quand c'est possible.
Les exceptions? c'est ce qu'il y a de plus propre et de plus souple, si on ne les gère pas a un niveau, elles remontent, jusqu'en haut si personne s'en occupe, ou jusqu'à la couche ou on peut sainement prendre une décision en fonction du type d'erreur remonté, c'est juste parfait quoi… devoir checker tout le temps la valeur ou le type d'un résultat pour savoir si tout c'est bien passé, ou juste prier pour que ça marche, en sachant qu'on aura rien d'autre que des résultats incohérents pour s'en rendre compte si ce n'est pas le cas, j'aime pas trop beaucoup ça…

Ah ouais, j’avais oublié d’en causer, de ça…

tshirtman a écrit :

[…] Pour le C, ça tiens plus du détail d'implémentation, et ça génère warnings ou erreur la plupart du temps, et oui, on peut raler sur cet aspect du C, par ce que ça peut faire des bugs qui piquent bien (genre addition d'un entier a un pointeur au lieu de la variable associée) qui sont inhérent à son mode de fonctionnement, mais demandent de comprendre mieux ce qu'on fait pour pas faire du code catastrophique…

Ben en C, avec un compilo civilisé, t’as un warning (ça fait même peut-être bien partie des warnings obligatoires), pour cause de conversion implicite, justement. Après, si tu veux quand même tenter, t’es grand, tu peux le faire car un pointeur c’est jsute un nombre au fond ; mais faut que tu sois sûr de toi et c’est de toutes façons moche. Cependant, le cas spécifique de l’addition ou la soustraction d’un entier à un pointeur, ça s’appelle de l’arithmétique des pointeurs et c’est bien pratique. La soustraction de deux pointeurs aussi est définie (mais t’as un risque d’overflow en 32 bits si tu utilises plus de 2 Gio de mémoire contiguë ).

ArkSeth a écrit :

Pylade a écrit :
Nan, des erreurs manifestent passent silencieusement, mais ce n’est pas grave, dormez tranquilles…
Ç'pas plus une erreur manifeste que de diviser par zéro.
Et il me semble bien qu'il existe plusieurs langages dans lesquels diviser par zéro ne cause aucune erreur, mais renvoie juste la constante NaN.
La programmation à base de levées d'exceptions, c'est bien, mais seulement dans certains cas. Exactement comme d'autres concepts, genre l'objet.

L’exception est une solution, NaN en est une autre. Dans les deux cas, l’erreur est signalée ; ce n’est pas silencieux (les exceptions permettant en plus de voir tout de suite d’où ça vient).

ArkSeth a écrit :

Pylade a écrit :
Donc en gros ça ne change rien, trop bien.
Ça changerait qu'il serait possible de vérifier (avec un ===, d'ailleurs au passage, c'est aussi une bonne idée de fournir une comparaison « au type près » et une autre « en tenant compte du type ». Je ne sais pas trop ce qu'il en est avec d'autres langages pour lesquels le cas est théoriquement possible, genre Python) s'il y a eu erreur ou pas, mais sans avoir besoin de recourir à des levées d'exceptions, ce qui à mon sens est la plus propre des trois approches.

Je ne vois pas de quoi tu parles (pour les histoires de type). Qu’as-tu contre les exceptions ?

ArkSeth a écrit :

Pylade a écrit :
Le problème c’est que la spécification elle ne le sait pas. Qu’attendre d’un langage qui supporte l’octal par accident ?
Hmm, sur le support accidentel de l'octal, j'en sais rien, j'me sers rarement de l'octal, mais je suppose que je veux bien des explications à ce sujet.

Ouais, un jour un mec qui n’y connaissant rien et peu scrupuleux à passé la base 0 à strtol pour le parsing des constantes entières. Or cette base signifie octal, décimal ou hexadécimal, au choix. Donc quand une constante entière commence par un 0, elle est reconnue comme décimale, mais convertie comme octale, et donc comme bien entendu aucun traitement des erreurs n’est réalisé, t’as des jolis comportements indéfinis si tu mets des constantes entières du genre de 0459236.

ArkSeth a écrit :

Pylade a écrit :
En C, les opérateur de déréférencement et de multiplication ont le même symbole. Le C est nettement moins bien conçu que les autres langages ?
Sur ce point là bien particulier, oui.
Ça n'en fait pas une généralité du tout (j'ai précisé explicitement dans le post que tu citais que cette appréciation ne portait que sur ce point-là), mais que deux opérations sans rapport l'une avec l'autre disposent de deux opérateurs différents, ça devrait juste être évident, je trouve.
(Après, il y a aussi le fait que sur les deux opérations en question, l'une d'elle n'est pas forcément présente dans beaucoup d'autres langages)

Ah, ouais, tu veux un symbole par opérateur ? Et quand il y a beaucoup d’opérateurs ? Tu leur donne des symboles à rallonge (deux signes c’est déjà trop ). À moment donné, il faut qu’un langage interprète le symbole en fonction du contexte, sinon c’est terrible. Tu n’as jamais essayé Perl, je parie… ^^
Au passage, c’est aussi tout un pan des langages orientés objet que tu remets en question : la surcharge des opérateurs, toussa…

ArkSeth a écrit :

Pylade a écrit :
Ben, oui, une chaîne se transforme en entier comme par magie, c’est vrai que c’est parfaitement logique.
Pas par magie, par cast implicite.
C'est parfaitement logique, oui, à partir du moment où l'on prend en compte les points entraînant cet état de fait (langage permissif, typage faible et dynamique, opération portant uniquement sur des entiers, et non-levée d'exceptions quand elles sont évitables. Partant de ces différents points, quel autre comportement que celui-ci proposerais-tu ?)

>>> 'a'+2
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Can't convert 'int' object to str implicitly

Ça, c’est un comportement civilisé. Passer un truc comme ça sous silence, c’est criminel et ça ne se justifie jamais.

ArkSeth a écrit :

Pylade a écrit :
Un caractère est un entier, donc pas de raison de reprocher quoi que se soit. Et non, on ne peut pas se servir d’un pointeur comme d’un entier comme si de rien n’était, en tous cas avec un compilateur civilisé (et si on peut passer outre les warnings, c’est seulement car le pointeur est aussi un nombre, à la base). En revanche on peut faire de l’arithmétique des pointeurs, mais c’est justement car le pointeur n’est pas casté en entier.
Un caractère est un entier en C. En PHP, un entier est une chaîne de caractères. Ces deux choses ne sont pas plus ou moins évidentes l'une que l'autre : ce sont simplement les spécifications du langage (et l'habitude d'utiliser ce langage) qui les rendent normales ou anormales.

Le seul autre langage que je connaisse où le entiers sont des chaînes, c’est le shell. Et encore, pas tout à fait, on demande explicitement de comparer des chaînes en temps qu’entier. Là, c’est un comportement sain. Sinon, WTF, c’est impossible de coder correctement.
Au fait, remarque que le fait que la chaîne vaille 0 est induit par la même mécanisme que le support accidentel de l’octal. Et je n’ai pas essayé, mais je jurerais qu’une chaîne du style "\t \n 3plop" donnera 3…

ArkSeth a écrit :

Je n'active peut-être pas autant de warnings que toi, mais je crois n'avoir encore jamais rencontré de compilation qui râlait parce que j'ai tapé ptr + i. C'est la base du fonctionnement des tableaux, d'additionner des pointeurs avec des entiers, et pourtant, sur le principe, ce n'est pas moins aberrant que d'additionner des entiers avec des chaînes de caractères (au lieu de prendre des choux et des tomates, on prend des choux et des concombres, mais ça reste une addition de légumes différents).

C’est défini dans le langage ; c’est de l’arithmétique des pointeurs. Ça a un sens. Et en plus, c’est vraiment efficace. Essaie de faire la multiplication entre un entier et un pointeur, là le compilo va râler.

ArkSeth a écrit :

Sinon, sur les affaires de casts automatiques, on peut aussi considérer les pointeurs sur un type qui peuvent devenir des pointeurs sur un autre type « comme par magie » (c'est vous qui m'avez fait remarquer qu'il n'y avait pas besoin de caster le résultat d'un malloc, par exemple).

Ben c’est normal, si t’utilise un pointeur générique. C’est le rôle de void*, être un type de pointeurs génériques. Et cela est plus que convenable lorsque l’on parle d’une fonction comme malloc.

ArkSeth a écrit :

Pylade a écrit :
Ce n’est pas hyper joli non plus le JavaScript, mais PHP ce n’est pas que le langage, c’est le langage plus l’interpréteur (comme Python, par exemple), sinon il ne supporterait pas l’octal par accident.
Ç'pas un langage privatif non plus, hein : certes, il y a un interpréteur « de référence », mais rien n'empêche d'en coder un autre. Et si tu en codes un autre et qu'il est mieux que l'autre, il est même possible que le tien devienne plus utilisé.

Pas quand t’as des tas de codes et tous les codeurs PHP qui se reposent sur les comportements étranges de l’interpréteur de référence, non.

ArkSeth a écrit :

Dire qu'un truc est mal pensé parce qu'il y a un problème dans son implémentation, c'est juste de la mauvaise foi : le fait que ce problème existe sur l'interpréteur php est effectivement un mauvais point (encore que, je le répète, même si je vous crois sur parole sur le fait que ça arrive, j'aimerais quand même bien avoir un peu plus de précisions sur les cas dans lesquels ça arrive). mais ça ne peut pas, honnêtement, être considéré comme un problème du langage PHP.

Je ne fais pas d’idéologie, je dis juste que PHP, en temps que solution, souffre de tellement de problème qu’il ne devrait pas être utilisé.

ArkSeth a écrit :

Pylade a écrit :
Par exemple, en C, l’ordre des argument de f* versus fscanf et fprintf ; ça c’est inconsistant.
…ce qui ne me renseigne pas le moins du monde sur le sens de ce mot, mais bon ^^

Ben t’as deux fonctions aberrantes qui prennent le FILE* en premier, c’est tout. C’est juste un exemple, hein, je ne suis pas un dictionnaire.

ArkSeth a écrit :

Pylade a écrit :
Désolé, mais PHP et code propre ou sérieux, c’est incompatible.
Désolé, mais PHP et code propre ou sérieux selon Pylade, c'est incompatible.
Et comme dans les critères de propreté et de sérieux de Pylade, il y a en toutes lettres « pas PHP », bah, dire ça ne sert juste à rien.
Propre et sérieux, c'est tout ce qu'il y a de plus subjectif, comme notion.
Bref, voilà, quoi : le langage PHP est loin d'être parfait, présente quelques problèmes, et ressemble sans doute plus à un gros bricolage qu'à un truc bien pensé, mais tout de même, les trois quarts de vos dénigrements sont juste des avis purement subjectifs ou de la mauvaise foi (parce que vous ne reprocheriez pas les mêmes choix faits dans d'autres langages qui vous plaisent plus). Reconnaissez-le, au moins

Ben, non, je ne vois pas en quoi.

Mais avec tous les problèmes dont on parle, tu ne trouves pas que ça fait un peu beaucoup pour que l’on fasse confiance à ce langage qui en plus n’a jamais eu vocation à permettre de faire des choses propres ?

ArkSeth a écrit :

[…]
Arf… courage. J'propose qu'on arrête de troller sur PHP (voire même sur d'autres langages) jusqu'à ce que tshirtman ait fini son rapport ^^

C’pas juste, je viens de faire une grosse réponse. Il n’a qu’à pas répondre, voilà !

Dernière modification par Pylade (Le 15/06/2011, à 03:35)

grim7reaper · Le 15/06/2011, à 05:52

Hello World!

Hé béh, successful troll is successful ^^"

Pylade a écrit :

que les gens qui veulent faire du code propre ne devraient pas utiliser PHP…

Encore une fois, source !?
C'est pas dans mon lien en tout cas.
Y'a suffisemment de citation à l'encontre de PHP pour que tu n'ais pas à en inventer en plus…

tshirtman a écrit :

et moi avec toutes ces lectures (a cause de stackoverflow, je suis partis loin), c'est mon rapport qui n'a pas avancé, pour dans 10 jours même pas, et qui est à 1/30eme de l'avancement >_<.

Ha tiens, moi aussi j'ai un rapport à commencer…

Compteur du TdCCT · Le 15/06/2011, à 06:42

Scores totaux, depuis le début :

1) 3507    nesthib
2) 3114    samuncle
3) 2973    Pylade
4) 2225    Кຼزດ
5) 1716    cm-t
6) 1711+5  grim7reaper /* ./viewtopic.php?pid=3486252#p3486252 */
7) 1326    na kraïou
8) 866    helly
9) 862    \\Ouranos//
10) 659    gnuuat
11) 621    tshirtman
12) 565    Lagierl
13) 429    Rolinh
14) 388    nathéo
15) 372    The Uploader
16) 263    Kanor
17) 196    Askelon
18) 193    :!pakman
19) 121    ǤƦƯƝƬ
20) 99    kamui57
21) 93    petifrancais
22) 78    edge_one
22) 78    pierguiard
24) 70    gulp
25) 42    sakul
26) 39    Le Rouge
27) 37    ilagas
28) 36    xapantu
29) 30    keny
30) 26    gustare
30) 26    d10g3n
32) 25    GentooUser
32) 25    Morgiver
34) 24    ไ୦บเઢ'
34) 24    Steap
36) 20    CROWD
37) 18    Ph3nix_
38) 16    kouskous
39) 15    timsy
40) 12    stratoboy
40) 12    sailing
42) 11    alexises
42) 11    Crocoii
44) 10    Toineo
44) 10    NutMotion
44) 10    pseudovingtcinqcaracteres
44) 10    pfriedZ
44) 10    CasseTaTele
44) 10    Zeibux
44) 10    THS`
51) 8    Mornagest
52) 7    Vista
53) 6    ubuntlin
53) 6    asma.geek
55) 5    tendances-tdct
55) 5    kinouchou
57) 4    danychou56
57) 4    Neros
57) 4    Biaise
57) 4    totoflute
57) 4    pinballyoda ㋛
57) 4    NLS le pingouin
57) 4    ceric
57) 4    Dice-Man
65) 3    Revan26914
65) 3    raspouillas
65) 3    sweetly
68) 2    SoJaS
69) 1    geenux
69) 1    ArzhurBZH

Répartition Posts/heure

Compteur du TdCCT · Le 15/06/2011, à 06:42

Scores de la période en cours :

1) 130    Pylade
2) 103    nesthib
3) 79    cm-t
4) 73    Кຼزດ
5) 71    samuncle
6) 48    tshirtman
7) 47    na kraïou
8) 40    nathéo
9) 27    :!pakman
10) 24    The Uploader
11) 18    grim7reaper
12) 10    Rolinh
13) 4    \\Ouranos//
13) 4    kamui57
15) 3    xapantu

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#226 Le 14/06/2011, à 21:39

Re : /* Topic des codeurs couche-tard [5] */

#227 Le 14/06/2011, à 21:40

Re : /* Topic des codeurs couche-tard [5] */

#228 Le 14/06/2011, à 23:05

Re : /* Topic des codeurs couche-tard [5] */

#229 Le 14/06/2011, à 23:11

Re : /* Topic des codeurs couche-tard [5] */

#230 Le 14/06/2011, à 23:19

Re : /* Topic des codeurs couche-tard [5] */

#231 Le 14/06/2011, à 23:20

Re : /* Topic des codeurs couche-tard [5] */

#232 Le 14/06/2011, à 23:35

Re : /* Topic des codeurs couche-tard [5] */

#233 Le 14/06/2011, à 23:44

Re : /* Topic des codeurs couche-tard [5] */

#234 Le 14/06/2011, à 23:55

Re : /* Topic des codeurs couche-tard [5] */

#235 Le 14/06/2011, à 23:59

Re : /* Topic des codeurs couche-tard [5] */

#236 Le 15/06/2011, à 00:17

Re : /* Topic des codeurs couche-tard [5] */

#237 Le 15/06/2011, à 00:32

Re : /* Topic des codeurs couche-tard [5] */

#238 Le 15/06/2011, à 00:55

Re : /* Topic des codeurs couche-tard [5] */

#239 Le 15/06/2011, à 01:11

Re : /* Topic des codeurs couche-tard [5] */

#240 Le 15/06/2011, à 01:45

Re : /* Topic des codeurs couche-tard [5] */

#241 Le 15/06/2011, à 01:52

Re : /* Topic des codeurs couche-tard [5] */

#242 Le 15/06/2011, à 01:57

Re : /* Topic des codeurs couche-tard [5] */

#243 Le 15/06/2011, à 02:01

Re : /* Topic des codeurs couche-tard [5] */

#244 Le 15/06/2011, à 02:02

Re : /* Topic des codeurs couche-tard [5] */

#245 Le 15/06/2011, à 02:06

Re : /* Topic des codeurs couche-tard [5] */

#246 Le 15/06/2011, à 02:06

Re : /* Topic des codeurs couche-tard [5] */

#247 Le 15/06/2011, à 03:34

Re : /* Topic des codeurs couche-tard [5] */

#248 Le 15/06/2011, à 05:52

Re : /* Topic des codeurs couche-tard [5] */

#249 Le 15/06/2011, à 06:42

Re : /* Topic des codeurs couche-tard [5] */

#250 Le 15/06/2011, à 06:42

Re : /* Topic des codeurs couche-tard [5] */

Pied de page des forums