Programmer comme ça, ça s’appelle de la programmation événementielle, ou programmation par évènements, et ça consiste en gros à remplacer un gros programme par des petits programmes, réactifs (ils réagissent à des évènements) et qui communiquent entre eux (l’envoi de message est un évènement).

L’idée remonte au moins à 1943 avec Warren McCulloch et Walter Pitts qui, conscients du fait que le cerveau humain ne fonctionne pas du tout séquentiellement comme une machine de Turing, ont réussi à simuler des calculs classiques avec des assemblages dont l’élément de base est un neurone formel. En effet un neurone est la plupart du temps inactif, et n’envoie un influx nerveux sur son axone que lorsqu’un nombre suffisamment élevé de ses synapses est excité. C’est comme ça que nous effectuons par exemple des calculs mentalement, par des neurones nombreux et interconnectés. La programmation événementielle fonctionne aussi comme ça : Les scripts sont souvent en hibernation mais chatouilleux, et lorsqu’une action les réveille, ils s’exécutent, avec pour résultat qu’il est souvent difficile de prédire le comportement d’une société de tels scripts-agents.

Comme McCulloch a longtemps travaillé au MIT, son empreinte s’est gravée chez les chercheurs en intelligence artificielle comme Seymour Papert et, au-delà de ce dernier, Alan Kay. Ainsi, parce que ses objets s’envoient des messages et qu’il est basé sur un environnement à base de souris et de fenêtres, le langage Smalltalk est l’un des premiers qui permettent la programmation par événements. Et donc, par héritage, les langages Java, Python et Ruby. Mais aussi, Lua très utilisé dans les jeux vidéo (où le joystick fournit des évènements à gérer) et le très microsoftien Visual Basic...

Mais les langages créés ad hoc pour faire de la programmation événementielle sont ceux basés sur la norme ECMA, le célèbre JavaScript et le bien nommé ActionScript, langage dans lequel a été créé TracenPoche. Le cas JavaScript montre que la programmation par événements est prépondérante sur le Net, mais aussi chaque fois qu’on utilise la souris. Un clic de souris, un mouvement de celle-ci, sont des évènements propres à réveiller des scripts d’action endormis. Un autre exemple très connu est le message auquel on finit par ne plus faire attention, affiché par le logiciel de messagerie, et disant « vous avez reçu un mail ». On peut penser à certains virus comme Tchernobyl (virus) qui se déclenchent à une date fixe...

Le domaine où la programmation par événements est le plus pratiquée est l’audio-vidéo, avec par exemple le langage MIDI, où rien ne se passe tant qu’un événement de type « appui d’une touche du clavier » n’est pas survenu. Mais dans un tableur aussi, il y a de la programmation événementielle, comme on peut le voir en entrant une formule dans une cellule, ce qui en général a sur les autres cellules le même effet que l’appui sur la touche F9 : Le recalcul de toute la feuille. Les objets qui s’envoient des messages sont ici les cellules du tableur, et l’événement qui déclenche leur réaction est la modification de leur contenu. Les logiciels de calcul formel aussi fonctionnent par événements, l’événement de base étant ici la modification d’un curseur ou l’entrée d’une requête par l’utilisateur.

Puisque plus haut on parlait de Smalltalk, voici quelques évènements de Scratch (langage) :

Ce langage de programmation est en effet basé sur les événements... Le drapeau vert est l’événement destiné à lancer le programme, mais en fait celui-ci est un système multi-agents, les agents (ce qui fait agir un script) étant appelés « lutins » dans le vocabulaire particulier de Scratch. Toutefois les événements importants en géométrie dynamique comme la mouvement des points ne sont pas reconnus par Scratch (« est pressé » ici veut dire « cliqué »).

En tête de cet article, est annoncée une série d’événements sur les événements dans le domaine de la géométrie dynamique, qui ont eu le don de me faire sortir d’une relative léthargie, et de me mettre en action en écrivant ledit article. Ces trois événements, presque simultanés, sont décrits dans les onglets suivants.

En février 2011, Hilaire Fernandes a introduit dans DrGeoII un nouvel objet qu’il appelle point par bloc (en tout cas en anglais, « point defined by block closure »). Pour comprendre en quoi ce point est différent des autres points (point par coordonnées et point sur courbe), il faut commencer par se poser la question « mais au fait, un bloc d’instructions Smalltalk, c’est quoi ? ». Dans ce cours de Smalltalk, on nous dit que

Smalltalk introduit la notion de blocs (ou fermetures lexicales). Il s’agit d’objets qui contiennent du code qui peut être évalué ultérieurement et ainsi transmis comme n’importe quel autre objet.

Soit mais encore ? L’idée de mettre les coordonnées d’un point entre crochets pour qu’elles ne soient calculées qu’au moment de la création du point est intéressante, mais heureusement, on peut faire beaucoup plus de choses avec un bloc. Par exemple, les fonctions sont elles aussi définies par des blocs. Un point par bloc peut donc déjà servir à représenter grahiquement des fonctions, il suffit pour cela de lui donner comme « parent » un point sur l’axe des abscisses, et de choisir comme variable du bloc l’abscisse de ce point :

Il suffit après ça de rajouter un « figure locusOf : stylo when : mobile. » pour avoir la représentation graphique de la fonction sur [-5 ;5] :

Mais ce n’est pas tout ! On peut définir des fonctions plus compliquées comme par exemple définies par des boucles. Ainsi la fonction proposée par Riemann à la recherche d’une fonction continue nulle part dérivable et definie par $R(x)=\sum_{k=1}^{\infty}\frac{sin(k^2x)}{k^2}$ peut se représenter graphiquement par ce script :

L’exécution du script produit la figure suivante :

Les courbes paramétrées sont maintenant à la portée de DrGeoII, par exemple le folium de Descartes :

En prime, on a gagné l’asymptote, c’est bien sûr une erreur d’approximation (de l’infini) :

Ces nouveaux objets (il y a aussi une variante où le mot « parents » est au pluriel) rendent maintenant accessibles à DrGeoII la géométrie complexe (l’image de cercles et droites par des polynômes complexes par exemple), les champs de vecteurs (avec résolution approchée des équations différentielles par des méthodes style Euler ou Runge-Kutta), l’étude dynamique de suites (avec deux parents, l’indice de la suite et un curseur, on peut représenter graphiquement la suite, et la représentation graphique évolue quand on manipule le curseur). Bref, le « point par bloc » propulse DrGeoII dans la « cour des grands ».

Mais le point par bloc permet quelque chose de bien plus impressionnant : En assimilant le bloc à un script (ce qu’il est d’ailleurs, le langage de script étant Smalltalk), la définition même du bloc permet de considérer le (ou les) parent(s) comme les points dont le mouvement chatouille et réveille le script. Une application en classe est la possibilité d’évaluer un algorithme sur un grand nombre de jeux de données différents, par simple mouvement d’un point à la souris : Double gain de temps, d’une part pour l’enseignant qui évalue à la fois rapidement et exhaustivement, et pour l’élève qui peut évaluer lui-même, épargnant ainsi à l’enseignant ces instants devenus brefs. Par exemple, le calcul de $\sqrt{2}$ par la méthode de Héron est facile à vérifier, il suffit d’attendre que l’algorithme ait suffisamment convergé, et de comparer le résultat avec une valeur approchée connue de $\sqrt{2}$. Mais pour vérifier la variante donnant $\sqrt{5}$, on doit tout recommencer ! Pour vérifier l’algorithme de calcul de plusieurs racines, on le met en script d’action (le bloc ci-dessus) mis en route par le mouvement d’un point m (le parent ci-dessus) et admettant en valeur d’entrée l’abscisse actuelle du point mobile (m ci-dessous). L’algorithme en Smalltalk donne ceci :

On voit que plus de la moitié du code est l’algorithme de Heron lui-même. Le point mobile est le point m attaché au segment ab (si il pouvait aller à gauche de l’origine DrGeoII planterait car l’algorithme ne convergerait pas). En déplaçant le point m à la souris, on voit n parcourir une courbe dont la nature peut être conjecturée. Et avec les deux dernières lignes, on trace cette courbe :

Toujours en février 2011, Éric Hakenholz a introduit dans CaRMetal ce qu’il a appelé des scripts d’action, ou action scripts. Le terme est malheureux puisque ActionScript est déjà le nom d’un langage de programmation. Aussi dans cet onglet lui préférera-t-on l’abréviation CaRAScript proposé par Stéphane Reyrolle, en insérant la première lettre du mot action (ou agent) dans le néologisme CaRScript. Alors, qu’est-ce qu’un CaRAScript ? Et bien, c’est juste un CaRScript normal, sauf qu’on lui attache un ou plusieurs points (équivalent aux parents de DrGeoII). Et il s’exécute chaque fois qu’on bouge l’un de ces points. Il n’y a pas de limite théorique au nombre de scripts qui peuvent être attachés à un point !

Un exemple d’utilisation : La figure ci-dessous est classique, le point M (en rouge) est le milieu de [AB] ce qui empêche de le manipuler :

milieu à l’ancienne

Le milieu M est construit donc pas manipulable, seuls A et B peuvent bouger.

Mais il est très raisonnable d’attendre que la manipulation soit inversable, et que le mouvement de M à la souris déclenche le mouvement de A et B de telle manière que M reste le milieu (par exemple, avec le logiciel GeoLicia, B devient le symétrique de A par rapport à M), avec un comportement de ce genre (obtenu avec la définition circulaire des coordonnées de deux des trois points) :

milieu mobile

Comme dans GeoLicia, on peut bouger le milieu alors qu’il dépend des deux autres points

Avec les CaRAScripts on peut très facilement simuler ce comportement, sans récursivité apparente (la récursivité est cachée dans l’ubiquité des agents doubles A, B et M). On crée pour chacun des points B et M un script de mise à jour de ses coordonnées. Pour le point B, redéfini comme le symétrique de A par rapport à M :

Pour le point M, redéfini comme le milieu de [AB] :

La suite c’est de définir pour chacun de ces scripts la liste de ses agents (les points dont le mouvement déclenche le réveil du script). Cela se fait dans le gestionnaire de scripts, un outil créé par Pierre-Marc Mazat (c’est d’ailleurs la vue de ce gestionnaire de script qui a déclenché chez Éric Hakenholz l’idée de réaliser des scripts d’action : Une fois de plus, le développement logiciel fonctionne comme les scripts d’action, avec des agents qui se stimulent mutuellement par déclenchement d’événements...). Pour le script du point M, on sélectionne les deux autres points :

et pour celui du point B, on sélectionne le point M, et c’est tout ! Le résultat est téléchargeable en bas de l’article, et à ouvrir avec une version supérieure ou égale à 3.6 de CaRMetal.

Le classeur est téléchargeable ci-dessous, avec un Easter egg de saison (dernière figure)...

Algorithme de Heron en manipulation directe

Pour tester l’algorithme de Heron avec beaucoup de données initiales mais rapidement tout de même, rien ne vaut l’engagement direct du prof-évaluateur offert à celui-ci par l’élève-programmeur. Donc pour entrer
la donnée x, on crée un point M attaché à l’axe des abscisses, et on lit son abscisse :

Pour peu que le point N (qui sert de sortie de données à l’algorithme) ait la « trace activée », le mouvement de M fait apparaître une courbe qui permet très vite de vérifier que l’algorithme est correct, et d’émettre des conjectures. CaRMetal est remarquablement résistant au plantage, en effet si l’abscisse de M devient négative, on ne voit rien se passer et c’est tout !

Épistémologiquement parlant, on peut dire sans trop exagérer qu’après avoir donné vie aux points de CaRMetal avec le Monkey, Éric Hakenholz leur a donné une forme d’intelligence avec les CaRAScripts ! Voilà une nouveauté à la fois intelligente et excitante (au sens où elle incite à se mettre en action).

Au début de 2011 (en février aussi ?), l’un des développeurs de GeoGebra a eu l’excellente idée de mettre du JavaScript dans GeoGebra. Et comme l’idée avait déjà été réalisée avec les CaRScripts, les développeurs de GeoGebra ont décidé d’aller un cran plus loin, on devinera comment ... en mettant ces scripts à l’intérieur des objets de GeoGebra, au même titre que leurs coordonnées, leur couleur etc. Bref, en en faisant des scripts d’action !

Trois sortes d’évènements peuvent activer un script d’un objet GeoGebra : Le clic sur cet objet (onClick comme dans Scratch et les boutons de CaRMetal), le déplacement de l’objet (onUpdate comme dans DrGeoII et les points de CaRMetal) et l’ouverture du fichier (comme dans CaRMetal). Et pour chacun de ces événements (bouger un point ce n’est pas cliquer dessus) on a le choix entre un langage de script appelé GGBScript (formé d’instructions GeoGebra sans boucle) et le JavaScript de rhino, le même que dans CaRMetal. Sauf pour l’onglet global JavaScript qui se lance à l’ouverture du fichier et qui, comme son nom l’indique, n’est pas propre à l’objet, et ne peut s’écrire qu’en JavaScript.

GeoGebra possède aussi un nouvel objet, la case de texte, qui se comporte de façon analogue aux cellules du tableur, et peut aussi réveiller un script lorsqu’on modifie son contenu (typiquement plutôt numérique).

Milieu dynamique

Pour recréer le milieu à la GeoLicia qu’on peut manipuler à la souris, on peut créer 3 points A, B et M et affecter à chacun d’entre eux un script qui se réveille lorsqu’on le chatouille (c’est-à-dire lorsqu’on le bouge : on ne peut bouger qu’un point à la fois !). Pour les points A et B le script sera

et pour le point M, on redéfinit B comme symétrique de A par rapport à M :

Avec ça le fichier se comporte exactement comme la version GeoLicia : Si on bouge A ou B, M suit le mouvement, et si on bouge M, B seul suit le mouvement. Pour un exemple aussi simple, il n’était pas nécessaire d’activer l’entrée « JavaScript » du menu comme on le voit sur les figures ci-dessus, mais on peut choisir « GeoGebra script » et entrer pour A et B

et pour M :

Pour l’algorithme de Heron en manipulation directe, on a vraiment besoin de JavaScript :

Algorithme de Heron

Comme dans les onglets précédents, on peut attacher un point M à l’axe des abscisses, et créer un point N dont la trace est active ; puis on donne à M le script suivant :

En bougeant ce dernier, on voit apparaître l’arc de parabole attendu, sauf que comme pour DrGeoII, on fait planter GeoGebra si l’abscisse de M devient négative.

• Scratch ne réagit pas au mouvement des objets, ce qui le place un peu hors concours (ce logiciel n’a pas la prétention de faire de la géométrie).

• GeoGebra peut réagir à des événements concernant des droites, des polygones, des cercles etc. et pas seulement à des points. Mais il faudra attendre des exemples d’utilisateurs pour voir si cette puissance est vraiment utile à quelque chose, en effet normalement ce sont les points qu’on bouge dans un logiciel de géométrie dynamique. DrGeoII réagit à tous les objets qui peuvent être parents (points, droites, cercles, expressions numériques) et permet donc le même genre de folie.

• Chaque CaRAScript de CaRMetal réagit non pas à un point mais à une liste de points, dont certains peuvent être communs à plusieurs scripts, ce qui émule le calcul parallèle. Un peu comme un neurone qui a plusieurs synapses en entrée. Avec ses parents multiples, le point par bloc de DrGeoII permet un comportement analogue.