Beuuurk !

Le 26-04-2004 Marc Espie a écrit:

Vouloir la remplacer par quelque chose de plus simple et plus
`mathematique' est une erreur. Ca n'a rien de plus mathematique, on
sait parfaitement lui donner un sens. Et en plus, on nie completement
la structure imperative du langage.

Pas si sûr que ça. Il y a des choses que ton experience verrons comme
évidente, et je ne te remet pas en cause là dessus, mais tu pourrais
admettre que rendre `plus mathematique' ton code, le rendrait simplement
prouvable par des "prouveurs" style de ceux qu'on obtiens en B.

Et ce qui te semble evident en C, se gauffre avec la méthode B, parceque
que tes changements de types à la volée, on ne sait pas prouver ces
trucs là, les pointeurs de fonction non plus, sur le plan mathematique,
ça n'a pas de sens.

--
Laurent

On 26 Apr 2004 13:10:44 GMT
Miod Vallat <miod@online.fr> wrote:

La oui tu est clairement elitiste. Tu fermes carrement la porte au
nez aux personnes qui n'ont pas fait d'etudes.

Bah, faudrait voir à ne pas éxagérer non plus. J'ai appris, grâce à
Marc, l'existence de monsieur Herbrand cet après-midi, et je ne suis
pas sûr de comprendre ses travaux; mais connaître la priorité des
opérateurs et l'ordre des évaluations, ça me semble un b.a.ba de
programmation, quel que soit le langage.

Ca je suis d'accord. C'est sur le fait que cela soit evident que je ne
suis pas d'accord.

Et quoi que tu dises, sur ce point, le langage C ne se classe pas la
catégorie des langages fournis avec planche savonnée au savon noir.

Je ne critique pas le C, je critique une certaine semantique que je
trouve obscure et sujette a erreur malgres que je la comprenne.

mips

In article <slrnc8q2j1.ek9.llefevre@nerim.nospam.net.invalid>,
Laurent Lefevre <llefevre@nerim.spam.net.gov> wrote:

Pas si sûr que ça. Il y a des choses que ton experience verrons comme
évidente, et je ne te remet pas en cause là dessus, mais tu pourrais
admettre que rendre `plus mathematique' ton code, le rendrait simplement
prouvable par des "prouveurs" style de ceux qu'on obtiens en B.

Et ce qui te semble evident en C, se gauffre avec la méthode B, parceque
que tes changements de types à la volée, on ne sait pas prouver ces
trucs là, les pointeurs de fonction non plus, sur le plan mathematique,
ça n'a pas de sens.

Ah mais, le C est un mal necessaire. On n'a pas vraiment de langage bien
foutu a ce niveau-la, pour plein de raisons historiques.

Mais bon, prendre un langage, en tirer une semantique reduite, et prouver
des choses sur cette semantique, on sait faire, quel que soit le langage.
Meme en C, si, si.

On 26 Apr 2004 12:46:48 GMT
Olivier Brisson <olivier.brisson@bluewin.ch> wrote:

mips <anti@spam.gov> schrieb:

Pour moi un source lisible est un source qui se comprend du
premier coup d'oeil. Or ce genre de construction je ne fais pas
qu'y jeter qu'un coup d'oeil vu qu'il est si facile de se
meprendre.

Tu peux avoir du code très bien écrit et ne pas le comprendre car
l'algo te dépasse...

Oui mais ca c'est autre chose auquel on ne peut pas grand chose :)

mips

In article <20040426144825.228d19d4.anti@spam.gov>,
mips <mips@cyberspace.org> wrote:

La oui tu est clairement elitiste. Tu fermes carrement la porte au nez
aux personnes qui n'ont pas fait d'etudes.

Certaines portes leur sont deja fermees, ou du moins tres difficiles
a ouvrir.

Le gars qui n'a pas fait d'etudes, et qui n'est pas autodidacte genial,
il va avoir beaucoup, beaucoup de mal a comprendre certains trucs par
lui-meme. C'est la realite, ca n'est pas moi qui en decide.

La ou je trouve que ca devient dangereux, c'est quand on va confier a
ce type (qui a dix ans d'experience) du code critique qui se trouvera dans
cette frange d'algorithmes qu'il ne comprend pas.

Et la ou je trouve que c'est absurde, c'est quand il va se retrouver a se
demener trois heures pour reinventer une roue tordue alors que la belle
roue bien ronde vient `naturellement' avec les bonnes bases.

Anecdote: j'ai commence l'informatique il y a bien longtemps, en
autodidacte, sur des machines d'un autre age, nommement, une TI-57, puis
un Acorn Atom, puis un Commodore 64. J'etais loin d'avoir les bases
mathematiques a cette epoque, et j'ai passe pas mal de temps a desassembler
les ROM de ces deux dernieres. Sur l'Atom, j'etais fascine par
la routine de trace de droites, et je ne comprenais absolument pas comment
elle fonctionnait... faut dire que capter Bresenham sans avoir fait
d'arithmetique entiere, et surtout en ayant juste sous la main du code
assembleur 8 bits implementant les formules `optimisees', c'est pas evident.
Je n'ai jamais reussi a decoder completement l'interpreteur basic non plus.
Je me heurtais a une routine qui faisait reference a une table avec des
sauts dans tous les coins... faut dire que sans savoir ce qu'est un
automate et sa representation efficace en machine, ca ressemble fort a
un code secret mis la expres pour vous faire chier.

Le code de calcul des sinus etait egalement tres intrigant: les
coefficients n'etaient pas ceux que j'ai vu en cours vers ce moment-la,
mais quelques choses qui ressemblait. Il faut dire que les techniques
d'acceleration de convergence, et les polynomes interpolateurs a la
Tchebycheff, ca s'invente pas, sauf si on est Tchebycheff...

A cote de ca, j'ai decouvert pas mal de trucs par moi-meme, ou j'ai bute
sur pas mal de choses qui m'ont rendu les notions mathematiques ou
informatiques vues ensuite interessantes. La notion de dichotomie, par
exemple, que j'ai presque retrouvee en resolvant des equations; ou la
notion de section critique, que j'ai trouve en reparant le pilote
d'imprimante de ma seikosha GP100 qui begayait... mais je ne regrette
absolument pas d'avoir vu ensuite le formalisme correspondant.

According to Marc Espie <espie@nerim.net>:

- Pascal ne l'a pas.

Soyons précis : le Pascal de base ne l'a pas, mais son implémentation la
plus répandue (Turbo Pascal de chez Borland, et dérivés tels que Delphi)
possède l'évaluation paresseuse des booléens en option (activée par
défaut, si je ne m'abuse).


--Thomas Pornin

Soyons précis : le Pascal de base ne l'a pas, mais son implémentation la
plus répandue (Turbo Pascal de chez Borland, et dérivés tels que Delphi)
possède l'évaluation paresseuse des booléens en option (activée par
défaut, si je ne m'abuse).

<cappilotracteur>
Seulement depuis la version 4, et par défaut seulement depuis la version
7, si mes souvenirs sont exacts. Ceci dit, on s'en contrefiche, puisque
c'est du pascal.
</>

According to mips <mips@cyberspace.org>:

Pour moi un source lisible est un source qui se comprend du premier
coup d'oeil. Or ce genre de construction je ne fais pas qu'y jeter
qu'un coup d'oeil vu qu'il est si facile de se meprendre.

Un code source est lisible s'il est facilement compris en le lisant.
C'est une tautologie. Mais il faut bien prendre conscience que la
lisibilité dépend beaucoup de celui qui lit, et qu'on suppose toujours
une base de connaissance de la part du lecteur, fût-ce implicitement.

En l'occurrence, quand on montre un code source en C à un lecteur, on
suppose que ce lecteur saura suffisamment de C pour en faire quelque
chose. Il y a pas mal de choses en C qui ne sont pas évidentes du tout
pour celui qui n'en a jamais appris la syntaxe, parmi lesquelles on
trouve :
-- les déclarations de variables et de fonctions ;
-- le for(;;) ;
-- les opérateurs un peu abscons (et notamment que "=" est une affectation
alors que "==" fait une comparaison) ;
-- les "break" et autres "continue" ;
etc...

Il est illusoire de faire un code lisible pour quelqu'un qui ne connaît
pas ces quelques bases du C. Or, le fait que "&&" et "||" font de
l'évaluation paresseuse, fait partie des bases du C. C'est expliqué
très tôt dans n'importe quel ouvrage ou cours décent sur le C. Si le
lecteur ne sait pas ça, il y a fort à parier qu'il bute aussi sur
d'autres constructions basiques et idiomatiques du C.

En bref : il y a une différence entre refuser l'élitisme et vouloir
faire du nivellement par le bas.



Un autre point à considérer est que pour que quelque chose soit lisible
"d'un coup d'oeil", il faut qu'on puisse effectivement l'appréhender
d'un seul coup d'oeil. Ce qui veut dire que tout doit tenir en ce que
l'oeil du lecteur peut voir en un seul coup. Je peux, personnellement,
considérer environ 30 lignes sans balayage excessif. Au-delà, c'est trop
grand, je perds trop de temps à sauter d'un endroit à un autre.

Donc, de mon point de vue de lecteur, toute construction qui tend à
écrire sur une ligne ce qui en aurait pris trois autrement, est un
gain. À condition que ça ne se fasse pas au détriment de l'espacement
horizontal, qui aide mes yeux à s'y retrouver.


--Thomas Pornin

On 2004-04-26, Thomas Pornin <pornin@nerim.net> wrote:

-- les déclarations de variables et de fonctions ;
-- le for(;;) ;

Ce sont des questions de syntaxe, pas de fonctionnement car ces
"notations" n'ont aucun fonctionnement implicite.

-- les opérateurs un peu abscons (et notamment que "=" est une affectation
alors que "==" fait une comparaison) ;

Je n'aime pas non plus les constructions du type (a=b)==c car je
n'attends pas de l'évaluation d'une expression qu'elle modifie des
variables.

Pour moi l'évaluation paresseuse c'est juste une optimisation.

-- les "break" et autres "continue" ;

J'ai vu tellement de gens penser que sur un break l'exécution allait
quand-même au bout de la boucle, donc je passe là dessus.

Un autre point à considérer est que pour que quelque chose soit lisible
"d'un coup d'oeil", il faut qu'on puisse effectivement l'appréhender
d'un seul coup d'oeil. Ce qui veut dire que tout doit tenir en ce que
l'oeil du lecteur peut voir en un seul coup. Je peux, personnellement,
considérer environ 30 lignes sans balayage excessif. Au-delà, c'est trop
grand, je perds trop de temps à sauter d'un endroit à un autre.

Il faut aussi qu'on puisse faire une lecture rapide du code et trop
condenser risque de cacher des appels de fonction qui auraient été
clairement visibles autrement. Donc là ça révèle plutôt des habitudes
de chacun.

C'est comme pour le placement des {} :

if(expressiona==expressionb) faisqqch();

if(expressiona==expressionb)
faisqqch();

if( expressiona == expressionb ) {
faisqqch();
}

if( expressiona == expressionb )
{
faisqqch();
}

etc.

--
cns

On 2004-04-26, Marc Espie <espie@tetto.gentiane.org> wrote:

Anecdote: j'ai commence l'informatique il y a bien longtemps, en
autodidacte, sur des machines d'un autre age, nommement, une TI-57, puis
un Acorn Atom, puis un Commodore 64. J'etais loin d'avoir les bases
mathematiques a cette epoque, et j'ai passe pas mal de temps a desassembler
les ROM de ces deux dernieres. Sur l'Atom, j'etais fascine par
la routine de trace de droites, et je ne comprenais absolument pas comment
elle fonctionnait... faut dire que capter Bresenham sans avoir fait
d'arithmetique entiere, et surtout en ayant juste sous la main du code
assembleur 8 bits implementant les formules `optimisees', c'est pas evident.

Là il est question de déassembler du code et pas de savoir comment il
a été écrit. Je suppose que dans le code source (qui devait être un
listing d'assembleur) il y avait des commentaires, et au moins une
référence à Bresenham. En écrivant correctement en C on peut se
passer de pas mal de commentaires. Et si on fait quelquechose de pas
très clair, comme le fameux for(n=0;b;n++) b&=b-1; on met une
explication.

Note: l'algorithme de Bresenham pour les cerlces est pas mal non plus.

Je n'ai jamais reussi a decoder completement l'interpreteur basic non plus.
Je me heurtais a une routine qui faisait reference a une table avec des
sauts dans tous les coins... faut dire que sans savoir ce qu'est un
automate et sa representation efficace en machine, ca ressemble fort a
un code secret mis la expres pour vous faire chier.

Là non plus sans les sources ça ne me choque pas qu'on n'y comprenne
pas grand chose. A titre d'exemple le code généré par lex n'est pas
vraiment fait pour être lu ou compris.

A cote de ca, j'ai decouvert pas mal de trucs par moi-meme, ou j'ai bute
sur pas mal de choses qui m'ont rendu les notions mathematiques ou
informatiques vues ensuite interessantes. La notion de dichotomie, par
exemple, que j'ai presque retrouvee en resolvant des equations; ou la
notion de section critique, que j'ai trouve en reparant le pilote
d'imprimante de ma seikosha GP100 qui begayait... mais je ne regrette
absolument pas d'avoir vu ensuite le formalisme correspondant.

Bah c'est un débat sans fin.

Les élitistes d'une part ne voulant pas se mettre au niveau des masses
("all genius appear simple"). Le programmeur lambda autodidacte qui
oublie trop vite que l'informatique est un métier qui ne s'improvise
pas.

--
cns