Rue89 : Pourquoi il faut enseigner le codage informatique au lycée.

Pour le code qui n'est pas "programmation" je pense à tout ce qui est métadonnées: voir par exemple le TEI: (text encoding initiative) http://www.tei-c.org/release/doc/tei-p5-doc/en/html/index-toc.html

Pourrais-tu me donner une idée du moment dans le cursus en math où les enfants apprennent à convertir les nombres entre différentes bases? (je ne sais pas comment exprimer cette notion en français n'ayant suivi aucun cours de math en France)

re: 32 (décimal: 10)= 20 (hex: 16)
7 (decimal: 10) =111 (binary: 2)

Pour ta question : plus jamais avant le supérieur !

C'était au programme de spé maths en TS jusqu'à cette année mais je crois bien que cela a disparu (je vérifierai car c'est moi qui les ai cette année).

Ils le font un peu en SI (sciences de l'ingénieur) en hexadécimal et binaire mais c'est un outillage, il n'y a pas de théorie mathématique expliquant le tout grâce à la division euclidienne.

C'était au programme de spé maths en TS jusqu'à cette année

C'était pas au programme de TS, ni cette année, ni avant.

Mode vieux dinausore ON:

Par contre, c'était au programme de 5 ème, il y a longtemps

Mode OFF

Ah si si, je l'ai enseigné pdt 8 ans : le TD systèmes de numération figurait dans les commentaires du programme officiel où il était mentionné que les élèves devaient savoir manipuler les bases.

Je l'ai fait au collège moi aussi, mais ailleurs, et avant. Le 5e me paraît à peu près logique, ça ne devrait pas être fait avant que les tables de multiplication ne soient bien apprises et la division bien ancrée, car évidemment ce n'est pas le truc le plus utile au monde; c'est juste un exercice assez sympa qui aide à voir que la norme en usage n'est pas limitative, que le décimal n'est pas la seule façon de représenter les chiffres....

e.g. du style {h1} en HTML peut "être" de taille 12px ou de taille 24px selon le CSS

merci à vous deux pour les réponses!

Les systèmes de numération étaient abordés à l'école primaire à l'époque des "maths modernes"...
En sixième ou cinquième, une occasion de faire des opérations (conversions avec du décimal et de l'hexadécimal), des calculs de pourcentages, de moyennes :
http://rdassonval.free.fr/flash/couleurs.html

très chouette, F5-reload et rejoue.

Je ne peux pas faire travailler mes anglicistes sur un site en français.

Traduisons, donc!

http://www.creoliste.fr/teaching/hex.html

dasson a écrit:Les systèmes de numération étaient abordés à l'école primaire à l'époque des "maths modernes"...
En sixième ou cinquième, une occasion de faire des opérations (conversions avec du décimal et de l'hexadécimal), des calculs de pourcentages, de moyennes :
http://rdassonval.free.fr/flash/couleurs.html

De bien doux souvenirs...

J'ai juste quelques petites questions :

* à l'époque où il n'y avait pas tous ces professeurs émérites qui commencent par les bases et apprennent à l'informatique "comme il faut", on peut s'accorder pour dire qu'il y a quand même eu des programmeurs (ou appelez-les comme vous le voulez). Ce sont donc tous des bidouilleurs qui ne sauront jamais rien faire de bien ?

* à l'époque actuelle où de toute façon l'apprentissage de la programmation arrive bien tard (allez admettons qu'on considère l'algorithmique en maths 2de comme le début de la programmation), que doit-on penser des jeunes qui ont ouvert un bout de code avant 15 ans ?

* et pour terminer sur une expérience personnelle, j'ai commencé à coder avec du BASIC sur des programmes que je recopiais de science et vie et que j'essayais de comprendre. Il y avait pas mal de GOTO à l'époque. Bon et puis un jour j'ai compris que "GOTO c'était mal" et j'ai arrêté. Les "mauvaises" habitudes, je doute qu'il n'y ait que moi qui sois capable de les arrêter ?

* ah oui et puisqu'on est sur un bon forum français je m'étonne que personne n'ait encore cité CAML

xphrog a écrit:Je l'ai fait au collège moi aussi, mais ailleurs, et avant. Le 5e me paraît à peu près logique, ça ne devrait pas être fait avant que les tables de multiplication ne soient bien apprises et la division bien ancrée, car évidemment ce n'est pas le truc le plus utile au monde; c'est juste un exercice assez sympa qui aide à voir que la norme en usage n'est pas limitative, que le décimal n'est pas la seule façon de représenter les chiffres....

e.g. du style {h1} en HTML peut "être" de taille 12px ou de taille 24px selon le CSS

merci à vous deux pour les réponses!

Là, tu confonds deux choses. La programmation au sens strict (C, Fortran, Pascal...) qui est le fruit d'une (quasi-) bijection entre un algorithme et un programme et l'interprétation d'un contenu par un formateur de texte. Ton programme se suffit donc à lui-même alors que ton code html est interprété par un navigateur et ses feuilles de style par défaut. Le résultat n'est donc ni unique ni déterministe (au sens mathématique du terme).

dasson a écrit:Les systèmes de numération étaient abordés à l'école primaire à l'époque des "maths modernes"...
En sixième ou cinquième, une occasion de faire des opérations (conversions avec du décimal et de l'hexadécimal), des calculs de pourcentages, de moyennes :
http://rdassonval.free.fr/flash/couleurs.html

C'est pourtant l'une des dernières choses à aborder. Le problème n'est pas le changement de base (sous-entendu des entiers), mais la finitude de la machine, en particulier de la longueur du mot. Si le diable est dans les détails, le problème de la conversion entre la notation décimale et le binaire se situe dans les flottants car il est impossible de se représenter en binaire exactement 0,1, la décomposition étant infinie.

Par ailleurs, il ne faut pas perdre de vue que certains langages travaillent directement en décimal (voire en virgule fixe ou en précision arbitraire) et que d'autres proposent des opérations arithmétiques sur la droite achevée (le terme technique exact m'échappe au moment où j'écris ces mots).

Par conséquent, il faut d'abord avoir de sérieuses notions d'algorithmie (valables quel que soit le langage) avant d'aborder les joyeusetés inhérentes à l'implantation de tel ou tel langage dans un automate fini et leur corollaire qu'est l'analyse numérique.

_Yann_ a écrit:J'ai juste quelques petites questions :

* à l'époque où il n'y avait pas tous ces professeurs émérites qui commencent par les bases et apprennent à l'informatique "comme il faut", on peut s'accorder pour dire qu'il y a quand même eu des programmeurs (ou appelez-les comme vous le voulez). Ce sont donc tous des bidouilleurs qui ne sauront jamais rien faire de bien ?

À l'époque, comme tu dis, l'informatique était rare et les calculateurs extrêmement limités. À titre d'information, la NASA a envoyé le premier homme sur la lune avec une puissance de calcul plus faible que la calculette de poche d'un collégien actuel. Et pour en avoir un peu fait, les calculs d'orbitographie sont très complexes (à tel point qu'on projette souvent l'espace de Riemann localement sur un espace euclidien). Les techniciens de l'époque ont tâtonné durant des années avant de réussir à fixer les paradigmes de l'informatique moderne dans les années 1970/1980. J'entends par paradigmes la programmation procédurale, le fonctionnement des piles, des interruptions... Avant cette période, chacun réinventait la poudre (ou la roue) à chaque nouvelle machine. Ce n'est que parce que les débuts de l'informatique ont été rudes qu'il a fallu attendre plus de vingt ans pour avoir des systèmes d'exploitation un tant soit peu standard et des fonctions communes pour que tout interagisse (presque) correctement. Des bidouilleurs géniaux il y en eu pourtant. Je pense à Grace Hopper, à von Neuman, à Turing voire à dieu^WKnuth. Pardon à ceux que j'oublie. Mais si le dernier est capable de faire quelque chose de très bien sur un calculateur moderne, les trois précédents seraient totalement perdus avec la plus petite des machines actuelles parce qu'ayant fait leurs armes et inventé l'informatique moderne sur des machines étriquées, leurs façons de concevoir un programme n'aurait rien à voir avec notre façon de programmer. Pour l'anecdote, il restait 400 octets de mémoire disponible dans une sonde voyager. Dans ces 400 octets de mémoire, la NASA a réussi à rajouter un programme de reconnaissance de forme grâce auquel on a découvert de nouvelles lunes dans le système solaire. Heureusement que les ingénieurs de la Nasa savaient programmer correctement.

Aujourd'hui, c'est un peu différent. Les concepts généraux n'ont pas vraiment changé depuis plus de trente ans (hormis les aberrations suprêmes que sont Java d'une part et Python d'autre part). Il n'y a donc aucune raison pour demander à un élève de réinventer la roue. Il faut en revanche qu'il comprenne comment cette roue fonctionne. Et si cet apprentissage revient à monter des méccanos de code à partir de blocs préexistants dont il ne comprend réellement ni les tenants ni les aboutissants, cela ne restera qu'un bidouilleur dont le code produit fonctionne par hasard.

* à l'époque actuelle où de toute façon l'apprentissage de la programmation arrive bien tard (allez admettons qu'on considère l'algorithmique en maths 2de comme le début de la programmation), que doit-on penser des jeunes qui ont ouvert un bout de code avant 15 ans ?

Absolument rien s'ils ont pris le problème dans le bon sens.

* et pour terminer sur une expérience personnelle, j'ai commencé à coder avec du BASIC sur des programmes que je recopiais de science et vie et que j'essayais de comprendre. Il y avait pas mal de GOTO à l'époque. Bon et puis un jour j'ai compris que "GOTO c'était mal" et j'ai arrêté. Les "mauvaises" habitudes, je doute qu'il n'y ait que moi qui sois capable de les arrêter ?

Il n'y a que le concepteur du langage Pascal qui déclare que le goto, c'est le mal absolu. C'est idiot et un peu court. Le problème n'est pas le problème du goto au sens strict, mais le problème de la programmation en Basic qui était largement impérative (sauf le Turbo Basic de Borland qui était procédural). Les gens qui avaient appris à programmer en Basic étaient contraints à reprendre de bonnes habitudes en passant dans des langages procéduraux parce qu'un goto entre une procédure et une autre n'est pas obligatoirement licite (et lorsqu'il l'est, comment dire, ça fout un bordel incommensutable sur la pile, ce qui fait qu'il est inefficace).

Pour être tout à fait exact, je considère cette histoire du goto comme une tarte à la crème reprise régulièrement. Tout le monde en parle, mais personne (sauf les spécialistes de la chose) ne sait réellement pourquoi Wirth a écrit un jour l'article "des Gotos considérés comme nuisibles". Sa réaction était surtout une réaction épidermique envers les langages un peu batards comme le Basic dont l'immense majorité des versions n'étaient pas structurées.

En revanche, il existe tout un tas d'autres mauvaises habitudes qui ont la vie dure. Les passages par copie à la place de passages par pointeurs ou par références, les effets de bords de certaines classes d'appel, la structuration des données et des alignements (je pense au SEQUENCE du Fortran qui est toujours une grande surprise pour les étudiants). Et ces mauvaises habitudes qui consistent souvent à faire des hypothèses sur la façon qu'a un compilateur de fonctionner sont assez problématiques, plus sournoises que l'éradication des gotos et beaucoup plus difficiles à corriger.

* ah oui et puisqu'on est sur un bon forum français je m'étonne que personne n'ait encore cité CAML

Je n'étais certes que très peu précis dans mon post, ce qui fait qu'on s'est mal compris :

* pour mon premier point, je ne remontais pas à si loin dans le temps. Je voulais simplement mettre en valeur le fait que bon nombre de personnes (on va dire d'une 60aine d'années) n'ont pas eu forcément les approches "académiques dans le 'bon' sens" et sont pourtant aujourd'hui tout à fait capables de programmer correctement (et d'enseigner cela).

Pour rebondir sur ta réponse, évidemment il fallait être bien plus astucieux quand on disposait de peu de mémoire, et il suffit de voir tous les MOs... pardon les GOs qu'on nous impose pour installer le moindre truc aujourd'hui pour se dire qu'optimiser un peu au lieu de faire des programmes tentaculaires ça ne serait peut être pas du gâchis.

* pour mon second point, je voulais dire que bien souvent un élève qui va apprendre par lui-même va apprendre pour faire quelque chose qui l'intéresse, et n'apprendra pas forcément dans "le 'bon' sens". Typiquement s'il fait comme moi il va commencer par recopier des petits bouts de programmes qui font ce qu'il veut faire, puis comprendre au fur et à mesure, pas forcément dans un ordre déterministe.

* pour mon dernier point, j'étais effectivement ironique (d'où mes nombreux guillemets), et le GOTO n'était là qu'à titre d'exemple. Tu peux remplacer cela par n'importe quelle mauvaise habitude : des tas d'élèves chaque année qui disent au début "excusez-moi" finissent par dire "veuillez m'excuser", des tas d'élèves chaque année qui disent au début "on fait passer" (résolution d'équation, mettons du 1er degré) finissent par dire s'ils ajoutent, retranchent, multiplient, divisent... J'ose de plus croire qu'ils disent "excusez-moi" depuis plus longtemps qu'ils ne font un passage par copie au lieu de référence ; donc si le premier est modifiable...

_Yann_ a écrit:Je n'étais certes que très peu précis dans mon post, ce qui fait qu'on s'est mal compris :

* pour mon premier point, je ne remontais pas à si loin dans le temps. Je voulais simplement mettre en valeur le fait que bon nombre de personnes (on va dire d'une 60aine d'années) n'ont pas eu forcément les approches "académiques dans le 'bon' sens" et sont pourtant aujourd'hui tout à fait capables de programmer correctement (et d'enseigner cela).

Parce que ces personnes ont soit :
- commencé à toucher l'informatique au début des années 1970 lorsque tout était à faire et ont dû inventer des solutions, et pour inventer ces solutions il fallait déjà comprendre finement comment cela fonctionnait. Pour information, je ne connais aucun ouvrage informatique traitant d'un système particulier et datant de la période 1970-1985 qui ne parle pas explicitement du matériel et de la façon de le programmer à bas niveau ;
- appris à coder après cette période avec des gens qui avaient défriché ce domaine pour eux.

Pour rebondir sur ta réponse, évidemment il fallait être bien plus astucieux quand on disposait de peu de mémoire, et il suffit de voir tous les MOs... pardon les GOs qu'on nous impose pour installer le moindre truc aujourd'hui pour se dire qu'optimiser un peu au lieu de faire des programmes tentaculaires ça ne serait peut être pas du gâchis.

* pour mon second point, je voulais dire que bien souvent un élève qui va apprendre par lui-même va apprendre pour faire quelque chose qui l'intéresse, et n'apprendra pas forcément dans "le 'bon' sens". Typiquement s'il fait comme moi il va commencer par recopier des petits bouts de programmes qui font ce qu'il veut faire, puis comprendre au fur et à mesure, pas forcément dans un ordre déterministe.

Lorsqu'un élève apprend seul, la démarche est un peu différente, il va essayer de comprendre comment ça marche, surtout dans le domaine en question.

* pour mon dernier point, j'étais effectivement ironique (d'où mes nombreux guillemets), et le GOTO n'était là qu'à titre d'exemple. Tu peux remplacer cela par n'importe quelle mauvaise habitude : des tas d'élèves chaque année qui disent au début "excusez-moi" finissent par dire "veuillez m'excuser", des tas d'élèves chaque année qui disent au début "on fait passer" (résolution d'équation, mettons du 1er degré) finissent par dire s'ils ajoutent, retranchent, multiplient, divisent... J'ose de plus croire qu'ils disent "excusez-moi" depuis plus longtemps qu'ils ne font un passage par copie au lieu de référence ; donc si le premier est modifiable...

Sauf qu'il faut déjà comprendre pourquoi un passage par copie peut être parfois bon, parfois mauvais...

Certains passages sont bons ou mauvais... De la même manière il faut comprendre quand utiliser du langage soutenu / langage familier. A priori les difficultés sont comparables.

Pour l'apprentissage en autodidacte, effectivement le problème est un peu différent au sens où la personne est forcément dans une démarche intéressées. Mais j'ai envie de dire que dans les études d'informatique, les élèves aussi sont intéressés : ils sont déjà plutôt matures (post-bac en général), ils ont choisi cette voie... eux aussi en veulent et sont capables d'aller voir par eux-même, si on leur montre cette possibilité.

En résumé je pense qu'il faut éviter de trop vouloir enfermer les élèves dans un sacro-saint carcan duquel il ne faut surtout pas sortir ; les élèves manipulent depuis très longtemps des ensembles sans avoir besoin de savoir toute la base de la théorie des ensembles ; les élève manipulent les réels sans avoir besoin d'une définition parfaitement exacte de cet ensemble de nombres ; et c'est bien normal !

On veut aujourd'hui enseigner aux élèves en premier lieu des choses qui ont mis (et tu es le premier à le dire dans ton post) des choses qui, selon la matière, ont mis des dizaines, des centaines, des milliers d'années à se mettre en place correctement. Alors certes, ça gagne du temps. Très peu de contemporains d'Einstein pouvaient comprendre ce qu'il faisait, alors que chaque année des centaines d'étudiants apprennent à manipuler cette théorie : c'est un gain inestimable. Cela dit ce n'est pas forcément bon à tous les niveaux. Un élève a une notion intuitive de ce que c'est qu'une probabilité (x chances sur y). Certes beaucoup de choses dans les probabilités sont contre-intuitives, mais pour le début c'est bien suffisant !

Qu'un daigne prendre le temps d'enseigner ce qu'on a à enseigner sans vouloir bille en tête commencer par la formalisation pure et dure qui a demandé un temps considérable à se mettre en place. Qu'on daigne donner à nos élèves le temps nécessaire à l'acquisition de nouveaux savoirs. Et alors là on pourra reparler des bases solides. Quand elles ne seront pas le premier jalon "indispensable" au savoir.

_Yann_ a écrit:Certains passages sont bons ou mauvais... De la même manière il faut comprendre quand utiliser du langage soutenu / langage familier. A priori les difficultés sont comparables.

Pour l'apprentissage en autodidacte, effectivement le problème est un peu différent au sens où la personne est forcément dans une démarche intéressées. Mais j'ai envie de dire que dans les études d'informatique, les élèves aussi sont intéressés : ils sont déjà plutôt matures (post-bac en général), ils ont choisi cette voie... eux aussi en veulent et sont capables d'aller voir par eux-même, si on leur montre cette possibilité.

Euh, comment dire... En fait non. C'est justement les élèves que je connais le mieux et on ne peut pas dire qu'ils soient réellement intéressés par ce qui se passe vraiment dans les entrailles d'une machine. Rares sont ceux qui viennent dans l'informatique ou le calcul pour la matière elle-même. Ils viennent plutôt par ici pour avoir un tremplin vers les options "banque et finance", "high speed trading" ou tout simplement coder des applications jetables en Java pour traders fous. Je passe actuellement mon temps à piloter des stagiaires soi-disant spécialistes en informatique ou mathématiques appliquées incapables de coder deux lignes de C ou de Fortran sans erreurs grossières.

En résumé je pense qu'il faut éviter de trop vouloir enfermer les élèves dans un sacro-saint carcan duquel il ne faut surtout pas sortir ; les élèves manipulent depuis très longtemps des ensembles sans avoir besoin de savoir toute la base de la théorie des ensembles ; les élève manipulent les réels sans avoir besoin d'une définition parfaitement exacte de cet ensemble de nombres ; et c'est bien normal !

Sauf qu'on ne parle pas du tout de la même chose. Je ne vois pas comment expliquer à un élève/étudiant pourquoi utiliser des entiers en virgule fixe plutôt que des réels même en double précision sans jamais n'avoir commencé à étudier la limite de la représentation des flottants en précision limitée. Ne pas le faire revient à faire des hypothèses assez scabreuses dans certains logiciels (je pense à un logiciel comptable célèbre qui vient de se prendre une telle erreur dans la figure et ça lui a coûté très cher).

Mais après tout, vous avez parfaitement le droit de vouloir mettre la charrue avant les boeufs.

On veut aujourd'hui enseigner aux élèves en premier lieu des choses qui ont mis (et tu es le premier à le dire dans ton post) des choses qui, selon la matière, ont mis des dizaines, des centaines, des milliers d'années à se mettre en place correctement. Alors certes, ça gagne du temps. Très peu de contemporains d'Einstein pouvaient comprendre ce qu'il faisait, alors que chaque année des centaines d'étudiants apprennent à manipuler cette théorie : c'est un gain inestimable. Cela dit ce n'est pas forcément bon à tous les niveaux. Un élève a une notion intuitive de ce que c'est qu'une probabilité (x chances sur y). Certes beaucoup de choses dans les probabilités sont contre-intuitives, mais pour le début c'est bien suffisant !

Qu'un daigne prendre le temps d'enseigner ce qu'on a à enseigner sans vouloir bille en tête commencer par la formalisation pure et dure qui a demandé un temps considérable à se mettre en place. Qu'on daigne donner à nos élèves le temps nécessaire à l'acquisition de nouveaux savoirs. Et alors là on pourra reparler des bases solides. Quand elles ne seront pas le premier jalon "indispensable" au savoir.

C'est pour cela que la formation, au moins au primaire, devrait se concentrer sur les enseignements de base (français, calcul et deux ou trois choses qui excluent l'apprentissage de la programmation).

Je comprends ce que tu dis, et j'entends le fait que par chez toi, les élèves ne sont pas tous motivés par l'informatique. Sache simplement que ce n'est pas partout le cas. Après je n'ai effectivement pas de statistiques précises, donc peut être ce débat est-il stérile pour le moment. Sache juste que les BTS informatique par chez moi sont vraiment très intéressés et sont des élèves avec qui on prend plaisir à travailler.

Pour ton exemple précis à enseigner, j'imagine que tu le fais déjà, mais c'est ce que je fais souvent : je montre par l'exemple des trucs très moches auxquels ils n'auraient sans doute pas pensé (un collègue récemment m'a fourni un super exemple : la suite définie par u_{n+1} = 6*u_n - 1 et u_0 = 0,2, qui est théoriquement stationnaire (valeur constante 0,2) diverge très vite quand on la programme (en raison de l'erreur générée par codage en flottant). Cela les frappe suffisamment en général pour au moins entrer en matière

Enfin j'ose espérer que je ne mets pas la charrue avant les boeufs en général dans mes cours, en essayant d'introduire un peu d'histoire des sciences pour parles des notions et non en commençant par les définitions atomiques. On peut en discuter.

PS: Je constate que j'ai utilisé le tutoiement alors que je viens de voir le vouvoiement dans (votre ?) dernier post. Si mon tutoiement a choqué je présente mes excuses, sinon autant faire tous les deux de même

_Yann_ a écrit:Je comprends ce que tu dis, et j'entends le fait que par chez toi, les élèves ne sont pas tous motivés par l'informatique. Sache simplement que ce n'est pas partout le cas. Après je n'ai effectivement pas de statistiques précises, donc peut être ce débat est-il stérile pour le moment. Sache juste que les BTS informatique par chez moi sont vraiment très intéressés et sont des élèves avec qui on prend plaisir à travailler.

Pour ton exemple précis à enseigner, j'imagine que tu le fais déjà, mais c'est ce que je fais souvent : je montre par l'exemple des trucs très moches auxquels ils n'auraient sans doute pas pensé (un collègue récemment m'a fourni un super exemple : la suite définie par u_{n+1} = 6*u_n - 1 et u_0 = 0,2, qui est théoriquement stationnaire (valeur constante 0,2) diverge très vite quand on la programme (en raison de l'erreur générée par codage en flottant).

Eh bien non. Cela dépend essentiellement de l'implantation du flottant dans le langage en question. Je viens d'essayer avec un compilo Fortran, ça ne diverge pas (le code assembleur indique que le calcul est fait en 64 bits avant d'être tronqué en 32 bits dans le real*4). Brutalement, avec un compilo C, ça part très vide dans le mur, mais ce n'est pas une généralité.

Un exemple plus parlant est le calcul d'une TVA sur un objet de quelques euros puis la somme des prix HT et TTC pour la facturation. À tous les coups, il y a une différence à la fin parce qu'on ne recherche pas une stationnarité mais qu'on inverse deux opérations (multiplication et sommation).

Cela les frappe suffisamment en général pour au moins entrer en matière

Enfin j'ose espérer que je ne mets pas la charrue avant les boeufs en général dans mes cours, en essayant d'introduire un peu d'histoire des sciences pour parles des notions et non en commençant par les définitions atomiques. On peut en discuter.

PS: Je constate que j'ai utilisé le tutoiement alors que je viens de voir le vouvoiement dans (votre ?) dernier post. Si mon tutoiement a choqué je présente mes excuses, sinon autant faire tous les deux de même

Disons que je me suis mélanger les pinceaux... Je ne le referai plus

Je constate que c'est la seconde fois que tu me dis "non" directement (juste avant tu me dis "non" alors que tu cites ma comparaison niveau de langue / passage copie-pointeur, sans m'expliquer pourquoi "non".)

Je n'ai jamais dit (ni mon collègue d'ailleurs) que la divergence de la suite était partout. J'aurais du préciser certes que c'était en C et sur tableur (microsoft excel et open office calc) et que je n'ai pas testé partout, m'enfin je trouvais quand même que l'exemple était suffisamment frappant. Que la suite ne se comporte pas de la même manière partout est encore mieux pour montrer aux élèves qu'il faut savoir comment ça fonctionne avant de lancer la machine dans un calcul !

Et puis si tu as un exemple plus frappant c'est tant mieux, mais du coup je crois que c'est très bien ça ton exemple pour les élèves : et pour le coup tu peux leur expliquer pourquoi utiliser telle ou telle représentation sans avoir fait trop de théorie avant justement : en leur montrant qu'en général, les réels peuvent cafouiller.

Après tout ce que je dis ne vient pas prêcher pour l'étude de la programmation dès le plus jeune âge, je dis simplement que l'option "tout théorique en premier" me parait discutable, et donc qu'il doit être possible d'en faire un peu plus tôt qu'après le bac. Que ça soit une bonne idée ou pas, je dirais que non, je suis plutôt d'accord avec le fait qu'il faut vraiment privilégier les fondamentaux qui pour la plupart des élèves ne seront plus étudiés (langue française, histoire-géographie, mathématiques). Mais ça ne me choque pas que ça soit disponible en option pour ceux qui le voudraient (comme ISN en terminale, mais ça peut même arriver en 2de en enseignement d'exploration pourquoi pas : j'ai déjà eu des élèves en 1e qui utilisaient de la programmation dans leur TPE)

_Yann_ a écrit:Je constate que c'est la seconde fois que tu me dis "non" directement (juste avant tu me dis "non" alors que tu cites ma comparaison niveau de langue / passage copie-pointeur, sans m'expliquer pourquoi "non".)

Il me semblait pourtant avoir expliqué juste après en quoi l'exemple n'était pas à mon avis correct puisqu'il dépend de l'implantation des flottant dans un compilateur (ou un outil de calcul)...

Alors c'est bien ce que je pensais et c'est simplement la citation trop grande qui par deux fois m'a laissé un moment dans le doute (puisque si j'ai bien compris maintenant, comme je m'en doutais, ce n'était pas un non à l'intégralité des citations)

Sinon je ne vois pas en quoi un exemple qui dépend de l'implantation des flottants n'est pas correct, je viens d'écrire que justement ça devrait montrer aux élèves qu'il faut bien faire attention (que ce soit pour la portabilité du code, pour la transcription etc.)

_Yann_ a écrit:Alors c'est bien ce que je pensais et c'est simplement la citation trop grande qui par deux fois m'a laissé un moment dans le doute (puisque si j'ai bien compris maintenant, comme je m'en doutais, ce n'était pas un non à l'intégralité des citations)

Sinon je ne vois pas en quoi un exemple qui dépend de l'implantation des flottants n'est pas correct, je viens d'écrire que justement ça devrait montrer aux élèves qu'il faut bien faire attention (que ce soit pour la portabilité du code, pour la transcription etc.)

C'est-à-dire que dans une promotion, j'ai toujours un ou deux étudiants pervers qui veulent se faire remarquer tout en n'ayant pas tout compris et qui vont me sortir qu'avec leur compilo machin en version bidule, ça marche. Je leur coupe l'herbe sous le pied en proposant un exemple qui ne peut être simplifié par un compilateur.

Edit: la constante peut d'autorité être castée en double (et non en float) pour une histoire de représentation interne. Le calcul se fait alors en double précision et le résultat est tronqué en simple précision.

Le grincheux a écrit:

xphrog a écrit:Je l'ai fait au collège moi aussi, mais ailleurs, et avant. Le 5e me paraît à peu près logique, ça ne devrait pas être fait avant que les tables de multiplication ne soient bien apprises et la division bien ancrée, car évidemment ce n'est pas le truc le plus utile au monde; c'est juste un exercice assez sympa qui aide à voir que la norme en usage n'est pas limitative, que le décimal n'est pas la seule façon de représenter les chiffres....

e.g. du style {h1} en HTML peut "être" de taille 12px ou de taille 24px selon le CSS

merci à vous deux pour les réponses!

Là, tu confonds deux choses. La programmation au sens strict (C, Fortran, Pascal...) qui est le fruit d'une (quasi-) bijection entre un algorithme et un programme et l'interprétation d'un contenu par un formateur de texte. Ton programme se suffit donc à lui-même alors que ton code html est interprété par un navigateur et ses feuilles de style par défaut. Le résultat n'est donc ni unique ni déterministe (au sens mathématique du terme).

Il me parle de code, le Grincheux!

Je ne suis pas sûr, pourtant, de bien confondre. (Je suis bien conscient qu'un document HTML ou CSS ou XML n'est qu'un module qui prépare son propre interprétation par des programmes plus "nobles", indépendent )

Même un HTML / CSS simple peut et doit être documenté avec les commentaires pour faciliter la modificiation et/ou (le cas écheant) le déboguage.

Sur le web de tous les jours -- je résume ce que j'ai compris -- la nobilité unique et déterministe réside du côté du PHP, puisque lui, tout seul, peut aller fouiller dans une BDD avec une SQL (structured query language) appropriée, pour ensuite génèrer des "fiches" HTML (non commentés en général) qui s'appuyeront sur le CSS sous-jacent¹ pour mettre en forme les données récupérées dans un format reconnaissable /interprétable par le navigateur.

Mais M. Grincheux, si je me souviens bien, n'aime pas trop PHP.

Je n'avais pas pensé aux difficultés liés au calcul de 16^-3. Ceci dit, c'est n'est pas une compétence nécessaire pour comprendre la répresentation des couleurs additives.²

Merci _yann, d'avoir avancé le débat et d'avoir cité CAML, que je ne connaissais pas!

Je relis tout ça maintenant :livre:

---

¹ e.g. tr.x-legendary:first-child = l'élément " fille ainée " d'un élément (rang de tableau -- table row) de la classe "x-legendary"
² Je m'excuse pour le "code-switching" d'un anglophone qui essaie tant bien que mal de se faire comprendre...

Le retour de l'informatique au lycée

Place de la Toile y a consacré l'émission du 01.09.2012
avec Gilles Dowek, INRIA
Alexis Kauffmann, Framasoft

http://media.radiofrance-podcast.net/podcast09/10465-01.09.2012-ITEMA_20396188-0.mp3

la dictée de xphrog

Il y a 20 ans quand l'enseignement de l'informatique s'est developé à l'université

[... digression ...]

Il y a eu des pressions similaires pour que les universités s'équipent en machines Windows, etc., bon, et on voit que cela a complètement échoué, c'est-à-dire, [pause], aujourd'hui, les universités sont l'endroit par excellence où la pénétration des outils Microsoft est la plus faible.

Et donc je crois que ce qui s'est passé à l'université va se passer de la même manière aux lycées et aux collèges.

Il y a une affinité naturelle des enseignants qui sont pauvres pour des produits qui sont peu chers.


--Gilles Dowek (vers 42:00)

<meta name="robots" content ="noindex, nofollow">