Les concepts mathématiques, qui a priori modèlisent le monde sensible, se construisent hors du temps et de l’espace, même s’ils y sont spontanément réinjectés pour leur enseignement. Avec l’utilisation de Scratch au collège, l’algorithmique s’illustre par une programmation qui se place d’emblée dans une interface fortement temporelle. Au moment où un mouvement de réappropriation mathématique de la notion d’algorithme émerge, dans les directive des nouvelles écritures des algorithmes, il est intéressant de prendre ... le temps ... d’analyser les possibilités « temporelles » d’une interface de programmation par bloc « a-temporelle », qui réagit en temps réel.
Les mathématiques ont mis du temps pour construire ses concepts de manière intrinsèque et les dégager du monde sensible d’où ils viennent et qu’ils servent - éventuellement - à modéliser. Par exemple, très tôt (Euclide) la géométrie a pris conscience de la nécessité de se dégager du mouvement pour pouvoir parler d’isométries. Les Éléments d’Euclide utilisent une seule fois une translation. De même l’analyse a dû se dégager du temps pour construire la notion de fonction indépendamment de la cinématique du point.
D’un point de vue un peu plus philosophique, il s’agit de l’importance de la réification des objets d’étude, au sens de les rendre indépendant de ce qui les a fait émerger. C’était en particulier très présent chez Frege, à partir de 1904, justement sur l’évacuation du temps. Plus généralement, en science, on estime que c’est une condition nécessaire (indépendance de la source et du contexte) pour qu’une connaissance individuelle puisse devenir un savoir collectif transférable.
Pourtant, depuis l’utilisation des TICE en mathématiques, dés que l’on fait bouger un point sur une courbe dans un grapheur ou un logiciel de géométrie dynamique, que ce soit pour illustrer un sens de variation ou le lien entre dérivée en un point et tangente à une une courbe par exemple, on réintroduit la réflexion fonctionnelle dans un environnement temporel. Même si c’est sans doute « moins mathématique », cela donne incontestablement une opportunité pour rentrer plus simplement dans les concepts. La démarche didactique accompagne ainsi une réflexion épistémologique qui donne du sens à l’historicité des objets mathématiques, et à la science en général. Tous les enseignants d’un certain âge, qui ont accompagné la transition numérique en classe ont entendu régulièrement cette réflexion : « mais comment vous faisiez avant ? », dont cette fameuse perle (en CM2) qui dit l’intemporalité du monde chez certains enfants : « Vous n’aviez pas d’ordinateur ? Mais comment on faisait pour aller sur internet ? ».
Une spécificité des mathématiques et son induction un peu précoce
Rappel technique : On écrit $\lim_{n \to +\infty}u_n=0$ pour rendre compte de cette définition :
Pour tout $\epsilon>0$, il existe un entier $n_0$ tel que pour tout entier $n>n_0$, alors $|u_n| < \epsilon$.
Ce que l’on peut noter ici, pour notre propos, c’est que, quelque soit le vocabulaire temporel ou spatial utilisé par un enseignant pour parler de géométrie ou d’analyse, de par sa formation, celui-ci est conceptuellement clair.
Par exemple, il sait que, dans la définition même d’une limite, il n’y a rien qui "tend vers 0" quand on dit que la suite $(u_n)$ définie par $u_n=\frac{1}{n}$ "admet 0 comme limite" même si comme tout un chacun, par habitude culturelle, mais aussi pour "donner à voir" par exemple avec une illustration numérique, il pourra dire que "la suite tend vers 0". Chacun aura à l’esprit de nombreux autres exemples, y compris en géométrie.
L’idée sous-jacente à l’origine de cet article, issue d’une observation des pratiques en classe des jeunes stagiaires M2 MEEF, est que cette clarté conceptuelle, assez souvent, est implicitement comme induite sur le champ de l’algorithmique. Tout se passe comme si l’appropriation simple et immédiate de la programmation par bloc (Scratch) par les jeunes enseignants, enrichie de leurs pratiques naturelles des changements de cadre, nouveaux et si pertinents, entre mathématique et algorithmique, confortait, toujours implicitement, les choix institutionnels de la programmation par blocs, les outils utilisés et au final, c’est ce qui nous intéresse ici, leurs interfaces.
L’aisance conceptuelle en mathématique nous permet, pour des questions didactiques, et en toute connaissance de causes, des « abus de langage », alors que notre aisance opérationnelle sur les nouvelles approches « de codage » semble rendre transparente la nécessité d’une réflexion plus approfondie sur les enjeux de représentations mentales que véhiculent les interfaces utilisées.
Retrouver et l’utiliser temporellement le temps réel
L’algorithmique telle qu’elle est pratiquée en début de collège est souvent très liée au temps, ne serait-ce que parce que l’on pratique par étape, quasiment pas à pas en début de cycle 4. On voit le lutin avancer, faire une étape de plus quand on ajoute quelques lignes à notre programme. Cette démarche, tout à fait naturelle, par apprentissage séquentiel, peut produire par ailleurs des représentations mentales chez les élèves mais aussi les enseignants assez loin de ce qui pourrait être attendu.
Or il est possible de faire de la programmation visuelle dynamique, y compris à la tortue, avec un résultat en temps réel, c’est-à-dire, finalement, hors temps et donc respectant la réification que l’on attend des concepts mathématiques ^plongés dans un environnement algorithmique.
Dans cet article, on se propose d’explorer, sur la base de cet outil en temps réel de reproduire - pour des raisons pédagogiques - les différents états temporels possibles.
Si cet article va détailler parfois, pour les personnes plus concernées par ce sujet, les méthodes précises utilisées pour arriver à ces résultats, l’objectif principal reste essentiellement de sensibiliser à la problématique générale du rapport au temps que l’on induit implicitement dans les pratiques de programmation au collège, et montrer que l’on peut travailler autrement.
Le temps réel avec Scratch
Le temps réel avec des clones
Tout d’abord, voyons qu’il est très simple de produire des figures qui s’actualisent en temps réel avec Scratch. Dans un article précédent (onglet 3 « aspect dynamique »), nous avions déjà détaillé comment Florian Tobé a utilisé les clones pour rendre des figures dynamiques au curseur., tout d’abord avec cette parabole dynamique, puis, surtout, avec ce coeur de tournesol dynamique. Dans les deux cas déplacer le curseur.
Alain Busser avait alors exploré une application à la géométrie dynamique avec Scratch en réalisant le milieu dynamique de deux points et puis l’isobarycentre de n points.
Le temps réel avec des blocs
Mais les clones ne sont pas au programme de collège. On peut proposer, en fin de collège, de réaliser des figures dynamiques plus simplement, avec la création de blocs. Voyons l’exemple d’un polygone régulier.
Dans cette écriture, il n’y a de mise à jour que dans quand on clique sur le drapeau vert.
Expérimenter ce programme en ligne.
Or on aimerait une mise à jour en temps réel, quand on modifie au curseur le nombre de côtés.
Étant souvent sur des projets autour de DGPad, j’avoue n’apprendre sur Scratch que quand je propose des projets à mes étudiants. Pour cet article, j’avais lancé l’idée de regarder ce qu’il pouvait être fait sur ce polygone, pour avoir le temps réel sur le curseur. Et bien entendu, un stagiaire (Ansfrid Geffroy que je remercie encore pour cette porte ouverte vers le dynamisme) a rapidement trouvé.
Il suffit en effet d’utiliser l’option « Exécuter sans rafraichissement de l’écran » des blocs que nous créons,
et de placer le bloc en question dans une boucle infinie.
Et cela suffit ! Explorer cette possibilité en ligne en manipulant le curseur du nombre de côtés.
Autre exemple : les spirolatères
MathémaTICE a déjà publié un article sur les spirolatères, avec un plan allant d’une utilisation au primaire, en passant par une utilisation en collège (largement détaillé) pour terminer par une réflexion sur spirolatères dynamiques avec l’origine et l’extrémité en manipulation directe et construction générique pour un angle et une liste de pas quelconques. On utilise alors que la trace d’une tortue peut être interprétée comme somme de nombres complexes, ce qui permet de faire beaucoup de choses (pour classe terminale ou au delà).
Sans tout reprendre, en particulier la fin qui serait peut-être possible avec les techniques de Alain Busser (les deux points dynamiques), on peut utiliser le principe précédent pour des cas générés dynamiquement par curseur. C’est déjà en soi intéressant.
Dans la réalisation élémentaire suivante, on s’intéresse à un spirolatère dit standard construit sur le liste [1, 2, 3, 4, 5], autrement dit les côtés sont des multiples de ces 5 nombres, et dans cet ordre ; standard mais d’angle quelconque et non 90°. On ajuste alors, manuellement, le nombre d’itérations (n) en fonction de l’angle choisi pour que le spirolatère se referme. Dans l’article cité n est calculé à partir d’un PGCD, on pourrait aussi le reprendre, bien entendu. Là on a choisi d’être rapide pour se centrer sur de l’élémentaire. Le tout est tracé en temps réel.
a. Le code
b. Quatre exemples, avec 5 dans la boucle interne, pour le motif de longueurs [1, 2, 3, 4, 5]. On ajuste la variable longbase et la position de départ pour que tout rentre à l’écran (20 ou 30 pixels par exemple pour longbase).
c. Deux exemples avec la boucle interne réglée à 4, donc des motifs de base à 4 branches et non plus 5 comme ci-dessus.
d. Stabilité et statut de la boucle infinie. La figure est stable. Bien entendu dira-t-on, mais pourtant on peut se demander pourquoi. Le programme principal consiste donc à appliquer un bloc, ici « spiro » - qui est le vrai programme - dans une boucle infinie pour que l’on puisse utiliser le temps réel sur l’angle en « ne rafraichissant pas l’écran », ce qui pose peut-être des questions de traduction.
Certains collègues refusent d’utiliser les boucles infinies car c’est le contraire d’un algorithme qui est associé à « un nombre fini d’étapes ». D’autres l’utilisent sans vergogne en argumentant que ce n’est pas tant une boucle infinie qu’une simple variante du « when idle() » de la boucle évènementielle.
Toujours est-il que ce n’est pas innocent d’utiliser cette boucle pour obtenir une construction en temps réel. Pour en prendre conscience, enlever la commande « s’orienter à 90° » du bloc spiro (et même le « goto » pour que ce soit parfois plus joli) : quand les valeurs de n et de l’angle ferment la figure, elle est naturellement stable, mais sinon, quand la tortue ne se retrouve pas au point de départ, elle n’est pas dans la bonne direction, on voit alors l’effet réel de la boule infinie : la figure tourne car elle est dessinée en permanence depuis la position et la direction de la tortue. On a donc une animation continue d’une figure incomplète, démarche qui peut éventuellement être utilisée pour d’autres activités, même si on s’éloigne probablement de l’attitude algorithmique initiale.
Voir la figure précédente en ligne sans l’orientation, ni le goto et agir sur les curseurs (mettre 54°, 63°, 68°, 72° et d’autres valeurs.
La même figure avec le goto, pour voir rapidement la différence. On comprendra qu’on tourne sur « le polygone des extrémités » avec le vocabulaire de l’article initial sur les spirolatères.
Ces quelques exemples très simples questionnent vraiment le statut de la boucle infinie. Est-elle interne au programme (les tenant du idle()) ? Et dans ce cas, on met le bloc d’orientation et on ne s’autorise pas à l’enlever pour jouer avec pour des rotations. Ou bien est-elle déjà une partie des effets de bords comme appartenant à la console de sortie ? Dans ce cas, on pourrait (peut-être) jouer avec la sortie. Le choix semble assez délicat.
Je retiens aussi de ces premières explorations que, même s’il est très simple de faire ce qui précède, et même si c’est intéressant en soi, Scratch n’est peut-être pas fait pour le temps réel géré de cette façon pour les questions soulevées par la boucle infinie.
Voyons maintenant ce que cela donne avec un logiciel qui incorpore le temps réel de la trace du lutin (ici d’une tortue) dans son propre ADN.
Trois temporalités sur la construction du polygone régulier
Rappel sur le Blockly de DGPad
On poursuit donc avec le Blockly de DGPad (dont une présentation très - trop ? - détaillée est disponible ici). Pour être bref, disons que tout y est en temps réel, y compris au plus profond de l’interface comme la roue des angles, ce qui permet de proposer aux élèves, sur des situations simples d’apprendre à « réfléchir en manipulation directe ». Cela semble conforme à une représentation mentale de l’algorithme plus proche de ce qu’on en attend en mathématique au sens où un algorithme « ne fait rien » en interne (ne parcourt pas une trajectoire par exemple) mais rend un résultat : la trace de la tortue. L’option choisie par l’auteur du logiciel, à savoir que la trace s’ajuste instantanément quand l’algorithme est modifié participe de l’ancrage de cette représentation là.
Autre illustration, le cas de l’aléatoire mis à toujours dés qu’il se passe quelque chose à l’écran. Exemple d’un spirolatère construit avec un cycle initial aléatoire. Dans cette figure vous pouvez déplacer le point A, mais aussi tout simplement déplacer la souris (appuyée) à l’écran. Penser aussi modifier l’angle et la taille du cycle initial.
Le principe d’une utilisation de l’a-temporalité pour illustrer divers temporalités
On s’intéresse désormais à la possibilité d’utiliser cette instantanéité de la tortue de DGPad pour explorer des niveaux différents de temporalité dans le rendu de la construction.
Sur la figure suivante, nous allons regarder comment peuvent être construits les segments de manière séquentielle, puis de manière continue dans cet environnement « temps réel ».
Commencer par regarder cette figure : https://huit.re/S1031Poly3tempo
D’abord en mode standard (en arrêtant l’animation ou non) : cela se passe comme la version Scratch précédente (inspirée de cette situation). Puis manipuler la figure dans les modes discret et continu, avec l’animation active, y compris en modifiant le nombre n (de côtés) pendant l’animation.
Le principe : un compteur est incrémenté dans le code et la figure se construit selon que ce compteur est supérieur ou non au curseur d’animation, qui représente le temps. La situation est simple dans le cas discret, un peu plus subtile dans le cas continu.
Procédure principale : après une initialisation qui définie la variable dAB et initialise le compteur à 0, le choix de l’approche temporelle est contenu dans le parcours des n côtés du polygone. En dehors du cas dynamique, standard, on altère le fonctionnement usuel par deux procédures AvanceDiscrete et AvanceContinue.
On notera le « sinon » du cas continu, qui construit le nombre de côtés associés à la partie entière des itérations déjà passées quand le « alors » de la condition dessine la partie décimale « en cours ». La partie « sinon » illustre bien la traduction algorithmique du fait que l’affichage de la tortue s’effectue en temps réel. Si on modifie le nombre de côtés, la figure est mise à jour car la borne du curseur temporel est fonction de cette donnée. La borne est (n+1).
Une quatrième temporalité
Nous allons ajouter un degré supplémentaire de temporalité. Pour cela nous reprenons une figure de Patrice Debrabant, auteur régulier de MathémaTICE. Il y a quelques mois, Patrice m’avait demandé si je pouvais faire une figure dynamiques de ses dalhias. Comme je réfléchissais déjà à cet article, j’en ai profité pour en faire une version quadri-temporelle que nous allons explorer ici, sas approche technique, juste pour inviter à une réflexion sur l’usage de cette temporalité.
A noter que depuis Patrice a fait des outils 3D pour les scripts de CaRMetal qui vont au delà de ce que l’on pourrait faire avec DGPad (gestion de la transparence 3D). Voir ses Dalhias 3D. Pour les manipuler il faut télécharger la dernière version de CaRMetal.
Les Dalhias standard
Commencer par explorer cette figure : https://huit.re/S1031dalhiaGene
La figure contient une animation : bien entendu la rotation par défaut n’a rien à voir avec celle des spirolatères avec Scratch, elle est volontaire, et on peut l’arrêter par le bouton en bas en gauche.
On prendra le temps d’observer que le point de contact des polygones peut varier selon le nombre de pétales. Par exemple pour les pentagones et les octogones, s’il y a deux fois plus de pétales que de côtés, les pétales ont un côté commun, il faut donc changer de point de contact en dessus et au dessous de cette valeur comme ici pour le cas des octogones.
Plus surprenant peut-être, le cas des heptagones :
En dehors des cas de polygones à 5, 7 ou 8 côtés, il y a un autre cas de changement de point de contact entre les pétales. Vous le trouverez facilement.
Réaliser cette première figure demande assurément un peu réflexion, mais comme ce n’est pas l’essentiel ici, nous n’insisterons pas sur sa réalisation.
Néanmoins, pour les lecteurs curieux de cette construction ou pour celles et ceux qui voudraient en apprendre un peu plus sur les possibilités utilisé du logiciel, quelques points structurels de la démarche utilisée sont détaillés dans le bloc dépliable suivant.
Comment cette figure est-elle réalisée ?
Il y a bien entendu de nombreuses façons d’aborder cette construction. La façon dont celle-ci est faite est originale, utilisant pleinement la remarquable souplesse du Blockly de DGPad.
La figure est construite sur un cercle de centre O (nom caché) passant par un point T (pour la taille de la figure). L’essentiel de la figure est construite en Blockly dont le code est dans le centre du cercle.
Néanmoins une partie préliminaire essentielle de la figure, la construction du point de contact U entre les deux polygones de la première couronne, est construite en Blockly avec un code placé dans le point T.
1. Détermination de l’indice du sommet de contact.
On voit sur l’illustration suivante un point M, puis le point U intersection de la droite (TM) et de la droite de l’angle au centre lié au nombre de pétales ( demi angle de 30° pour 6 pétales, angle nommé theta2 dans la suite pour theta/2)). Ce point U est le point de contact entre les polygones dont un sommet est T et le polygone suivant.
Le code de cette illustration détermine l’indice du sommet de polygone régulier qui sera le point de contact. Patrice Debrabant a repéré que c’est, en général, le nombre de côtés divisé par 3. Comme on a ajouté des curseurs assez larges, il faut un peu adapter cela en fonction des conditions : c’est ce que fait ce code, puis il appelle la procédure PolyCote1 qui va fixer le point M.
2. Placement du point M
Nous sommes toujours dans le code Blockly du point T. On rappelle que dans DGPad, Blockly est un comportement, c’est-à-dire que le code peut modifier la position d’un point mais ne construit pas de points (contrairement à ce que fait le récent GeoBlockly mais qui perd alors - nécessairement - la manipulation directe). Le point M est donc un point de base (que vous pouvez déplacer en le rendant visible par l’outil cacher/montrer. La seconde procédure PolyCote1 va donc placer le point M dans la bonne position.
La procédure simule (le crayon est levé) le début de construction d’un polygone régulier de côté 1, plus précisément on s’arrête au nombre de sommets déterminé (TronkPoly) par le code précédent.
Cette procédure place donc le point M à la position voulue, pour un polygone fictif de côté 1.
Note : en rendant le point M visible, vous pouvez le déplacer car ce n’est pas un point construit, mais juste placé par codage. La figure est alors fausse bien entendu. Mais il suffit de déplacer T ou de modifier un des curseurs pour replacer M en bonne position. C’est toute la subtilité du Blockly de DGPad qui permet ainsi des choses extraordinaires sur le déterminisme par exemple (détaillé à la fin de cet article et plus encore dans l’iBook signalé en fin d’article).
3. Initialisation de la figure et procédure principale
Tout le reste de la figure est construit par Blockly dans le point O.
Voici la procédure principale (n est la profondeur, le nombre de couronnes) et surtout la procédure d’initialisation qui fixe les variables globales principales.
On fixe essentiellement des variables globales. On remarquera Rsuiv, le rayon du cercle circonscrit à la couronne en cours, initialisée au rayon du cercle (R=OT), la variable AB (pour passer d’un polygone au suivant) et surtout le côté du polygone régulier cpoly calculé à partir des points T, M et U placés et construits précédemment.
La procédure place la tortue en A le point animé pour une figure un peu plus sympathique.
La procédure principale répète le fait de faire un tour (une couronne) et de changer de niveau.
4. La construction d’un tour et la préparation du suivant
De cette procédure on retiendra que l’on construit un pétale de moins que le nombre indiqué par le curseur. En effet - mais ce n’est qu’un choix - on a choisi de construire le dernier polygone dans une fonction particulière qui détermine le sommet de départ de la couronne suivante (le point NewS) qui est le retour d’une fonction PolyRetour.
La procédure Poly est triviale
Par contre la fonction PloyRetour est plus longue car, pour avoir le point suivant, on construit une liste en dessinant le dernier polygone, cette liste permettant alors de choisir le sommet de la couronne suivante, soit un sommet si le nombre de côtés est pair soit le milieu de deux sommets consécutifs sinon. D’où l’intérêt de cette liste des sommets pour avoir ce point sans calcul spécifique.
5. Passage à la couronne suivante
On met à jour les variables globales, par exemple le côté du polygone cpoly est l’image du précédent par une homothétie de rapport celui des cercles circonscrits de la nouvelle couronne et de l’ancienne. Puis on place la tortue en position pour continuer la figure.
(fin du bloc de présentation de la construction)
Extension de la temporalité « discrète » à deux états
On conserve le temps réel, puis on place deux temporalités discrètes, la plus fine, la plus naturelle, sur la construction discrète des pétales (des polygones), et une autre sur les couronnes.
Explorer la figure https://huit.re/S1031dalhia3tempo. Elle est centrée sur les pétales.
Par exemple on peut observer - et reproduire - cette situation, puis voir d’autres variantes, en particulier en ajoutant des couronnes.
Regardons maintenant l’option « couronne ». Comme on garde la même borne temporelle, l’affichage des couronnes est plus lent.
Une amélioration possible serait de paramétrer la borne en fonction du choix couronne ou polygone pour un meilleur confort d’utilisation en mode « couronne ».
Ajout de la 4° temporalité, la construction continue des polygones
Mais le plus intéressant est d’ajouter une temporalité supplémentaire, à savoir la construction « continue » des polygones. On a choisi de faire une nouvelle figure pour avoir par défaut une animation très lente pour voir les constructions.
La figure en ligne : https://huit.re/S1031dalhia4tempo est placée sur la continuité dans la configuration illustrée ci après :
En pratique, se limiter aux profondeurs 2 et 3 sinon l’affichage est trop rapide et ressemble en fait au polygones discrets.
On peut ralentir encore l’animation du curseur temporel. Il est réglé sur 2 on peut le mettre sur 1. Pour cela afficher l’inspecteur des objets (la roue du tableau de bord), sélectionner le curseurs du temps, puis dans Animation mettre le curseur à 1.
Le code de l’avance continue des pétales
Il est quasi identique au précédent du polygone. Les choix faits pour les comparaisons peuvent être modifiés (en particulier pour voir les dessins continus pour une profondeur plus grande).
Pour les personnes qui souhaitent aller plus loin, rappelons que tout le code est dans le centre du cercle comme la figure initiale.
Bilan
On aura compris que, dans cet article, nous interprétons le dynamisme de la tortue de DGPad comme répondant particulièrement bien à la définition d’un algorithme : la tortue rend l’algorithme, d’un seul bloc, elle ne le parcours pas, « cinématiquement », comme le font de manière standard Logo, Scratch, ou même Snap. L’intérêt est que la manipulation directe de l’algorithme est aussitôt répercutée sur la trace de la tortue, d’où cette idée d’une réflexion algorithmique au collège, non seulement en temps réel, mais même « en manipulation directe ».
Faire de l’algorithmique avec la tortue de DGPad, avec cette simultanéité entre le code et la production de la tortue est aussi une façon de faire entrer les élèves dans cette démarche que David Schön a appelé « le praticien réflexif » (voir ici ou encore là), cette démarche où chacun produit sa réflexion « sur l’action et en cours d’action ».
Nous avons vu qu’une démarche assez proche est possible aussi en Scratch, très simplement. On pourrait même ajouter une temporalité discrète en Scratch sur le polygone (sera fait dans une mise à jour de l’article d’ici sa publication « officielle »).
Le temps réel, de la tortue ou du lutin, ouvre, presque paradoxalement, vers des simulations temporelles plus riches qu’avec des programmes dont l’interface est déjà inscrite dans la temporalité, ce qui invite à une réflexion sur la façon dont le temps s’immisce dans les interfaces de logiciels de codage.
Téléchargements et autres informations
Les programmes Scratch proposés - même s’ils sont très courts
- Programmes Scrach de Sesam 1031
Les figures DGPad : il suffit (après avoir dézippé) de glisser les figures sur DGPad en ligne : www.dgpad.net/inex.php (fonctionnel dans tout environnement).
- Figures DGPad de Sesam 1031
DGPad existe aussi en application locale pour Linux (distribution Debian) et Mac OS.
Il existe aussi une application iOS et Android. Mais la partie Blockly n’est pas implémentée sous Android. Avis aux amateurs (Github) !
Un peu de militantisme pour DGPad ;-)
L’IRES de Toulouse (connu entre autre pour la démarche de Maths en Scène) a des pages de formation à DGPad pour une utilisation en collège, rédigées en Scénari.
Programmer en Blockly (APMEP - Lyon 2016)
Autre formation : Atelier Limoges 2017
Pour les collègues qui découvriraient DGPad par cet article et travailleraient sous Mac OS ou iOS, un iBook gratuit de présentation des possibilités didactiques de Blockly avec environ 80 figures sur 200 pages est disponible.
Lien iTunes : http://itunes.apple.com/fr/book/id1231386212
En particulier un chapitre est consacré aux conséquences subtiles (conservation des manipulations temporelles, mais aussi récursivité croisée entre les points par exemples) de la démarche utilisée pour construire le point M de la figure. Des applications plus simples, pour le collège, dans le chapitre de « la tortue algébrique » sont intéressantes aussi.
Plus généralement, hors utilisation des iBooks, on peut simplement consulter cet article de présentation (tout environnement) dont l’iBook n’est essentiellement qu’une synthèse et une mise à jour.
Pour d’autres figures DGPad, on peut consulter le compte twitter @Curvica974 (peu bavard ;-)