Je te rejoins quasiment en tout point. Sauf sur le point clé suivant: [...]
Effectivement, c'est sur ce point que l'on diverge. C'est lorsque tu écris : « [elle] ne devrait répondre qu'au seul problème du quotient d'un entier machine entre 0 et 2n - 1 par une puissance positive quelconque de 2 » en parlant de la primitive shift_right. Pour moi, elle ne devrait rien être, mais elle est ce que l'implémenteur a décidé qu'elle serait. C'est tout le problème de la spécification d'un code. C'est pour cela que j'avais écrit :
En conséquence, la seule chose à faire si l'on veut savoir ce que fait une fonction, c'est d'aller lire la doc : on ne peut pas se fier uniquement à son type ni à ses attentes. Et le seul moyen de vérifier qu'elle se comporte exactement comme le spécifie la doc, c'est d'aller lire le code d'où la condition sine qua non que celui-ci soit publiquement accessible. Voilà une leçon que pourront retenir tes étudiants de cet exercice.
C'est un peu comme Hilbert qui disait qu'en géométrie on s'en fout des noms point, droite ou plan et qu'on pourrait les remplacer par chope de bière, chaise et table : ce qui compte c'est l'axiomatique des structures. Dans toute cette histoire, moi ce que je vois c'est que certains langages ne te fournissent pas de base l'axiomatique que tu souhaiterais. Ce à quoi je te réponds : ils te donnent néanmoins les moyens de construire la structure que tu désires. D'ailleurs au sujet de ADA, je suis allé voir la documentation est le moins que l'on puisse dire c'est que ni le type, ni son complément dans la documentation ne permet de savoir c'est que fait cette fonction shift_right. Même grâce au complément en langue anglaise, je trouve que l'on a là une sous-spécification de son comportement. Au moins, dans certains langages qui ne font pas ce que tu souhaites, avec la documentation on sait ce qu'elle doit faire.
Au fond ce que je vois, c'est qu'on a un opérateur qui agit sur un cylindre : produit cartésien d'un anneau Z/nZ avec un domaine fini. Toi tu veux que l'on prolonge le cylindre en saturant sur sa valeur au bord (ARM), d'autres recollent les bouts et opèrent sur un tore (X86). Ce qui compte surtout c'est qu'il soit possible de faire des découpages et des collages pour construire la structure que l'on souhaite, et cela tous les langages le permettent. Le rôle d'un langage de haut niveau c'est de fournir des moyens plus abstrait que l'assembleur pour effectuer ces constructions puis de passer la main au compilateur pour traduire le tout en code machine. Apprendre un langage donné consiste essentiellement à apprendre les méthodes de construction qu'il fournit pour définir des structures ainsi que les moyens pour opérer sur celles-ci.
Ce que tes étudiants ont expérimenté c'est qu'un tore est cyclique sur ces deux dimensions et qu'il n'a pas du tout la même géométrie qu'un cylindre. Ce qui me rappelle un épisode des Simpson dans lequel Stephen Hawking était très intéressé par la théorie d'Homer selon laquelle l'Univers avait la forme d'un Donuts. :-P
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Du haut niveau pour gérer correctement du bas niveau
Posté par kantien . En réponse au journal Un décalage de 64 bits, ça vous inspire comment ?. Évalué à 2.
Effectivement, c'est sur ce point que l'on diverge. C'est lorsque tu écris : « [elle] ne devrait répondre qu'au seul problème du quotient d'un entier machine entre 0 et 2n - 1 par une puissance positive quelconque de 2 » en parlant de la primitive
shift_right. Pour moi, elle ne devrait rien être, mais elle est ce que l'implémenteur a décidé qu'elle serait. C'est tout le problème de la spécification d'un code. C'est pour cela que j'avais écrit :C'est un peu comme Hilbert qui disait qu'en géométrie on s'en fout des noms point, droite ou plan et qu'on pourrait les remplacer par chope de bière, chaise et table : ce qui compte c'est l'axiomatique des structures. Dans toute cette histoire, moi ce que je vois c'est que certains langages ne te fournissent pas de base l'axiomatique que tu souhaiterais. Ce à quoi je te réponds : ils te donnent néanmoins les moyens de construire la structure que tu désires. D'ailleurs au sujet de ADA, je suis allé voir la documentation est le moins que l'on puisse dire c'est que ni le type, ni son complément dans la documentation ne permet de savoir c'est que fait cette fonction
shift_right. Même grâce au complément en langue anglaise, je trouve que l'on a là une sous-spécification de son comportement. Au moins, dans certains langages qui ne font pas ce que tu souhaites, avec la documentation on sait ce qu'elle doit faire.Au fond ce que je vois, c'est qu'on a un opérateur qui agit sur un cylindre : produit cartésien d'un anneau
Z/nZavec un domaine fini. Toi tu veux que l'on prolonge le cylindre en saturant sur sa valeur au bord (ARM), d'autres recollent les bouts et opèrent sur un tore (X86). Ce qui compte surtout c'est qu'il soit possible de faire des découpages et des collages pour construire la structure que l'on souhaite, et cela tous les langages le permettent. Le rôle d'un langage de haut niveau c'est de fournir des moyens plus abstrait que l'assembleur pour effectuer ces constructions puis de passer la main au compilateur pour traduire le tout en code machine. Apprendre un langage donné consiste essentiellement à apprendre les méthodes de construction qu'il fournit pour définir des structures ainsi que les moyens pour opérer sur celles-ci.Ce que tes étudiants ont expérimenté c'est qu'un tore est cyclique sur ces deux dimensions et qu'il n'a pas du tout la même géométrie qu'un cylindre. Ce qui me rappelle un épisode des Simpson dans lequel Stephen Hawking était très intéressé par la théorie d'Homer selon laquelle l'Univers avait la forme d'un Donuts. :-P
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.