Saupin Guillaume

La France ne cesse de baisser dans les enquêtes PISA, qui évaluent le niveau en mathématiques des jeunes générations. Cédric Villani, médaillé Fields, a remis récemment un rapport pour rétablir la France dans ce classement. Pourtant, la France compte dans son histoire de nombreux mathématiciens d’importance. C’est le cas de Pierre de Fermat, fameux mathématicien, « prince des amateurs » qui avant ses 40 ans, en 1640, a démontré un théorème désormais éponyme : le petit théorème de Fermat. Ce théorème a à son tour été exploité par Ronald Rivest, Adi Shamir et Leonard Adelman, eux aussi de fringants trentenaires en 1977, année où ils mirent au point le fameux algorithme de chiffrement, lui aussi éponyme : RSA. Voyons ce qu’il y a de si remarquable dans ces maths qui n’impliquent que de simples opérations arithmétiques.

Face à la complexité d’un ensemble de données, le data scientist commence par les scruter sous tous les angles. Cette analyse graphique permet parfois de mettre en évidence des relations entre différentes dimensions. Dans ces cas-là, il est alors tentant de quantifier cette relation. Parmi les outils à la disposition du data scientist, la régression linéaire est l’un des plus simples, dont nous allons voir qu’il ne permet pas uniquement de lier des données selon une relation linéaire.

Il existe une terrible malédiction à laquelle se heurte le data scientist : la malédiction de la dimension. Ce terrible fléau frappe lorsque le nombre de variables d’un ensemble de données devient trop important. Dans ce cas, afin de permettre une analyse précise dans chacune des dimensions, il faut un ensemble de mesures tout à fait gigantesque. De plus, la multiplication des dimensions rend l’analyse très complexe. Difficile pour un humain d’appréhender les relations entre autant de variables.

Ce qui est formidable, avec l’informatique, c’est que c’est le jeu de construction ultime, un méta Lego, qui permet en assemblant de petites briques programmatiques, de créer de nouveaux univers imitant le nôtre. Et reconstruire notre univers, cela permet de se l’approprier, de s’en faire une représentation mentale, et finalement de mieux le comprendre. C’est l’intuition qu’a eue Seymour Papert, l’inventeur du langage Logo, l’inspirateur des Lego Mindstorms, le  père du constructionnisme. Quelques mois après sa mort, nous allons lui rendre hommage en construisant notre propre univers physique pour mieux nous approprier les lois de la physique. Ce moteur physique 2D, nous allons le développer à l’aide de Julia, un jeune langage de  programmation, inspiré du Lisp, et donc parfaitement dans l’esprit des travaux de Papert, dont on a surnommé Logo le « Lisp sans parenthèse ».

Température, pression, vitesse, puissance, sondage, euros, clics, position géographique… tout est mesuré, jaugé, quantifié, comparé, de nos jours ! Et avec pour conséquence un accroissement vertigineux de la quantité de données disponible sur un sujet donné. Cette masse de données fait le régal des « data scientists », et offre des perspectives dans de nombreux domaines, et pas uniquement pour offrir aux consommateurs toujours plus à consommer. Mais quel que soit l’usage que l’on fait de ces données, il faut de la puissance pour traiter très rapidement de grands ensembles, et de la souplesse pour pouvoir explorer sans contrainte. Bref, il nous faut un Lisp la souplesse du Python et les performances du C.

Développer l'interface web d'une application en ligne est un exercice bien différent conceptuellement du développement de la partie backend. Les interfaces graphiques, fonctionnant par essence en réaction aux évènements utilisateurs ou applicatifs, appellent un mode de conception du code bien particulier. Si l'on part avec le mauvais paradigme, la rapidité de développement et la qualité du code s'en ressentiront rapidement. Elm offre, en s'appuyant sur la programmation fonctionnelle réactive, et en lui adossant un système de typage fort avec inférence à la ML, une solution robuste, performante et élégante au problème du développement d'interface graphique web.

Les deux précédents articles de cette série nous ont permis de mettre au point les fonctionnalités de base de notre langage de programmation. Nous sommes maintenant outillés pour pouvoir parser et évaluer des expressions d'un langage de type Lisp. De plus, nous disposons d'un mécanisme de plugins permettant d'étendre facilement notre langage. Nous allons maintenant passer aux choses sérieuses et permettre à notre langage de s'étendre en déclarant des fonctions, et surtout en supportant les macros.

Dans le précédent article, notre héros, le Lisp, a fait l’objet d’un rappel de ses innombrables qualités. Inspirés par ce modèle,  nous avons présenté rapidement le caractère modulaire que nous souhaitions donner à notre langage, puis décrit la structure de données contenant le code parsé, et enfin écrit un parseur récursif descendant. Tout ça n’est pas très utile. Nous allons remédier à ça en ajoutant un interpréteur à notre langage.

Il est des quêtes dont on revient forcément changé. Celle que je vous propose est la quête ultime, celle que doit mener tout programmeur pour pouvoir un jour asséner avec force et sérénité cette affirmation : j'ai créé mon propre langage de programmation !