Paradigmes de programmation

Une cellule et une variable

Le service de paiement du chapitre précédent reçoit $\lambda = 8$ demandes par seconde et en traite au plus $\mu = 10$. Son temps de réponse moyen vaut $W = 1/(\mu - \lambda)$, soit une demi-seconde. Le même calcul, écrit deux fois.

Le même calcul en Python demande de savoir ce que fait exactement une ligne comme w = 1 / (service - arrivees).

Les deux lignes affichent 0,5 seconde. Ni le tableur ni Python ne se trompent : ils ne disent pas la même chose. La formule du tableur déclare une relation, et le tableur décide quand la recalculer ; le script ordonne une suite d'étapes, faites chacune une fois et dans l'ordre. Pour que w suive, il faudrait réécrire la ligne qui le calcule après chaque changement, c'est-à-dire ajouter une étape. C'est la première grande ligne de partage entre façons de programmer : décrire ce qu'on veut obtenir, ou décrire comment l'obtenir.

Un paradigme n'est pas un langage

Trois confusions à écarter d'emblée.

Un paradigme n'est pas un langage. Python permet d'écrire des étapes, des objets et des fonctions dans le même fichier, et le tableur, qui n'est pas un langage au sens courant, est l'exemple le plus répandu du style déclaratif. Java, pensé autour des classes, a ajouté des fonctions de première classe : des fonctions que le langage traite comme n'importe quelle autre valeur, qu'on peut ranger dans une variable, passer en argument ou rendre comme résultat. L'usage le plus courant en Python est sorted(arrets, key=lambda a: a["duree"]), qui range des arrêts de machine par durée : sorted reçoit une autre fonction, écrite sur place et sans nom, qui dit selon quoi trier. Le chapitre Bien écrire une fonction l'enseigne. La plupart des langages sont multi-paradigmes, et le choix revient à qui écrit.

Un paradigme n'est pas un niveau de compétence. Écrire en objet n'est pas « plus avancé » qu'écrire une suite d'étapes. Un script de 40 lignes enveloppé dans trois classes est plus difficile à lire, pas plus professionnel.

Ce n'est pas non plus une religion. Un vrai logiciel mélange les familles : une application de suivi de production range ses données dans une base interrogée en SQL, calcule ses indicateurs avec des fonctions, et représente chaque machine par un objet.

La carte : où vit l'état

Quatre familles se partagent la façon de programmer. Les deux premières sont deux manières d'organiser des étapes, donc deux formes de l'impératif ; les deux dernières décrivent un résultat plutôt qu'un chemin, la fonctionnelle en partie, la déclarative entièrement. Ce qui les sépare le mieux est la colonne du milieu.

Une famille par problème

Chaque famille a ses problèmes de prédilection. Les quatre qui suivent viennent du même atelier de production, mais ce sont quatre problèmes différents, choisis parce que la famille y est chez elle.

Procédural : un compteur que tout le programme modifie

En fin de poste, l'atelier veut savoir combien de pièces chaque machine a produites. Les lots arrivent un par un, et chacun s'ajoute au compteur de sa machine : une suite d'étapes qui modifient un total. C'est le terrain du procédural, qui décrit les étapes dans l'ordre où on les ferait à la main, comme les algorithmes du parcours d'algorithmique. Les données vivent dans une variable que tout le programme voit, et des fonctions la modifient.

Direct, lisible, minimal. La première ligne affichée mérite qu'on s'y arrête, parce que tout le chapitre tourne autour : l'appel enregistrer("presse", 15) renvoie None, c'est-à-dire rien, et pourtant la ligne suivante montre une presse à 180 pièces. Ce que la fonction rend et ce qu'elle fait sont deux choses distinctes, et c'est la seconde qui compte ici : on l'appelle un effet de bord, toute modification qu'une fonction laisse derrière elle en dehors de ce qu'elle renvoie. Une fonction à effet de bord ne se lit pas dans son appel, seulement dans son corps.

Et une faiblesse structurelle : production est accessible et modifiable de partout. Rien n'empêche un autre bout de programme d'écrire production["presse"] = -5.

Objet : une cuve qui garde sa règle

Un centre d'usinage est alimenté en huile de coupe par une cuve de 1 000 litres. Le programme de supervision la remplit, et une règle ne doit jamais casser : la cuve ne déborde pas. Un état qui dure, et une règle qui doit tenir à chaque changement : c'est le terrain de l'objet, qui range dans un même objet les données et les opérations qui les concernent.

La même scène que tout à l'heure, avec une barrière en plus.

Le gain est concret : la règle « pas de débordement » est écrite à un seul endroit, dans remplir, et tout remplissage passe par là. Le second remplissage est refusé avant que rien ne soit versé, et la cuve reste à 600 litres. La capacité appartient à la cuve, là où on la cherchera.

La garantie a une limite, qu'il faut connaître : cuve._niveau = 5000 s'exécute sans erreur, et la cuve affiche alors 5 000 litres pour une capacité de 1 000. Le souligné dit « ne pas toucher », il n'empêche pas de toucher. L'encapsulation protège ce qui passe par les méthodes ; pour fermer aussi cette porte, il faudrait des valeurs qu'on ne peut plus modifier, ce qui est précisément l'idée de la famille suivante.

Pour aller plus loin (facultatif) : le diagramme de classes. La même structure se dessine en notation UML, celle des patrons de conception. Le signe qui précède chaque ligne dit ce qui est interne (-) et ce qui est offert à l'extérieur (+) ; une parenthèse signale une méthode.

Fonctionnel : un journal dont chaque version reste

Au contrôle qualité, chaque pièce usinée est mesurée, et sa cote s'ajoute au journal du lot. Un client qui conteste une livraison demandera ce que contenait le journal au moment où le lot est parti : il faut donc que chaque version du journal reste consultable. C'est le terrain du fonctionnel : on ne modifie rien, chaque opération rend une valeur neuve, et les anciennes restent.

Le résultat remarquable est la ligne j1 est intact : True. Trois cotes ont été ajoutées, et pourtant j1 contient encore la seule première, tandis que j3 en affiche trois. Chaque version du journal existe toujours. Retrouver l'état d'un lot à un instant donné ne demande aucun code : il suffit d'avoir gardé le nom de la version. Comparer deux états, rejouer un historique, annuler un ajout deviennent immédiats, et c'est exactement ce que demande le client qui conteste une livraison.

C'est aussi la version où le mot pure devient vérifiable. Contrairement à enregistrer dans la version procédurale, ajouter et moyenne renvoient tout ce qu'elles produisent. moyenne(j3) rend 25,01 mm, et l'appeler dix fois d'affilée rend dix fois la même valeur sans rien laisser derrière. Le résultat de la fonction est son seul effet.

Les mêmes gestes servent partout où l'on transforme des données sans rien garder : sorted(cotes) rend une liste triée neuve et laisse cotes telle quelle, quand cotes.sort() trie la liste elle-même ; une compréhension, [c for c in cotes if c > 25], fabrique elle aussi une liste neuve.

Pourquoi le fonctionnel convient au travail en parallèle. Un programme peut mener plusieurs traitements à la fois, les fils d'exécution, qui partagent les mêmes données. Une valeur qui ne change jamais peut être lue par mille fils en même temps sans le moindre verrou, ce mécanisme qui réserve une donnée à un seul fil à la fois. L'essentiel de la difficulté du parallélisme vient de l'état modifiable partagé : deux fils lisent la même valeur, la réécrivent chacun de leur côté, et l'une des deux écritures se perd. C'est la condition de course, dont la fin du chapitre montre un cas sur le compteur de production. Supprimer l'état modifiable partagé supprime cette classe de problèmes entière, et c'est la raison pour laquelle les langages fonctionnels ont regagné du terrain avec les processeurs multicœurs.

Déclaratif : décrire le résultat, laisser le chemin au moteur

Le service maintenance consigne chaque arrêt de machine dans une base de données : la machine, la durée en minutes, la cause. Sa question du lundi : quels arrêts ont duré plus d'une demi-heure, du plus long au plus court, et combien de minutes au total ? C'est le terrain du déclaratif. On décrit le résultat voulu, comme dans la formule du tableur, et un moteur choisit comment l'obtenir. C'est exactement ce que fait SQL, et le bloc ci-dessous s'exécute vraiment.

Nulle part il n'est écrit comment trouver les arrêts de plus de 30 minutes, ni comment les trier : pas de boucle, pas de comparaison écrite à la main. La contrainte duree_min >= 0 est déclarée une fois, et la base la fait respecter à chaque insertion, d'où qu'elle vienne. C'est le pendant de la règle écrite dans la méthode remplir de la cuve, à une différence près : ici, aucune ligne de code applicatif ne la vérifie, et le programme qui insère ne peut pas l'oublier.

Ce que change l'état modifiable

Les quatre familles ne se séparent pas d'abord par leur syntaxe, mais par ce qu'elles font de l'état, et le clivage se voit mieux sur un défaut que sur un discours. Avant de modifier les réglages d'une presse, le programme de supervision en garde une sauvegarde, pour pouvoir revenir en arrière si le nouveau réglage se passe mal.

Le programme ci-dessous joue la première scène, puis la même modification sur une structure immuable.

Les deux moitiés du programme se lisent dans ce qu'il affiche. En haut, une seule ligne a été modifiée, reglages[0]["pression"] = 140, et pourtant sauvegarde affiche 140 elle aussi : la sauvegarde, faite justement pour réparer un mauvais réglage, a reçu l'erreur. En bas, la même modification sur le tuple ne s'exécute pas : Python répond 'tuple' object does not support item assignment. Ce n'est pas une convention à respecter, c'est un refus. Pour changer le réglage, il faudrait fabriquer un tuple neuf, et la sauvegarde garderait l'ancien.

La cause tient dans une image mentale fausse. On se représente une variable comme une boîte qui contient une valeur, alors qu'elle est une étiquette collée sur un objet. L'affectation ne déplace pas de contenu : elle colle une seconde étiquette. Sur les figures qui suivent, les noms sont à gauche et les objets à droite. Un cadre en trait plein est un objet modifiable, un cadre en pointillé un objet immuable ; un cadre rouge signale un objet à la fois modifiable et désigné par plusieurs noms, le cas où modifier par un nom modifie pour tous.

Sur cette figure, compter les cadres : il n'y en a qu'un, pour deux noms. C'est là tout le problème, et les figures suivantes se lisent en comptant de la même façon.

Deux façons de s'en sortir, et elles ne se valent pas. La première consiste à copier vraiment : sauvegarde = copy.deepcopy(reglages), après un import copy. Elle donne deux objets distincts, mais demande de penser à le faire à chaque fois.

Deux cadres cette fois, et deux pressions différentes : 140 d'un côté, 14 de l'autre. C'est bien ce qu'on voulait, puisque la sauvegarde permet de réparer la faute de frappe, au prix d'une ligne que rien n'oblige à écrire.

La copie la plus évidente, reglages.copy(), ne suffit pas ici : c'est une copie superficielle, une nouvelle liste qui contient le même dictionnaire. La figure suivante dessine la case 0 de chaque liste comme un nom de plus.

Trois cadres, dont un rouge. Les deux listes sont distinctes, et ajouter un réglage à l'une ne toucherait pas l'autre ; mais leur contenu est commun. C'est ce qui rend la copie superficielle si traîtresse : elle protège la structure de la liste, pas ce qu'elle contient.

La seconde façon consiste à rendre l'objet immuable. Le partage subsiste, et il devient inoffensif : on ne peut modifier ce qui ne se modifie pas, donc la question ne se pose plus.

Ce que ces figures disent ensemble. Le défaut ne vient pas du partage, et il ne vient pas de la mutabilité : il vient de leur rencontre. Supprimer l'un des deux suffit, et l'immuabilité est celui qu'un langage peut garantir à la place du programmeur. C'est tout l'argument du style fonctionnel, et c'est aussi la raison pour laquelle ses structures se partagent entre fils d'exécution sans verrou : ce qui ne change pas ne peut pas être vu à moitié changé.

Deux écritures en même temps

Le partage a une forme que la copie ne règle pas : deux utilisateurs qui modifient la même donnée au même moment. Le compteur de la presse, celui de la version procédurale, est maintenant tenu par une base que deux terminaux d'atelier mettent à jour. Il vaut 180 pièces. Le terminal A enregistre un lot de 12 pièces, le terminal B un lot de 20, à quelques millisecondes d'écart.

Le scénario tient en six échanges, et rien n'y est anormal pris isolément. Le diagramme se lit de haut en bas, dans l'ordre du temps : une flèche pleine est une demande, une flèche en pointillé une réponse. Regarder les deux premières réponses du compteur : elles donnent la même valeur, 180, à deux interlocuteurs différents. Tout le défaut est déjà là.

Deux lots ont été enregistrés, un seul subsiste : le compteur affiche 200 pièces au lieu de 212, et les 12 pièces de A ne figurent plus nulle part. Aucune exception n'est levée, aucun test ne le voit, et le défaut n'apparaît que sous charge, à la relève, quand tous les postes déclarent leur production en même temps.

Ce défaut a un nom, la perte de mise à jour. Le remède est un contrôle au moment d'écrire : vérifier, quand B veut écrire 200, que le compteur vaut toujours 180. S'il vaut 192, l'écriture est refusée ; B relit 192 et recalcule 212. Ce contrôle ne dépend d'aucune famille, et un programme procédural peut le faire aussi bien qu'un autre. Le style fonctionnel ne suffit pas non plus, à lui seul, à éviter le défaut : deux fonctions pures parties du même 180 calculeraient encore 192 et 200. Ce qu'il apporte, c'est que le calcul ne touche à rien : il rend un nouvel état, et l'état dont il est parti reste connu, ce qui est exactement ce que le contrôle doit comparer. Ce contrôle est le métier d'une base de données, celui des transactions.

Choisir une famille

La bonne question n'est jamais « quel est le meilleur paradigme », mais « lequel pour ce problème, sous ces contraintes ». La méthode tient en trois questions, qui reprennent la carte.

1. Le programme a-t-il un état qui dure et qui change ? Un script qui transforme des données sans rien garder n'en a pas : fonctionnel, ou une simple suite d'étapes. Une simulation, une machine pilotée, une session d'utilisateur en ont un : objet.
2. Cet état est-il partagé, entre plusieurs parties du programme ou plusieurs utilisateurs ? Si oui, l'immuabilité cesse d'être une élégance pour devenir une garantie, et l'écriture partagée demande un contrôle, celui d'une base de données.
3. Le domaine a-t-il déjà un langage déclaratif ? Calcul entre des cases, requête sur des données, validation d'un format : inutile de réécrire en étapes ce qu'un tableur, SQL ou une expression régulière fait mieux.

La cellule et la variable, pour finir

La question d'ouverture opposait une case de tableur qui suit ses données à une variable Python qui ne les suit pas. La différence ne vient ni de Python ni du tableur, elle vient de la famille. La formule du tableur est déclarative : elle énonce une relation, que le moteur maintient vraie. L'affectation Python est impérative : une étape faite une fois, dont le résultat ne sait plus d'où il vient. Aucune des deux n'a tort. La case convient à une feuille qu'on fait varier pour voir, le script à une suite de traitements qu'on veut maîtriser pas à pas.

Ce qu'il faut savoir d'un programme avant de lui confier des données que d'autres modifient tient en trois points.

• Où vit son état : dans une variable ouverte à tous, dans un objet derrière ses méthodes, dans des valeurs qui ne changent plus, ou dans un moteur.
• Si cet état est à la fois partagé et modifiable : c'est leur rencontre, et non l'un ou l'autre, qui produit les défauts, de la sauvegarde qui bouge avec l'original au lot de pièces écrasé.
• Ce qui protège l'écriture, et à quel prix : une copie, une valeur immuable ou un contrôle au moment d'écrire, payés en recopies, en mémoire ou en vérifications.

La méthode

1. Nommer la famille avant de décrire une solution : « une requête », « une classe », « des fonctions pures » situent tout ce qui suit.
2. Dire où vit l'état : une variable ouverte à tous, un objet derrière ses méthodes, des valeurs successives, un moteur. C'est la question qui distingue les familles.
3. Prévoir avant d'exécuter : pour chaque affectation, copie ou appel, compter les objets qui existent et dire lequel change.
4. Chercher le partage : deux noms sur un même objet, une fonction qui modifie la liste reçue, deux utilisateurs qui écrivent la même donnée.
5. Couper la rencontre du partage et de la mutation : une copie profonde, une valeur immuable, une fonction qui rend du neuf, ou un contrôle au moment d'écrire.
6. Citer le coût de la parade : des recopies, des versions à garder, des vérifications. Une solution dont on ne dit pas l'inconvénient n'a pas été examinée.

Mettre en pratique

Le débat sur l'état modifiable se tranche aussi par un comptage, celui des cas qu'il faut essayer pour éprouver une fonction. C'est l'argument le plus concret en faveur des fonctions sans effet de bord.

La dernière réponse ne dit pas qu'une fonction pure a moins de cas : si elle avait besoin des mêmes dix informations, elle les recevrait en paramètres, et le compte serait le même. Elle dit où ces cas se trouvent. En paramètres, ils sont écrits dans la signature, et chacun s'essaie en une ligne de test. Cachés dans l'objet, ils ne se voient pas à l'appel : il faut d'abord amener l'objet dans chacun de ses $2^{10} = 1024$ états par une suite d'appels avant de vérifier quoi que ce soit. Personne ne le fait, ce qui veut dire que personne ne sait vraiment ce que cet objet fait dans la plupart de ses états.

Les deux parades de la fin du chapitre ont aussi un prix qui se compte : les recopies du journal fonctionnel, et les pièces perdues quand plusieurs écritures partent de la même lecture.

Ce que « sans effet de bord » achète réellement. Une fonction dont le résultat ne dépend que de ses arguments se raisonne seule, se teste seule, et se remplace par son résultat partout où elle apparaît. Les trois propriétés viennent du même fait : il n'existe aucun contexte à connaître pour prédire ce qu'elle rend.

Ce n'est pas une raison de bannir l'état, qui est parfois exactement ce qu'il faut représenter, comme le niveau d'une cuve. C'est une raison de savoir où il se trouve, et de le tenir à un seul endroit plutôt que dispersé.

Les notions employées ont toutes été rappelées plus haut : l'effet de bord avec la version procédurale, l'encapsulation avec la version objet, la fonction pure avec la version fonctionnelle, le déclaratif avec le tableur et SQL. Répondre par écrit, en quelques phrases, avant d'ouvrir la réponse.