[Atom] [Mail] [Twitter]
Liens : git · hacks · divers · cabale · planète · à propos +

Cohérence des effets de bord

Réactions
<. Détection automatique de bugs

Ce week-end, je me suis promis que je rédigerai, pour le prochain article que je lirai en entier, un court résumé de deux ou trois paragraphes, pas plus, pour cesser d’écrire des réactions à la longueur démesurée. Voici le résultat.

Coherent Reaction (pdf, 8 pages) est un papier de Jonathan Edwards (pas le prédicateur américain), un type intéressant dont le blog s’appelle Alarming Development (Dispatches from the Programmer Liberation Front). C’est aussi le créateur du langage de programmation visuelle Subtext.

Problématique

En travaillant sur Subtext, il s’est rendu compte que l’ordonnancement des effets de bords pose problème dans un programme interactif (avec une interface utilisateur, comme par exemple des formulaires Web). Son exemple, dans un cadre MVC classique, est le suivant : imaginez qu’on travaille sur trois valeurs, qui pour avoir du sens doivent vérifier une contrainte de correction commune (par exemple la troisième, 5, doit être la somme des deux premières, 2 et 3). C’est le contrôleur qui vérifie ces contraintes : il dispose pour chaque valeur d’une fonction de vérification.

Maintenant, si on change deux de ces valeurs en même temps (la première à 4 et la troisième à 7), il y a risque de "fausse erreur" si les vérifications ne sont pas faites dans le bon ordre : si on modifie la première valeur à 4, puis on vérifie, on a une erreur (la contrainte n’est plus vérifiée, car 4 + 3 ne vaut pas 5) alors que si on avait modifié les deux ensemble tout se serait bien passé.

Il y a aussi des situations ou l’ordre de modification est important : fondamentalement, on voudrait que chaque modification s’effectue en parallèle, indépendamment, mais les langages impératifs effectuent les effets les uns après les autres, donc il y a toujours un risque d’interférence.

Les solutions classiques proposent que le modèle donne plus d’informations sur les contraintes liées au données : quelles sont les données liées, par exemple, pour qu’on les modifie toujours toutes en même temps au lieu d’une par une. Leur inconvénient, d’après l’article, est une perte en modularité, puisque cela révèle une partie de l’implémentation du modèle.

Coherent Reaction

Pour Edwards, le problème de fond est la difficulté à coordonner les effets de bords dans les langages impératifs classiques : plus les contraintes sont complexes, plus elles sont difficiles à gérer et donnent lieu facilement à des erreurs de programmation difficile à repérer. Il propose de libérer le programmeur des questions de coordination avec sa notion de cohérence, qui est une forme d’atomicité : le programmeur ne précise pas dans quel ordre faire les modifications, et c’est le programme qui le découvre par essais/erreurs : si des modifications produisent un état inconsistent ou introduisent des interférences, on les annule (rollback) pour les recommencer dans un ordre différent.

Il a aussi conçu, comme expérience pratique, un langage de programmation basé sur cette idée. C’est un langage dynamique centré sur les données (plutôt que les comportements, comme la POO), mettant en avant deux concepts :

dérivation

une façon de déduire des champs du reste de l’objet : on peut dire par exemple qu’un champ c dérive de la somme de deux champs a et b. Si l’un de ces champs est mis à jour, le champ c sera modifié en conséquence, pour maintenir cet invariant.

réaction

propagation de modifications dans le sens inverse de la dérivation : une réaction est une sorte de callback qui est exécuté quand le champ auquel elle se rattache est modifié

Ces deux mécanismes de transmission des modifications permettent de maintenir simplement l’état des données; pour les combiner, c’est le programme qui se charge de trouver un ordre des dérivations/réactions qui évite les interférences.

Remarques personnelles

J’ai apprécié cet article, mais peut-être un peu déçu : pour la réinvention des effets de bord, je m’attendais à quelque chose de plus profond. La discussion des travaux similaires, étendue dans la version longue du papier, est très intéressante.

Je ne suis pas tout à fait convaincu que cette idée peut être reprise dans le cadre d’un langage généraliste, mais elle pourrait être appropriée comme paradigme spécialisé des parties interactives d’un programme. La comparaison avec la programmation fonctionnelle réactive serait certainement intéressante, mais c’est un sujet que je ne connais pas (bien que j’envisage de m’y intéresser prochainement) donc je ne pourrais pas en dire plus.

Enfin, l’article se termine quasiment par un paragraphe, en réaction à une citation très classique d’Alan Kay, qui me semble tout à fait obscur. Je ne pense pas le comprendre, c’est bien trop flou/littéraire/psychologique pour moi, mais je pense qu’il pourrait intéresser certains lecteurs :

Smalltalk’s design—and existence—is due to the in- sight that everything we can describe can be repre- sented by the recursive composition of a single kind of behavioral building block that hides its combina- tion of state and process inside itself and can be dealt with only through the exchange of messages.
– Alan Kay : The early history of smalltalk

The conceptual model of Coherence is in a sense opposite to that of Object Oriented languages. As Alan Kay’s quote above indicates, the central metaphor of OO is that of mes- saging: written communication. The central metaphor of Co- herence is that of observing a structure and directly manip- ulating it. These two metaphors map directly onto the two primary mechanisms of the mind: language and vision.

[ tag:blog.huoc.org,2009:bluestorm/9 ]
Gabriel Scherer (bluestorm).
Le 22.01 2010 à 22:59.

[>] Commentaires[Atom]

# Cyprien_
30.01.10, 01:24.

Article intéressant sur le fond, mais j'avoue que j'aurais aimé en savoir plus sur, par exemple, la manière dont le programme va gérer l'apparition d'interférences, par exemple, comment différencie-t-il une simple interférence (donc à corriger en modifiant l'ordre des  effets de bords) d'une véritable incohérence (qui est donc à signaler comme toute erreur qui se respecte) ?

Par contre, je ne sais pas si tu as refréné ton envie d'écrire pour des raisons personnelles, ou bien parce que tu penses qu'un texte trop long risque de rebuter. Si c'est la deuxième hypothèse, personnellement, c'est toujours un plaisir de te lire, et j'avoue que la longueur de cette réaction me laisse un peu sur ma faim :p (mais ça n'engage que moi).

Merci, une fois encore !
[ tag:blog.huoc.org,2010-01-30:1264811082.20521 ]

# bluestorm
31.01.10, 08:58.

Pour l'instant, l'idée et le langage associé sont encore en gestation. C'est un article publié dans la conférence "Onwards!" qui s'intéresse à des idées nouvelles et pas encore éprouvées. Je pense qu'il ne gère pas certaines incohérences, par exemple on doit pouvoir provoquer des boucles infinies avec certains programme qui n'ont pas d'entrelacement correct.

Cette réaction est courte, parce que j'aimerais écrire plus de réactions.
D'une part, je ne suis pas satisfait de ma méthode actuelle : je survole beaucoup d'articles, j'en lis quelques uns, et je garde une trace écrite (résumé ou réaction) d'une petite fractions de ces derniers. J'aimerais mieux, à terme, me forcer à commenter plus souvent les articles que je lis, et c'est de là qu'est née l'idée des "réactions". Clairement, je ne peux pas me permettre de passer autant de temps sur chaque réaction que précedemment si je veux en publier plus.
D'autre part, cet article m'a un peu déçu, et je n'ai pas été motivé pour écrire quelque chose de très long. C'est la contrepartie de la volonté à terme de garder une trace de tout ce que je lis : il y aura aussi des choses qui me plaisent moins que les autres. Dans l'idée je pense que parler des papiers qui m'ont moins plu peut être aussi intéressant que parler des papiers qui m'ont plu, mais il faut faire attention à ne pas ennuyer le lecteur par vengeance.

Fondamentalement, je crois qu'il faut que je fasse des choix, entre publier un bon article long et très travaillé tous les deux mois, ou baisser un peu mon propre niveau d'exigence pour avoir des articles plus fréquents. C'est pas facile.


Je te remercie pour ton avis. J'ai bien vu que cette réaction n'avait pas motivé l'enthousiasme des foules, mais c'est beaucoup plus utile pour moi qu'on me dise comme tu l'as fait ce qui gêne ou pose problème.
[ tag:blog.huoc.org,2010-01-31:1264924737.27336 ]

# SpiceGuid
31.01.10, 16:49.

À mon avis certains articles ne veulent pas fermer des portes arbitrairement. Du coup ils peuvent paraitre plus algorithmiques qu’ils ne le sont en vérité.

Quand je lis ce genre de phrase :

"Coherence retains mutable state, abandoning only the Program Counter."

Je ne peux pas m’empêcher de penser que l’article traite en fait du problème de la cohérence dans la maintenance des bases de données. Quand un modèle est trop centré sur la dynamique des données ça en fait une technique d’IA ou de SGBD. Eventuellement ça pourrait aussi être un DSL pour GUI, CAO et 3D interactive.

En développant son propre interpréteur plutôt qu’une librairie pour un langage existant l’auteur prend le risque de faire apparaître la faiblesse de son approche dans le cas général tout en masquant les éventuels avantages par rapport aux approches concurrentes comme le tout impératif ou la FRP.

[ tag:blog.huoc.org,2010-01-31:1264952962.22851 ]

# Alp
14.03.10, 01:18.

Pas directement lié mais intéressant quand même : http://www.cs.bath.ac.uk/~cf/eff_hyper.pdf
[ tag:blog.huoc.org,2010-03-14:comments/1268525915.24416 ]

Nouveau commentaire