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.
