code = data

Quand on découvre l’informatique, une des premières choses que l’on apprend, c’est qu’il y a, d’un côté les données et, de l’autre, le code : le code agit sur les données. Très vite, on met les données de côté (vu qu’elles changent tout le temps) et on se concentre sur le code. C’est d’autant plus vrai que l’approche dominante aujourd’hui, est la programmation orientée objet qui favorise la création de « boîtes noires » abstraites qui encapsulent si bien les données qu’on ne les voit plus.

Mais quand on utilise un tableur, le raisonnement est complètement inversé. On a un grand tableau avec un très grand nombre de cases, et chaque case peut contenir une valeur. Ici on mettra des titres, là des chiffres : on le remplit de données. Et puis, il y a cette donnée un peu particulière et qui change tout : une formule qui produira la valeur par calcul. En pratique, c’est du code mais on le perçoit comme une donnée.

Ce qui apparaît sur une feuille de calcul, c’est uniquement les valeurs, on ne voit que les données (si on veut voir une formule, il faut cliquer) : c’est tout l’inverse du code où on ne voit que les expressions (pour voir les résultats, il faut lancer l’exécution). Je crois que c’est ce qui différencie les programmeurs des autres utilisateurs : le programmeur parvient à exécuter le code « dans sa tête » et peut se passer de voir les valeurs pour comprendre ce qui se produit, un peu de la même façon que le mathématicien manipule des formules sans toujours avoir besoin de représentation plus concrète (et je pense que c’est la raison principale pour laquelle on prétend qu’il faut être bon en math pour programmer).

Dans son expression la plus simple, un programme c’est une liste d’instructions, une séquence d’actions à effectuer. On peut la représenter à l’écran comme une liste de blocs, chacun calculant un résultat intermédiaire et référençant les précédents. Chaque bloc contenant un nom, une valeur et une expression.

Pour simplifier, ce dont il s’agit c’est de programmer directement dans un debugger. Une autre manière de voir les choses est de considérer que la séparation entre éditer et voir le résultat n’est peut-être pas nécessaire, comme pour les traitements de texte. Et, toujours comme pour les traitements de texte, je crois qu’il est plus que temps de présenter les expressions clairement, comme on le ferait en mathématiques.

Une propriété remarquable de cette façon de présenter un programme est que chaque bloc représente une variable et que cette variable, du fait de sa représentation en tant que « case » ne pouvant faire référence qu’aux cases précédentes, satisfait naturellement les conditions du Static Single Assignment (SSA). Autant que faire se peut, l’idée est de converger vers une représentation qui puisse être convertie directement en IR LLVM, et pouvoir produire aussi simplement que possible du code compilé.

A ce stade, on voit assez bien comment représenter une séquence d’instructions (un basic block) mais c’est bien insuffisant pour écrire un véritable programme. La prochaine fois, nous examinerons la question des tests, des boucles, des sous-programmes et toutes ces structures de base nécessaires à toute construction logicielle.

Programmer, sans coder

Les languages de programmation évoluent, mais une chose reste constante : ils se présentent principalement sous la forme de fichiers texte à la syntaxe extrêmement rigoureuse. Programmer, c’est avant de faire quoi que ce soit, s’assurer que chaque parenthèse, chaque accolade ouverte est bien fermée, coder c’est vérifier d’abord que tous les point-virgules nécessaires sont bien là… Je ne m’en rend plus compte, je fais ça mécaniquement, mes doigts se sont comme programmés à cet exercice. Il y a cependant quelque chose d’archaïque à continuer à saisir du code, au 21e siècle, quand l’informatique a révolutionné tous les autres métiers.

Il y a eu de nombreuses tentatives pour remplacer cette représentation textuelle par des diagrammes ou autres représentations graphiques. Il y a longtemps, il m’est arrivé d’utiliser un normographe pour tracer des organigrammes. Plus tard, des interfaces graphiques ont été créées pour coder sous forme de diagrammes, comme dans Houdini, Maya ou Substance Designer. Des représentations graphiques sont courantes pour représenter des schémas de bases de données, l’architecture d’un système (UML notamment) ou, plus récemment, le dataflow d’un réseau de deep-learning. Dans l’ensemble de ces cas, on a l’impression de regarder un schéma électronique, une usine à gaz et aucune vision synthétique ne semble véritablement émerger qui soit supérieure à la représentation textuelle : la programmation paraît condamnée à un certain niveau de complexité.

The Houdini Node System – by SideFx

Pourtant, une des promesses du micro-ordinateur, c’était la possibilité pour tout un chacun de coder. Le language BASIC n’avait pas d’autre objectif : être un langage à tout faire, pour débutant. Aujourd’hui, pour s’initier à la programmation, on commencera par bidouiller du HTML, on tentera d’apprendre un peu de JavaScript et, inévitablement, l’expérience se révèlera simplement frustrante.

Il y a cependant un outil qui permet aux utilisateurs de parvenir à un résultat satisfaisant sans tous ces efforts : le tableur. Visicalc est la killer-app qui a propulsé l’Apple][ dans le monde de l’entreprise au début des années 80. Avec cet outil, on peut modéliser et analyser des problèmes très complexes, étudier des alternatives sans recommencer tous les calculs, on prend une longueur d’avance. Sans savoir programmer. Pourtant, il s’agit de la même chose : des données en entrée, des données en sortie et des opérations au milieu. On ne le voit pas parce que, pendant tout ce temps, les outils de programmation se sont focalisés sur le code et ont établi une ségrégation d’avec les données (au prétexte du principe de « separation of concerns »). Les tableurs, eux se sont focalisés sur les données et n’ont pas su proposer de structures permettant de modéliser tests, boucles, fonctions ou sous-programmes.

C’est cette idée qui me trotte dans la tête depuis quelques années : développer un outil qui ressemble à un tableur, un « visual calculator » qui présente des résultats plutôt que des symboles et des formules, qui permette à tout un chacun de créer des programmes, sans coder.

La prochaine fois, je vous parlerai des autres raisons qui me font penser que, même si l’on n’est plus débutant, il est temps de passer à ce niveau d’abstraction supplémentaire. Et, si le vent le veux, j’espère bien faire quelques expériences pratiques, voir à quoi ça pourrait ressembler…

« Ce qui ne s’exprime pas s’imprime »

J’entendais une femme quasiment chanter cette maxime à une autre sur le quai de la gare… Elles revenaient sur une discussion où quelque chose d’important avait été dit, ce qu’on aurait appelé autrefois « vider son sac », une « discussion franche et honnête » ou « je lui ai dis ses quatre vérités ». Mais elles n’en parlaient pas comme cela et cette forme de maxime est sortie, dite sur le ton d’une comptine enfantine. Ça a conclu leur discussion.

Pourtant, pour ma part, c’est tout un train de pensées qui est entré en gare !

Qu’est-ce qui fait qu’on accorde tant de crédit à une petite phrase comme celle-ci ? Il y a indéniablement un facteur esthétique, ce fait que ça puisse se chanter, une bonne maxime a un rythme, une sonorité, elle invite à une théâtralité. Il y a une structure aussi qui fait que c’est à la fois simple et complet, à une bonne maxime il n’y a rien à ajouter. C’est un petit objet bien rond, parfait sous tous les angles, péremptoire mais charmant. En un sens, ça a les mêmes propriétés qu’un trait d’humour, l’esprit se régale de la quantité de sens dans une si courte formule.

Et, ainsi, la maxime accède au rang de vérité. L’habileté apparaît comme de la sagesse, cette petite merveille de symétrie se doit, en plus, de renfermer un secret. Séduit par cette beauté, on accepte le message.

Pourtant.

Mon expérience personnelle, c’est qu’une fois qu’une chose est dite, elle prend corps. Une fois qu’une chose est dite, on a du mal à revenir dessus : c’est dit ! Mon expérience c’est qu’un projet n’a pas véritablement commencé tant qu’on ne l’a pas baptisé, qu’il devient réel dès lors qu’on lui donne un nom et, à ce moment là, il prend une vie propre : les dés en sont jetés. Avant cela, il flottait dans le royaume nébuleux des idées, ça trottait dans la tête, bribes incomplètes, malléables et changeantes. Et puis, un jour on sait lui donner un nom, et « ça prend forme ». Et tout cela peut se généraliser à la pensée quand elle s’applique à d’autres enjeux que les projets.

Alors, si « ce qui ne s’exprime pas s’imprime », il se trouve aussi que « ce qui s’exprime s’incarne… ». En fin de compte, je n’aime pas tellement les maximes ou les citations : ce sont des raccourcis de l’esprit, elles masquent autant qu’elles révèlent.