Re: Informatique en cycle 3/4: découvrons Scratch (récapitulatif tenu à jour de mes essais page 8)

par JPhMM Mer 30 Mar 2016 - 23:36

Pourquoi pas la courbe de Peano ? Very Happy

par Dw4rF_Naheulbeuk Jeu 31 Mar 2016 - 0:46

A votre avis, ça se programme en scratch un jeu de la vie ou pas?
Question subsidiaire: si oui est ce que ça présenterait un intérêt quelconque hormis le fait de parler d'un truc rigolo?

par ycombe Jeu 31 Mar 2016 - 6:18

JPhMM a écrit:Pourquoi pas la courbe de Peano ?

On peut générer toute la gamme, mais la courbe du dragon me rappelle Martin Gardner qui l'a popularisée et Donald Knuth qui l'a étudiée. Cela lui donne une saveur particulière pour moi.

par ycombe Jeu 31 Mar 2016 - 6:24

Dw4rF_Naheulbeuk a écrit:A votre avis, ça se programme en scratch un jeu de la vie ou pas?
Question subsidiaire: si oui est ce que ça présenterait un intérêt quelconque hormis le fait de parler d'un truc rigolo?

Ça se programme sans problème. Quand à l'intérêt, c'est toi qui vois.

Martin Gardner (il me semble) avait décrit une variante amusante, avec des requins et poissons. Les cases contiennent des requins et des poissons, mais je ne sais plus quelles étaient les règles de reproduction et disparition. Il faudrait que je retrouve ça mais ce sera pour plus tard, je n'ai pas accès à mes livres pour l'instant (ma maison ayant un peu brûlé fin janvier).

par Crichton Jeu 31 Mar 2016 - 8:43

ycombe a écrit:

Dw4rF_Naheulbeuk a écrit:A votre avis, ça se programme en scratch un jeu de la vie ou pas?
Question subsidiaire: si oui est ce que ça présenterait un intérêt quelconque hormis le fait de parler d'un truc rigolo?

Ça se programme sans problème. Quand à l'intérêt, c'est toi qui vois.

Ca se programme, j'en ai fait une version, pour "tester" scratch sur des exemples un peu plus consistants que le tracé d'un carré par un chat. C'est ici :
https://scratch.mit.edu/projects/103576385/
"Sans problème" je n'irai pas jusque là. En particulier, l'absence de tableaux à deux dimensions conduit à une gestion un peu lourde des listes. La version que je propose utilise des clones, donc hors "programmes du collège".

Amha trop complexe pour une classe du collège, mais pour montrer quelques possibilités de Scratch aux collègues, çà peut servir.

(Edit) Capture d'écran :
Informatique en cycle 3/4: découvrons Scratch (récapitulatif tenu à jour de mes essais page 8) - Page 10 Captur13

Informatique en cycle 3/4: découvrons Scratch (récapitulatif tenu à jour de mes essais page 8) - Page 10 Captur13

par William Foster Jeu 31 Mar 2016 - 14:19

Dw4rF_Naheulbeuk a écrit:A votre avis, ça se programme en scratch un jeu de la vie ou pas?
Question subsidiaire: si oui est ce que ça présenterait un intérêt quelconque hormis le fait de parler d'un truc rigolo?

Tout est possible, tout est réalisable, c'est le jeu de la vie... bounce

par William Foster Jeu 31 Mar 2016 - 14:21

JPhMM a écrit:Pourquoi pas la courbe de Peano ?

Tracée dans son intégralité ?

par VinZT Jeu 31 Mar 2016 - 16:43

Je vois que vous vous amusez bien :lol:

Chtites questions en passant:
- cela vous paraît faisable avec des élèves "normaux" ?
- cela vous paraît à même de les faire progresser tant en math qu'en info ?
- les "compétences" acquises avec Scratch vous semblent-elles transposables à d'autres langages informatiques ?

Nulle polémique dans ces questions, mais je m'interroge.
Cela me rappelle les savantes constructions et animations faites avec GeoGebra (ou Cabri ou autre), intéressantes lors de colloques IREM ou de réunion avec pairs (et encore), mais ... avec les élèves ? Si cela se résume à des activités "cliquodromes" où on se contente de suivre une check list, quel intérêt ?

par Al9 Jeu 31 Mar 2016 - 18:05

Même constat que VinZT, c'est bien joli toussa.

Pour en avoir fait un peu cette année, tout se qui est proposé est infaisable avec les élèves. C'est beaucoup trop compliqué.
Quand il faut presque 1 heure pour de très bons élèves pour sortir d'un labyrinthe alors, manipuler les listes et des tonnes de variables Razz

.

Créer une table de multiplication avec Scratch c'est déjà difficile pour 90% d'entre eux donc...

par sandelan Jeu 31 Mar 2016 - 19:26

Scratch n'est pas un langage de programmation !!!
Cela permet de mettre en œuvre un algorithme mais en aucun cas il faut parler de langage de programmation.
Dans un vrai langage de programmation, tout est structuré, avec des fonctions et des procédures par exemple. On peut mettre également des commentaires.
Et surtout, on écrit les lignes de code.
Cela demande entre autre de la rigueur. A la moindre erreur, ça ne fonctionne pas mais une indication sur l'erreur commise est en général donnée pour se corriger.
Pour moi, scratch donne juste l'illusion de programmer mais en fait, on en est loin.

par William Foster Jeu 31 Mar 2016 - 19:37

Bien sûr qu'on n'est pas dans de la programmation pure et dure avec lignes de code... bounce

Mais pour la rigueur, c'est un bon début pour des élèves de 6° (pas encore testé sur les 3°) puisqu'ils doivent comprendre comment fonctionne l'algorithme, que l'ordre des commandes est capital (même si parfois on peut en inverser sans gravité), et surtout ça leur permet de voir et d'expliquer certains "bugs" : ne pouvant aider tous les élèves simultanément, les élèves comparent seuls leurs programmes et cherchent des solutions sans attendre que je les leur donne. Je trouve ça très formateur pour l'esprit "info".

Mais (parce qu'il y a un GROS "mais") je n'ai que 20 élèves, que des "bons", que des 6° motivés, et 2h par semaine en dehors des cours de maths.
Quand il faudra faire la même chose avec des 3° dont la moitié (au moins) est nihiliste, en 3h dans l'année, tout en leur faisant faire des maths sérieuses, avec plus de 2 élèves par ordi... Ce sera moins fun :|

par Balthazaard Jeu 31 Mar 2016 - 19:41

William Foster a écrit:

JPhMM a écrit:Pourquoi pas la courbe de Peano ?

Tracée dans son intégralité ?

Dans l'intégralité, on peut essayer rectfill() ou un truc de ce genre.

Blague à part, je ne trouve pas scratch intuitif du tout et les algorithmes écrits quasiment illisibles quand il y a un minimum d'imbrication. Quitte à apprendre quelque chose, les vrais langages ne manquent pas

par VinZT Jeu 31 Mar 2016 - 20:03

Balthazaard a écrit:Blague à part, je ne trouve pas scratch intuitif du tout et les algorithmes écrits quasiment illisibles quand il y a un minimum d'imbrication. Quitte à apprendre quelque chose, les vrais langages ne manquent pas

Là est la question, s'agit-il d'apprendre quelque chose aux élèves, ou de les occuper en leur faisant croire qu'ils sont des programmeurs ?

par JPhMM Jeu 31 Mar 2016 - 20:07

Autant pythoner.

par Le grincheux Jeu 31 Mar 2016 - 20:17

JPhMM a écrit:Autant pythoner.

Informatique en cycle 3/4: découvrons Scratch (récapitulatif tenu à jour de mes essais page 8) - Page 10 912711202

On n'est pas contraint non plus d'échanger la peste contre le coryza. Des pythoneux, j'en vois passer. Déjà, lorsqu'on maîtrise la programmation, c'est un langage casse-gueule (RedHat s'en souvient encore... GDF-Suez aussi d'ailleurs pour la même raison...), alors en tant que débutant...

Pour avoir donné des cours de programmation, on devrait toujours commencer par un langage procédural ou fonctionnel impur. Certainement pas par un impératif ou, pire, un objet. En ce sens, commencer par Python est une aberration lorsqu'on ne sait pas comment fonctionne un calculateur. Et c'est d'autant plus casse-gueule que ce langage mélange allègrement le fond et la forme. Un débutant a besoin de voir des blocs, indentés et parfaitement délimités de façon explicite. Rajouter la portée des blocs dans l'indentation est le meilleur moyen de perdre la moitié d'une classe surtout lorsqu'ils mélangent les espaces et les tabulations et que les éditeurs font leur sauce de leur côté.

Les meilleurs résultats que j'ai eu, c'était en faisant bosser les étudiants (Bac+3/4) sur du Fortran77. Ça oblige à réfléchir, la syntaxe est claire et il n'y a aucune chausse-trappe.

par JPhMM Jeu 31 Mar 2016 - 20:24

On parle de collégiens, là...

par Hélips Jeu 31 Mar 2016 - 20:25

@LeGrincheux : avec mes ISN, Python, ça marche pas mal du tout. Justement l'histoire de l'indentation qui n'est pas seulement un problème de forme, ça les oblige à écrire les trucs proprement.

par Le grincheux Jeu 31 Mar 2016 - 20:27

JPhMM a écrit:On parle de collégiens, là...

Justement. Il leur faut des choses simples et aisément compréhensibles. Scratch n'entre ni dans l'un ni dans l'autre des catégories. Python non plus d'ailleurs.

Ce qui m'a d'ailleurs toujours fasciné, c'est la haine qu'éprouvent la plupart des programmeurs pour les Basic's et leur propension à utiliser Python alors qu'objectivement, on peut reprocher aux deux langages exactement les mêmes choses. Enfin, il y a bien des gens pour utiliser Java...

par Le grincheux Jeu 31 Mar 2016 - 20:34

Hélips a écrit:@LeGrincheux : avec mes ISN, Python, ça marche pas mal du tout. Justement l'histoire de l'indentation qui n'est pas seulement un problème de forme, ça les oblige à écrire les trucs proprement.

Le problème de l'indentation est un problème parce que cela mélange la forme et le fond et qu'un éditeur chafouin peut faire des choses rigolotes sur cette indentation. Ce n'est pas parce qu'on utilise autre chose que Python qu'il ne faut pas indenter. Personnellement, je refusais de corriger des programmes non indentés (et les bouts de C écrit avec autre chose que l'indentation d'Allman).

Dans un bon langage de programmation, il n'y a rien d'implicite. Typiquement en Fortran, on commence par un beau

Code:: IMPLICIT NONE

, en ADA, c'est encore pire puisque mêmes les cast sont explicites. En Python, rien de tout cela. Pire, on a une inférence de type complètement foireuse qui fait que même en faisant attention, on finit toujours par se tirer une balle dans le pied. Python, ça va lorsqu'on a dix lignes de code à écrire "à l'arrache". Mais le problème est que les gens qui ont débuté avec ça considèrent qu'on peut tout faire avec ce sale truc. Et on se retrouve avec des projets complets écrits en Python et totalement non maintenables.

par ben2510 Jeu 31 Mar 2016 - 20:35

Je pense qu'un peu de Scratch en CM2/6e/5e c'est bien, et qu'ensuite on peut passer à autre chose, typiquement Python.
Un troisième qui aurait commencé Scratch en CM2 risque de vomir si on lui en remet encore une couche pour la cinquième année consécutive.
Pour autant il faut se méfier, il y a toujours un écat énorme entre ce qu'on enseigne et ce que les élèves s'approprient vraiment...

Peut-être qu'une librairie python qui reprend certaines fonctionnalités de Scratch...

par Le grincheux Jeu 31 Mar 2016 - 20:41

Il y a tout de même une chose qu'il faudrait que l'on m'explique. Pourquoi mettre Python à toutes les sauces ? Ce langage est une calamité, il fait prendre tout un tas de mauvaises habitudes (sauf l'indentation, je l'admets).

C'est une vraie question. Je connais Python (et d'autres langages), j'ai fait du design et de l'implantation de langages, donc je me suis posé un certain nombre de questions sur le sujet depuis une vingtaine d'années... Mais Python n'est pas le seul langage dans ce cas, il y en a d'autres du même tonneau.

par JPhMM Jeu 31 Mar 2016 - 20:55

Le grincheux a écrit:

JPhMM a écrit:On parle de collégiens, là...

Justement. Il leur faut des choses simples et aisément compréhensibles. Scratch n'entre ni dans l'un ni dans l'autre des catégories. Python non plus d'ailleurs.

Ce qui m'a d'ailleurs toujours fasciné, c'est la haine qu'éprouvent la plupart des programmeurs pour les Basic's et leur propension à utiliser Python alors qu'objectivement, on peut reprocher aux deux langages exactement les mêmes choses. Enfin, il y a bien des gens pour utiliser Java...

A titre personnel, j'adorerais leur faire faire du Locomative Basic. Un bonheur ce langage !

par ycombe Jeu 31 Mar 2016 - 21:12

VinZT a écrit:Je vois que vous vous amusez bien :lol:

Chtites questions en passant:
- cela vous paraît faisable avec des élèves "normaux" ?
- cela vous paraît à même de les faire progresser tant en math qu'en info ?
- les "compétences" acquises avec Scratch vous semblent-elles transposables à d'autres langages informatiques ?

Nulle polémique dans ces questions, mais je m'interroge.
Cela me rappelle les savantes constructions et animations faites avec GeoGebra (ou Cabri ou autre), intéressantes lors de colloques IREM ou de réunion avec pairs (et encore), mais ... avec les élèves ? Si cela se résume à des activités "cliquodromes" où on se contente de suivre une check list, quel intérêt ?

C'est gentil de nous ramener sur terre Razz

Tu as mille fois raison.

Avec des élèves normaux, c'est à dire y compris les 47 % qui ne rentrent actuellement ni dans l'algèbre, ni dans la démonstration, il est attendu ce genre de chose:
https://scratch.mit.edu/projects/103664153/
Informatique en cycle 3/4: découvrons Scratch (récapitulatif tenu à jour de mes essais page 8) - Page 10 Pong10

Informatique en cycle 3/4: découvrons Scratch (récapitulatif tenu à jour de mes essais page 8) - Page 10 Pong10

Voici l'explication du document d'accompagnement:

Le professeur peut choisir ce type d’activité avec différents objectifs : travailler la notion de direction angulaire relative ou absolue, découvrir et utiliser les constructions conditionnelles, découvrir et utiliser des variables, programmer une gestion d’événements.
Selon le(s) choix qu’il effectue, il développera plus tel ou tel aspect de l’activité, proposera des défis différents aux élèves, prolongera l’activité suivant diverses directions.
On peut commencer par une activité concernant le rebond sur les bords d’une balle. Il vaut mieux choisir pour commencer un lutin dont la direction est immédiatement visible (le chat, une flèche), et reporter à plus tard l’utilisation d’un lutin en forme de balle. De la même façon, il est sans doute utile d’afficher la direction du lutin (en cochant la case appropriée tout en bas de la catégorie « Mouvement »).
Une répétition infinie de avancer de 10 , rebondir si le bord est atteint , permet alors l’observation de ce qui se passe aux bords : un objectif est que les élèves conjecturent les règles de changement de direction.
On peut alors proposer un défi, qui est de réaliser le même processus, mais sans utiliser le bloc rebondir si le bord est atteint. Il faut toutefois prendre garde à repérer l’approche des bords, en ajoutant des répétitions infinies de test sur l’abscisse (inférieure à -215 ou supérieure à 215) et sur l’ordonnée. Ce défi n’est pas si simple pour des élèves inexpérimentés.
On ajoute deux raquettes (que les élèves peuvent dessiner, un simple rectangle suffit). On pensera à les nommer de façon explicite, raquette gauche et raquette droite, par exemple. Il n’est pas très difficile d’associer à chaque raquette un script qui permet à l’utilisateur de la faire monter ou descendre, à l’appui d’une touche ou d’une autre. Il faudra donc choisir quatre touches différentes du clavier, pour le joueur gauche et le joueur droit.
Il s’agit là d’une programmation événementielle très simple à mettre en œuvre. Pour l’instant, la balle et les raquettes agissent sans aucune interaction.
Il convient maintenant de gérer le rebond de la balle sur chaque raquette.
Pour cela on crée une boucle infinie qui teste le contact à l’aide du premier bloc de la catégorie « Capteurs ». Si la raquette gauche est touchée, il suffit de changer la direction de la balle en l’opposé de la direction actuelle. Remarquons que puisqu’il s’agit de modifier la direction de la balle, c’est bien sur le script de la balle qu’il faut travailler, et non sur celui de la raquette!
C’est un objectif important que les élèves comprennent bien quelles commandes sont à écrire dans le script de la balle et quelles autres dans celui de chaque raquette : on introduit ici des concepts liés à la programmation-objet, sans avoir pour autant besoin du moindre formalisme. Une autre remarque s’impose ici : on peut bien sûr créer un unique script long et compliqué pour la balle, mais il est sans doute plus simple de créer plusieurs scripts associés chacun à un comportement particulier : le déplacement perpétuel sur le terrain de jeu, la gestion du rebond sur les bords (si on ne veut pas utiliser la commande ), le contact avec la raquette gauche, le contact avec la raquette droite. Cela introduit à la fois la notion de programmation d’actions en parallèle et permet une mise au point beaucoup plus facile des programmes.

Je passe les prolongements proposés, tout cela semble assez irréaliste.

par User25249 Jeu 31 Mar 2016 - 21:59

William Foster a écrit:Bien sûr qu'on n'est pas dans de la programmation pure et dure avec lignes de code...
Mais pour la rigueur, c'est un bon début pour des élèves de 6° (pas encore testé sur les 3°) puisqu'ils doivent comprendre comment fonctionne l'algorithme, que l'ordre des commandes est capital (même si parfois on peut en inverser sans gravité), et surtout ça leur permet de voir et d'expliquer certains "bugs" : ne pouvant aider tous les élèves simultanément, les élèves comparent seuls leurs programmes et cherchent des solutions sans attendre que je les leur donne. Je trouve ça très formateur pour l'esprit "info".

Mais (parce qu'il y a un GROS "mais") je n'ai que 20 élèves, que des "bons", que des 6° motivés, et 2h par semaine en dehors des cours de maths.
Quand il faudra faire la même chose avec des 3° dont la moitié (au moins) est nihiliste, en 3h dans l'année, tout en leur faisant faire des maths sérieuses, avec plus de 2 élèves par ordi... Ce sera moins fun :|

Si c'est que 3h dans l'année, il n'y a plus qu'à caser ça sur la dernière semaine de juin, et on en parle plus. On est libre de notre progression, que je sache. A cette période, il devrait y avoir de la place en salle info.

par William Foster Jeu 31 Mar 2016 - 22:13

Stéphane60150 a écrit:Si c'est que 3h dans l'année, il n'y a plus qu'à caser ça sur la dernière semaine de juin, et on en parle plus. On est libre de notre progression, que je sache. A cette période, il devrait y avoir de la place en salle info.

Sauf que le jour où tu vas en salle info en fin d'année, tu peux être sûr que y'a un paquet d'ordis en carafe, et le travail en binôme se transforme en travail en trinôme (sans second degré).
Faire ça à l'arrache, en fin d'année, ou sur une semaine boiteuse (genre tu viens de finir un chapitre et il reste 3h à caser avant les vacances de Nowel) c'est sans doute ce que feront beaucoup de collègues. Je ne les blâme pas, les IPR n'ayant pas réussi à être très convaincants sur le bien-fondé de ce chapitre. Mais je ne puis me résoudre à bâcler une partie de mes cours, et je chercherai à donner quelque utilité au bouzin.

Dernière objection pour ne pas garder ça pour la dernière semaine de juin : c'est censé être au brevet... Donc autant le faire avant l'épreuve...

par User25249 Jeu 31 Mar 2016 - 22:35

William Foster a écrit:

Stéphane60150 a écrit:Si c'est que 3h dans l'année, il n'y a plus qu'à caser ça sur la dernière semaine de juin, et on en parle plus. On est libre de notre progression, que je sache. A cette période, il devrait y avoir de la place en salle info.

Sauf que le jour où tu vas en salle info en fin d'année, tu peux être sûr que y'a un paquet d'ordis en carafe, et le travail en binôme se transforme en travail en trinôme (sans second degré).
Faire ça à l'arrache, en fin d'année, ou sur une semaine boiteuse (genre tu viens de finir un chapitre et il reste 3h à caser avant les vacances de Nowel) c'est sans doute ce que feront beaucoup de collègues. Je ne les blâme pas, les IPR n'ayant pas réussi à être très convaincants sur le bien-fondé de ce chapitre. Mais je ne puis me résoudre à bâcler une partie de mes cours, et je chercherai à donner quelque utilité au bouzin.

Dernière objection pour ne pas garder ça pour la dernière semaine de juin : c'est censé être au brevet... Donc autant le faire avant l'épreuve...

Tu n'as pas tort, quitte à faire les choses, autant bien le faire. Le problème, c'est que si on lit les programmes, on se rend compte qu'en fait, le but, c'est de faire un peu d'algo, mais surtout pas de la vraie, un peu de math, mais pas trop, et qu'en fait, le programme veut faire faire du scratch aux élèves, pour faire... Du scratch ! Pour qu'en fait; les élèves "ne s'ennuient plus (sic)", et là, on est bien dans l'esprit de la réforme...

J'ai rien contre l'informatique, ayant été moi-même dans le métier pendant dix ans. Mais quand on voit l'état de décrépitude du niveau des élèves, encore 3h de perdu en math, c'est trop. Alors que l'algo, à défaut de matière spécifique informatique, ça peut bien se faire en techno (j'étais prof de techno l'an dernier, j'ai expérimenté scratch sur les 4 niveaux du collège).

Alors voilà, mon propos était de donner une idée de résistance passive... Mais bon s'ils en mettent au brevet, va falloir s'y mettre. Sad