D'une manière générale, il est difficile de pas troller lorsque l'on évoque feu Edsger Dijkstra.
Je sais que tu postes cela pour mon bien mais je fais partie des gens qui n'adhèrent pas automatiquement à ses idées (et je ne suis pas le seul si l'on en croit cette célèbre citation extraite de kernel/sched.c : http://www.coda.cs.cmu.edu/doc/talks/linuxvfs/tsld031.htm ). La discussion était d'ailleurs déjà très animée il y a trois ans :
Je reproche majoritairement deux choses aux disciples de Dijkstra :
1) Tuer dans l'oeuf tout risque de discussion en assénant des vérités toutes faites du style : « It is practically impossible to teach good programming to students that have had a prior exposure to BASIC; as potential programmers they are mentally mutilated beyond hope of regeneration. ». Dijkstra devrait être au quotidien un type pas du tout facile à vivre et ne devait pas aimer que l'on remette en cause ses théories :-)
Aujourd'hui, les gens qui le suivent considèrent les gens qui soutiennent toute théorie « déviante » comme étant nécessairement sots, ou au mieux dans l'ignorance. Cela me rappelle un peu Dan, le scientifique illogique :-)
Quand on en arrive à de telles extrémités, c'est en général par manque de pertinence de l'argumentation.
2) Raisonner de manière essentiellement mathématique. J'entends par là : tenter d'appliquer le modèle de raisonnement et l'analyse des problèmes traditionnels à l'informatique. Il faut bien se rendre compte qu'algorithmie et programmation sont deux domaines sensiblement différents et que ce n'est pas parce Dijkstra a brillament résolu le problème du colporteur que la manière dont il va l'implémenter va être propre.
bien souvent l'essentiel des bugs sont sur des effet de bord dans des conditions mal traitée ou pas traitées du tout. dans la liste on trouve :
- mauvaise gestion du malloc()/free()
- mauvaise gestion des IPC
- explosion d'etat interdependant car le code ne permet de faire autrement dans le delai imparti ( car sinon faut tout recoder )
... et Dieu tue un chaton aussi. Ces exemples sont les problèmes classiques récurrents de la programmation système. On les attribue à toutes les causes possibles et imaginables quand on a envie de se faire le détracteur d'une méthode particulière.
On ne doit pas imbriquer nos if() de la même manière car moi, au contraire, je tiens cette méthode pour être la plus élégante façon de résoudre ces problèmes, spécialement ceux des malloc(). C'est même la seule chose qui me réconcilie un peu avec Dijkstra. La sacro-sainte programmation structurée ne trouve sa réelle signification que sous cette forme. Tout ce qui est conditionné par un if() doit se trouver à l'intérieur.
Il y a belle lurette que grâce à cela, je n'utilise plus exit() et qu'il n'y a qu'un seul return, toujours à la fin de mes fonctions.
si on regarde bien, il n'y a là dedans que des erreurs de conceptions ou d'implementation. ce qui m'amene a une regle que j'enonce ainsi :
- tout programme ou bout de programme dont la couverture en condition est superieur à 5 tends necessairement à être buggé
Moi, j'en assène une autre, attribuée à Euclide de Mégare et qui orne le portail mathématique du Wikipédia français :
« Ce qui est affirmé sans preuve peut être nié sans preuve »
Quant à la lisibilité, l'important est de garder de la cohérence tout au long de son propre code. Le reste n'est qu'affaire de subjectivité. Il y a de fortes chances pour qu'un code lisible selon tes critères soit parfaitement obscur pour quelqu'un d'autre. Moi, je pense que lorsque l'on est trop à cheval sur la forme, c'est que l'on ne l'est pas assez sur le fond.
si tu as un doute, reprends le propos de dijkstra sur les goto
Ben voyons, je parle de if() imbriqués et tu me parles de gotos ? Comme je le dis au dessus, il me semble que l'inclusion des différentes routines est justement le meilleur moyen de s'en débarrasser. Sémantiquement parlant, un analyseur de code (autre grand sujet de troll et d'étude en algorithmie) sera immédiatement capable de reconnaitre si un bloc d'instruction est dépendant d'un if() ou pas. Si on les remet à plat, on perd cette possibilité.
Aujourd'hui, il faut necessairement comprendre le propos de Dijkstra comme les conditions prealable au goto sont a eviter.
Oui, mais ce n'est pas suffisant. Il faut également le saisir de la manière dont il a voulu l'exprimer. Jamais un troll en informatique n'aura été si proche d'une guerre de religion. Dijkstra était déjà un fondamentaliste, mais la plupart des intégristes interprètent aujourd'hui ses propos selon le sens qui leur plaît et partent en croisade contre tous les autres.
Dijkstra a produit beaucoup de bon matériel, mais il faudrait voir à ne pas prendre tout ce qu'il a dit comme paroles d'évangile.
Tout ceci étant dit, je te remercie quand même d'avoir pris le temps de te pencher sur mon problème (d'une part) et tenter de m'éclairer (d'autre part).
[^] # Re: pas clair ...
Posté par Obsidian . En réponse au message GTK : Forker depuis la boucle principale. Évalué à 2.
D'une manière générale, il est difficile de pas troller lorsque l'on évoque feu Edsger Dijkstra.
Je sais que tu postes cela pour mon bien mais je fais partie des gens qui n'adhèrent pas automatiquement à ses idées (et je ne suis pas le seul si l'on en croit cette célèbre citation extraite de kernel/sched.c : http://www.coda.cs.cmu.edu/doc/talks/linuxvfs/tsld031.htm ). La discussion était d'ailleurs déjà très animée il y a trois ans :
http://linuxfr.org/2002/08/09/9216.html
Je reproche majoritairement deux choses aux disciples de Dijkstra :
1) Tuer dans l'oeuf tout risque de discussion en assénant des vérités toutes faites du style : « It is practically impossible to teach good programming to students that have had a prior exposure to BASIC; as potential programmers they are mentally mutilated beyond hope of regeneration. ». Dijkstra devrait être au quotidien un type pas du tout facile à vivre et ne devait pas aimer que l'on remette en cause ses théories :-)
Aujourd'hui, les gens qui le suivent considèrent les gens qui soutiennent toute théorie « déviante » comme étant nécessairement sots, ou au mieux dans l'ignorance. Cela me rappelle un peu Dan, le scientifique illogique :-)
Quand on en arrive à de telles extrémités, c'est en général par manque de pertinence de l'argumentation.
2) Raisonner de manière essentiellement mathématique. J'entends par là : tenter d'appliquer le modèle de raisonnement et l'analyse des problèmes traditionnels à l'informatique. Il faut bien se rendre compte qu'algorithmie et programmation sont deux domaines sensiblement différents et que ce n'est pas parce Dijkstra a brillament résolu le problème du colporteur que la manière dont il va l'implémenter va être propre.
... et Dieu tue un chaton aussi. Ces exemples sont les problèmes classiques récurrents de la programmation système. On les attribue à toutes les causes possibles et imaginables quand on a envie de se faire le détracteur d'une méthode particulière.
On ne doit pas imbriquer nos if() de la même manière car moi, au contraire, je tiens cette méthode pour être la plus élégante façon de résoudre ces problèmes, spécialement ceux des malloc(). C'est même la seule chose qui me réconcilie un peu avec Dijkstra. La sacro-sainte programmation structurée ne trouve sa réelle signification que sous cette forme. Tout ce qui est conditionné par un if() doit se trouver à l'intérieur.
Il y a belle lurette que grâce à cela, je n'utilise plus exit() et qu'il n'y a qu'un seul return, toujours à la fin de mes fonctions.
Moi, j'en assène une autre, attribuée à Euclide de Mégare et qui orne le portail mathématique du Wikipédia français :
« Ce qui est affirmé sans preuve peut être nié sans preuve »
Quant à la lisibilité, l'important est de garder de la cohérence tout au long de son propre code. Le reste n'est qu'affaire de subjectivité. Il y a de fortes chances pour qu'un code lisible selon tes critères soit parfaitement obscur pour quelqu'un d'autre. Moi, je pense que lorsque l'on est trop à cheval sur la forme, c'est que l'on ne l'est pas assez sur le fond.
Ben voyons, je parle de if() imbriqués et tu me parles de gotos ? Comme je le dis au dessus, il me semble que l'inclusion des différentes routines est justement le meilleur moyen de s'en débarrasser. Sémantiquement parlant, un analyseur de code (autre grand sujet de troll et d'étude en algorithmie) sera immédiatement capable de reconnaitre si un bloc d'instruction est dépendant d'un if() ou pas. Si on les remet à plat, on perd cette possibilité.
Oui, mais ce n'est pas suffisant. Il faut également le saisir de la manière dont il a voulu l'exprimer. Jamais un troll en informatique n'aura été si proche d'une guerre de religion. Dijkstra était déjà un fondamentaliste, mais la plupart des intégristes interprètent aujourd'hui ses propos selon le sens qui leur plaît et partent en croisade contre tous les autres.
Dijkstra a produit beaucoup de bon matériel, mais il faudrait voir à ne pas prendre tout ce qu'il a dit comme paroles d'évangile.
Tout ceci étant dit, je te remercie quand même d'avoir pris le temps de te pencher sur mon problème (d'une part) et tenter de m'éclairer (d'autre part).