go

Le 28-11-2009, ? propos de
Re: go,
Stephane TOUGARD ?crivait dans fr.comp.os.linux.debats :

JKB wrote:

... Si pour éviter des constructions
de structures conditionnelles tu es contraint à l'utilisation du goto,
c'est que ton code a un sérieux problème de conception.

Ah, ca y est, le grand maitre du code et de la raison universelle a parle.

Puisque tu es un grand defenseur des grandes choses et un grand
attaquants des mauvaises. J'ai voulu voir si les grandes choses en
faisaient des mauvaises :

$ pwd
/home/stephane/tmp/sendmail-8.14.3
$ grep -R goto *|wc
525 1686 19080

Ensuite, j'ai voulu savoir qui etait le plus coupable

$ pwd
/home/stephane/tmp/qmail-1.03
$ grep -R goto *|wc
38 268 2504

En tous cas, il semble que qmail ai environ 15 fois moins de "problemes
de conception" que sendmail ... environ. Tout ca pour arriver a un
objectif similaire (etre un MX).

Tu es vraiment un crétin sans bornes. Rapporte simplement le nombre
de gotos à la longueur des sources et tu verras que qmail a
proportionnellement deux fois plus de goto que sendmail. De toute
façon, le problème n'est pas là. Sendmail est un programme
historique qui contient pas mal de code ancien datant de l'époque où
le goto était classiquement utilisé en serait-ce que parce qu'il
permet de raccourcir le code. Qmail n'a jamais eu cette contrainte
et aurait pu être écrit sans aucun goto.

Au fait :

cauchy:[~/rpl/rpl-4.0.7/src] > grep -R goto *|wc
0 0 0
cauchy:[~/rpl/rpl-4.0.7/src] > du -hs
7,2M .
cauchy:[~/rpl/rpl-4.0.7/src] > wc
...
237490 633908 6958635 total
cauchy:[~/rpl/rpl-4.0.7/src] >

donc on arrive à coder sans aucun goto et sans complexifier le code.

J'attends aussi l'argument du "le goto, ça évite au programme de
gérer la pile en passant d'un point à un autre d'une routine", parce

Bof, pour moi le goto ca sert simplement a ce que j'ai deja dit : eviter
des if imbriques les uns dans les autres a en rendre le programme
illisible.

Il me semble d'ailleurs que malgre qu'un tas d'andouilles le considerent
salement, c'est une instruction dont on ne saurait se passer des qu'un
projet depasse une certaine taille et une certaine complexite.

Mouarf... Celle-là, je l'encadre.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

JKB a écrit :

Et tu appelles ça comment ?

Je dirais un traducteur de C vers pascal. P2c fait une analyse lexicale,
une analyse syntaxique et gère une table de symbole. Je trouve c'est
beaucoup pour un simple préprocesseur au minimum on est plus du tout au
niveau de préprocesseur comme cpp ou m4.

Le problème est qu'on utilise un langage ou un autre en fonction du
résultat. Rendre le C strict est une connerie parce que ça empêche
de faire certaines choses. Rendre ADA moins strict est une autre
connerie parce qu'il a justement été conçu pour d'autres choses.

Donc le C aurait du être réservé aux domaines ou ces certaines choses
(des bidouilles ;-) ) sont indipensables.

JKB wrote:

Tu es vraiment un crétin sans bornes. Rapporte simplement le nombre
de gotos à la longueur des sources et tu verras que qmail a
proportionnellement deux fois plus de goto que sendmail. De toute
façon, le problème n'est pas là. Sendmail est un programme
historique qui contient pas mal de code ancien datant de l'époque où
le goto était classiquement utilisé en serait-ce que parce qu'il
permet de raccourcir le code. Qmail n'a jamais eu cette contrainte
et aurait pu être écrit sans aucun goto.

Jusqu'ou ira la mauvaise foi de JKB.

En ce qui me concerne, les deux sont des MX et les deux font la meme
chose au final. Le fait que Qmail soit plus petit serait plutot a son
avantage.

donc on arrive à coder sans aucun goto et sans complexifier le code.

Sans complexifier le code, il y a que toi pour le dire.

Il me semble d'ailleurs que malgre qu'un tas d'andouilles le considerent
salement, c'est une instruction dont on ne saurait se passer des qu'un
projet depasse une certaine taille et une certaine complexite.

Mouarf... Celle-là, je l'encadre.

On le trouve absolument partout, jusque dans le noyau Linux.

Le tout etant de l'utiliser intelligement et lorsqu'il apporte quelque
chose et non pas comme un goret. Vouloir ne pas l'utiliser du tout,
juste par principe est tout simplement aussi stupide que de l'employer a
tort et a travers.

Mais il va falloir que tu commences a penser autrement que 0 ou 1 pour
comprendre ce mode de pensee. Le plus surprenant, c'est qu'a ton age et
malgre ta grande experience, tu n'y sois toujours pas arrive.

Le Sat, 28 Nov 2009 21:09:38 +0100, Richard Delorme a écrit:

Ahahahahaha....

http://www.cs.bell-labs.com/cm/cs/cstr/100.ps.gz

Très intéressant, qu'est ce qu'il en est aujourd'hui? Est ce qu'il y a
toujours les mêmes problèmes?

--
La loi, dans un grand souci d'égalité, interdit aux riches comme aux
pauvres de coucher sous les ponts, de mendier dans les rues et de voler
du pain.
Anatole France.

Le 29-11-2009, ? propos de
Re: go,
batyann811 ?crivait dans fr.comp.os.linux.debats :

JKB a écrit :

Et tu appelles ça comment ?

Je dirais un traducteur de C vers pascal. P2c fait une analyse lexicale,
une analyse syntaxique et gère une table de symbole. Je trouve c'est
beaucoup pour un simple préprocesseur au minimum on est plus du tout au
niveau de préprocesseur comme cpp ou m4.

Je ne me suis jamais penché sur ce truc parce que je n'ai jamais eu
à compiler du Pascal sous Linux. Par contre sous SunOS, j'ai fait ce
genre de sport. Je te prie de croire que tu peux parfaitement
compiler un source Pascal à partir d'un préprocesseur un tant soit
peu évolué (cpp n'entre pas dans cette catégorie). Si je retrouve le
QIC 60 qui contient l'outil en question (et si j'ai encore un
lecteur opérationnel), je te filerai le soft. C'était un truc fait
maison à partir de m4 et ça te convertissait directement ton source
Pascal en source C.

Le problème est qu'on utilise un langage ou un autre en fonction du
résultat. Rendre le C strict est une connerie parce que ça empêche
de faire certaines choses. Rendre ADA moins strict est une autre
connerie parce qu'il a justement été conçu pour d'autres choses.

Donc le C aurait du être réservé aux domaines ou ces certaines choses
(des bidouilles ;-) ) sont indipensables.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

Le 29-11-2009, ? propos de
Re: go,
Stephane TOUGARD ?crivait dans fr.comp.os.linux.debats :

JKB wrote:

Tu es vraiment un crétin sans bornes. Rapporte simplement le nombre
de gotos à la longueur des sources et tu verras que qmail a
proportionnellement deux fois plus de goto que sendmail. De toute
façon, le problème n'est pas là. Sendmail est un programme
historique qui contient pas mal de code ancien datant de l'époque où
le goto était classiquement utilisé en serait-ce que parce qu'il
permet de raccourcir le code. Qmail n'a jamais eu cette contrainte
et aurait pu être écrit sans aucun goto.

Jusqu'ou ira la mauvaise foi de JKB.

En ce qui me concerne, les deux sont des MX et les deux font la meme
chose au final. Le fait que Qmail soit plus petit serait plutot a son
avantage.

Réponds à la question. Tu viens de montrer que tu ne sais pas faire
une règle de trois de base.

donc on arrive à coder sans aucun goto et sans complexifier le code.

Sans complexifier le code, il y a que toi pour le dire.

Non. Parce que lorsque tu dois débugguer un truc avec des gotos, il
te faudrait aussi le pendant (le comefrom) pour éviter le côté
spaghetti du code. C'est aussi pour cela qu'on évite le goto et
qu'on le réserve seulement aux cas où on ne peut pas faire
autrement.

Il me semble d'ailleurs que malgre qu'un tas d'andouilles le considerent
salement, c'est une instruction dont on ne saurait se passer des qu'un
projet depasse une certaine taille et une certaine complexite.

Mouarf... Celle-là, je l'encadre.

On le trouve absolument partout, jusque dans le noyau Linux.

Je n'ai jamais dis le contraire. Je prétends seulement (et tu n'as
encore aucun argument contre) que le goto n'est pas utile dans
l'immense majorité des cas. Je t'ai aussi dit qu'historiquement, ça
pouvait tout à fait se justifier pour des vieux programmes, mais
certainement pas pour des écritures récentes dans lesquelles entre
qmail.

Il est parfaitement normal qu'il soit utilisé dans un noyau d'OS (je te
laisse réfléchir au pourquoi du comment), mais je persiste à dire
que dans une application normale, il n'a rien à faire. Utiliser un
goto dans une application normale (ie pas un noyau) revient dans
l'immense majorité des cas à dire que son design est défectueux.
Pour te fixer un peu les idées et enfoncer le clou, le recours à
un goto signifie quasiment toujours que tu essaies de récupérer un
cas que tu as oublié de traiter, c'est un cataplasme sur une jambe
de bois. NOTE BIEN QUE J'AI ÉCRIT QUASIMENT TOUJOURS. Je le mets en
majuscules parce que ta comprenette est bouchée à l'émeri.

De toute façon, je parle à un mur, parce parler de programmation
noyau avec toi, c'est un peu discuter sur la vertu du point-virgule
dans les Pensées de Pascal avec une mouette.

Le tout etant de l'utiliser intelligement et lorsqu'il apporte quelque
chose et non pas comme un goret. Vouloir ne pas l'utiliser du tout,
juste par principe est tout simplement aussi stupide que de l'employer a
tort et a travers.

Mais il va falloir que tu commences a penser autrement que 0 ou 1 pour
comprendre ce mode de pensee. Le plus surprenant, c'est qu'a ton age et
malgre ta grande experience, tu n'y sois toujours pas arrive.

Ce que tu n'arrives pas à comprendre (mais vu ta mentalité, c'est
presque normal), c'est qu'on peut parfaitement se passer du goto et
que le fait de ne pas l'employer n'est pas du tout synonyme de ne
pas l'employer par principe.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

Emmanuel Florac :

http://www.cs.bell-labs.com/cm/cs/cstr/100.ps.gz

Très intéressant, qu'est ce qu'il en est aujourd'hui? Est ce qu'il y a
toujours les mêmes problèmes?

La plupart des points me semble obsolètes. J'ai fais pas mal de delphi
et ça doit être la seule implémentation qui a survécu (avec FreePascal
qui est plus ou moins compatible avec delphi).

Concernant les strings, le vieux type pascal n'est plus utilisé depuis
belle lurette. Les chaînes sont complétement dynamiques.

Pour le typage des tableaux, c'est toujours vrai mais on peut utiliser
des tableaux dynamique sans taille fixe.

Le typage fort est toujours là, par exemple j'ai été confronté à la
conversion de deux entiers 16 bits venant d'une trame sur une liaison
série vers un flottant IEEE je ne sais plus combien. Bref c'est
impossible, il faut passer par un hack :
flotant: real;
entier : dword absolute flotant;

Ce qui veut dire que entier est à la même adresse que flotant, et on
peut travailer sur entier (impossible de faire des décalage, &, sur un
flotant...). C'est particulièrement laid...

Concernant les variables d'itération dans une boucle for, c'est toujours
vrai, elles sont indéfinies en dehors de la boucle.

Je crois qu'il y a un "default" sur le case et un "break" (mon pascal
est rouillé).

Les gros reproches que j'ai vis à vis du pascal moderne "Object Pascal"
comme ils disent c'était l'absence de généricité et la pauvreté des
conteneurs. Ainsi qu'une gestion de la création et destruction des
objets manuelle et très pénible.

De toutes façons c'est mort...

Le Sun, 29 Nov 2009 14:37:07 +0100, Patrick Lamaizière a écrit:

Les gros reproches que j'ai vis à vis du pascal moderne "Object Pascal"
comme ils disent c'était l'absence de généricité et la pauvreté des
conteneurs. Ainsi qu'une gestion de la création et destruction des
objets manuelle et très pénible.

De toutes façons c'est mort...

Il faut dire que les défauts restants font quand même peur.



--
My assertion that we can do better with computer languages is a
persistent belief and fond hope, but you'll note I don't actually claim
to be either rational or right. Except when it's convenient.
Larry Wall

JKB wrote:

Réponds à la question. Tu viens de montrer que tu ne sais pas faire
une règle de trois de base.

Quelle question ?

Je n'ai vu aucune question dans ton post.

Non. Parce que lorsque tu dois débugguer un truc avec des gotos, il
te faudrait aussi le pendant (le comefrom) pour éviter le côté
spaghetti du code. C'est aussi pour cela qu'on évite le goto et
qu'on le réserve seulement aux cas où on ne peut pas faire
autrement.

Oh ben voila, il commence a comprendre le JKB. Il y a pas que des 0 et
des 1 dans la vie. Il y aussi des moments ou utiliser goto est
necessaire et meilleur que n'importe quelle autre solution (car on peut
toujours faire autrement).

Je n'ai jamais dis le contraire. Je prétends seulement (et tu n'as
encore aucun argument contre) que le goto n'est pas utile dans
l'immense majorité des cas. Je t'ai aussi dit qu'historiquement, ça
pouvait tout à fait se justifier pour des vieux programmes, mais
certainement pas pour des écritures récentes dans lesquelles entre
qmail.

Ca, c'est de la mauvaise foi. Mais c'est bien, tu progresses, tu as
admis qu'il y a des raisons pour les quelles on peut (et on doit)
utiliser goto.

Il est parfaitement normal qu'il soit utilisé dans un noyau d'OS (je te
laisse réfléchir au pourquoi du comment), mais je persiste à dire
que dans une application normale, il n'a rien à faire. Utiliser un
goto dans une application normale (ie pas un noyau) revient dans
l'immense majorité des cas à dire que son design est défectueux.

Donc le design de sendmail est defectueux. Vois-tu, je ne suis pas
d'accord sur le cote historique de ton argumentation. Sendmail est Libre
et Open Source. Si goto c'est mal, on passe quelques jours sur le
probleme et on le vire du code.

Si on le laisse, c'est bien qu'il y a de bonnes raisons.

Maintenant, je peux faire le tour des tous les gros projets en C du GNU,
je suis a peu pret sur de trouver du goto en pagaille dans la plupart
d'entre eux. Tout simplement parce qu'il y des fois ou goto, c'est bien.

Pour te fixer un peu les idées et enfoncer le clou, le recours à
un goto signifie quasiment toujours que tu essaies de récupérer un
cas que tu as oublié de traiter, c'est un cataplasme sur une jambe
de bois. NOTE BIEN QUE J'AI ÉCRIT QUASIMENT TOUJOURS. Je le mets en
majuscules parce que ta comprenette est bouchée à l'émeri.

C'est pour ca qu'a chaque fois que je vois des goto, ils sont toujours
dans des series de conditions et pointent tous vers un point unique.

Houla, merci JKB pour tes lecons de programmation, mais je crois que je
vais faire sans. Pas que tu sois mauvais, mais ta mauvaise foi te fait
dire des betises.

De toute façon, je parle à un mur, parce parler de programmation
noyau avec toi, c'est un peu discuter sur la vertu du point-virgule
dans les Pensées de Pascal avec une mouette.

Je ne fais pas de programmation noyau et on ne parle pas de
programmation du noyau. On parle de l'utilisation de goto et dans le
fait que cela se justifie dans certains cas. Ce sur quoi on est presque
d'accord. T'as juste a essayer de trouver un echapatoire pour bien dire
que t'as une plus grosse bite, bien que le coup de la "programmation
noyau avec toi" devrait etre suffisant.

Ce que tu n'arrives pas à comprendre (mais vu ta mentalité, c'est
presque normal), c'est qu'on peut parfaitement se passer du goto et
que le fait de ne pas l'employer n'est pas du tout synonyme de ne
pas l'employer par principe.

C'est surtout le fait que l'employer n'est pas synonyme de "mauvais
design". C'est l'employer a tort et a travers ou pas du tout lorsque
cela est necessaire qui est synonyme de mauvais design.

Le 29-11-2009, ? propos de
Re: go,
Stephane TOUGARD ?crivait dans fr.comp.os.linux.debats :

JKB wrote:

Réponds à la question. Tu viens de montrer que tu ne sais pas faire
une règle de trois de base.

Quelle question ?

Celle que tu as judicieusement viré et qui concernait ta comparaison
foireuse entre le nombre de goto présents dans sendmail et dans
qmail.

Je n'ai vu aucune question dans ton post.

Elle était dans le tien. Tu ne sais même plus ce que tu écris, ça
devient franchement grave.

Non. Parce que lorsque tu dois débugguer un truc avec des gotos, il
te faudrait aussi le pendant (le comefrom) pour éviter le côté
spaghetti du code. C'est aussi pour cela qu'on évite le goto et
qu'on le réserve seulement aux cas où on ne peut pas faire
autrement.

Oh ben voila, il commence a comprendre le JKB. Il y a pas que des 0 et
des 1 dans la vie. Il y aussi des moments ou utiliser goto est
necessaire et meilleur que n'importe quelle autre solution (car on peut
toujours faire autrement).

Tu es vraiment le roi des <censure>. Tu ne comprends même pas ce
qu'on te dit lorsque ça ne va pas dans le même sens que celui de ta
vision étriquée.

Je n'ai jamais dis le contraire. Je prétends seulement (et tu n'as
encore aucun argument contre) que le goto n'est pas utile dans
l'immense majorité des cas. Je t'ai aussi dit qu'historiquement, ça
pouvait tout à fait se justifier pour des vieux programmes, mais
certainement pas pour des écritures récentes dans lesquelles entre
qmail.

Ca, c'est de la mauvaise foi. Mais c'est bien, tu progresses, tu as
admis qu'il y a des raisons pour les quelles on peut (et on doit)
utiliser goto.

Je n'ai admis qu'une seule chose et manque de chance pour toi, ce
n'est pas celle que tu essayes de comprendre. Boote-toi un second
neurone, ça t'aidera.

Il est parfaitement normal qu'il soit utilisé dans un noyau d'OS (je te
laisse réfléchir au pourquoi du comment), mais je persiste à dire
que dans une application normale, il n'a rien à faire. Utiliser un
goto dans une application normale (ie pas un noyau) revient dans
l'immense majorité des cas à dire que son design est défectueux.

Donc le design de sendmail est defectueux.

Tu as encore compris la moitié de ce que j'ai écrit. Relis-moi
attentivement.

Vois-tu, je ne suis pas
d'accord sur le cote historique de ton argumentation. Sendmail est Libre
et Open Source. Si goto c'est mal, on passe quelques jours sur le
probleme et on le vire du code.

On ne change pas un truc qui est éprouvé parce qu'à une certaine
époque, on utilisait des goto pour limiter la longueur des codes
sources et leur complexité pour rentrer dans la mémoire étriquée des
machines de l'époque. Quand un truc fonctionne et qu'on n'a pas a y
toucher, il faut une sérieuse raison pour le modifier. Par ailleurs,
le 'quelques jours' prouve que tu n'as jamais été confronté à de la
réécriture de code. Ce ne sont pas quelques jours, mais au mieux
quelques semaines parce qu'il faut y inclure la validation. Enfin,
venant d'un bricoleur...

Si on le laisse, c'est bien qu'il y a de bonnes raisons.

Ouaips, le fait qu'il n'y a aucune raison de changer un truc qui
fonctionne. Que tu ne vois pas la différence entre un vieux code et
les contraintes de l'époque de sa jeunesse et un truc écrit à partir
de rien, c'est assez dramatique.

Maintenant, je peux faire le tour des tous les gros projets en C du GNU,
je suis a peu pret sur de trouver du goto en pagaille dans la plupart
d'entre eux. Tout simplement parce qu'il y des fois ou goto, c'est bien.

Non, ce n'est _pas_ bien. Et ce n'est pas parce qu'il y en a en
pagaille un peu partout que c'est bien. Je te mets d'ailleurs au
défi de débugguer un truc qui merdoie lorsque tu as des goto
partout (surtout en multithreadé, parce que là...).

Pour te fixer un peu les idées et enfoncer le clou, le recours à
un goto signifie quasiment toujours que tu essaies de récupérer un
cas que tu as oublié de traiter, c'est un cataplasme sur une jambe
de bois. NOTE BIEN QUE J'AI ÉCRIT QUASIMENT TOUJOURS. Je le mets en
majuscules parce que ta comprenette est bouchée à l'émeri.

C'est pour ca qu'a chaque fois que je vois des goto, ils sont toujours
dans des series de conditions et pointent tous vers un point unique.

Va jusqu'au bout de ton raisonnement et tu verras que c'est
justement l'utilisation du goto la plus mauvaise qui soit. Je ne
vais pas essayer de t'expliquer, il me faudrait beaucoup trop de temps,
tu prendras une éternité pour comprendre et je n'en ai pas la patience.

Houla, merci JKB pour tes lecons de programmation, mais je crois que je
vais faire sans. Pas que tu sois mauvais, mais ta mauvaise foi te fait
dire des betises.

Je n'ai pas de leçon de programmation à recevoir d'un type comme
toi. D'ailleurs, je n'essaie pas non plus de t'en donner parce que
le boulot serait énorme. Je ne parle pas de leçon de programmation
pour bricoler un petit script en perl dans un coin, mais pour coder
des applications sérieuses.

De toute façon, je parle à un mur, parce parler de programmation
noyau avec toi, c'est un peu discuter sur la vertu du point-virgule
dans les Pensées de Pascal avec une mouette.

Je ne fais pas de programmation noyau et on ne parle pas de
programmation du noyau. On parle de l'utilisation de goto et dans le
fait que cela se justifie dans certains cas. Ce sur quoi on est presque
d'accord.

Non, on n'est pas d'accord. Tu justifies l'utilisation du goto, je
prétends que le goto est une verrue dans les applications normales
et ne se justifie que dans des applications noyau pour des raisons
totalement différentes.

T'as juste a essayer de trouver un echapatoire pour bien dire
que t'as une plus grosse bite, bien que le coup de la "programmation
noyau avec toi" devrait etre suffisant.

C'est toi qui prétends toujours avoir la plus grosse et tu m'amuses.
Tu ne peux pas savoir à quel point (chez toi, c'est pavlovien, on
dirait même que tu es un clone d'Averelll). Tu n'arrives pas à
imaginer la différence de programmation entre une application
utilisateur et un bout de noyau ni ce que ça implique (au moins en
terme de branchements et de sauts), il n'y donc même pas matière à
continuer. À moins que tu veuilles encore t'enfoncer et passer pour
un charlot ?

Ce que tu n'arrives pas à comprendre (mais vu ta mentalité, c'est
presque normal), c'est qu'on peut parfaitement se passer du goto et
que le fait de ne pas l'employer n'est pas du tout synonyme de ne
pas l'employer par principe.

C'est surtout le fait que l'employer n'est pas synonyme de "mauvais
design". C'est l'employer a tort et a travers ou pas du tout lorsque
cela est necessaire qui est synonyme de mauvais design.

Parfait, si c'est ce que tu crois. Reste à ce niveau de
compréhension, ça évitera de te remettre en cause. Passer pour un
charlot à ses propres yeux, c'est vraiment dur.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.