C’est typiquement le genre d’article qui nécessite des corrections, des remarques et peut-être un débat. Alors n’hésitez pas.

Code et data

Pas de code sans données, car le but d’un code est de tourner et de produire des résultats et, pour ce faire, le code doit “manger” des données.

On peut voir le code dans sa forme la plus abstraite comme un algorithme dont le rôle serait de produire des preuves. Mais on peut aussi voir le code comme un algorithme qui ne fait pas simplement que valider et prouver mais également qui produit des changements d’états et des évènements qui, au sens littéral du terme, changent le monde.

On a ici un parallèle avec les “speech acts” de Searle et Austin dont Henry Story avait parlé dans son intervention au MeetUp Semantic Web de Février 2011.

Quiconque écrit un programme s’attend en effet à “changer le monde”, ne serait-ce que pour écrire “Hello World” sur un terminal. Changer le monde avec des algorithmes et du code, Microsoft, Google,  Facebook et d’autres l’on fait, et l’ensemble des développements en Open Source peut-être plus encore.

Pas de code sans données donc.  Or ces données sont stockées dans des supports de mémoires différents selon qu’elles sont en mémoire vive, sur un système de fichier, ou dans une base de donnée. Et chaque support de mémoire utilise un modèle de données qui n’est pas forcément le même. Ce qui nous ramène à la difficile collaboration entre les développeurs et les gestionnaires de base de données.

Si les développeurs et les administrateurs de base de données doivent collaborer, la réalité est parfois toute autre : les développeurs ne comprennent pas toujours le SQL et les RDB (bases de données relationnelles), et les DBA (administrateurs de base de données) ne voient les développeurs que comme de dangereux cowboys qui veulent massacrer l’intégrité de leur données (“mon précieux …”).

Le DBA

Le développeur

“Impedance mismatch”

La réalité est que les modèles de données utilisés dans les langages développement et dans les systèmes de stockage des données ne sont pas les mêmes : modèle objet et modèle tableau.

C’est ce qu’écrivait Yves-Marie Pondaven, que je citais également dans mon intervention au MeetUp Semantic Web de Décembre 2010, et dont je reproduis ci-après le schéma qu’il avait fait et dans lequel on voit que l’on passe son temps à basculer du modèle relationnel au modèle objet puis au modèle document et inversement.

Aussi disais-je que la plupart des CPUs de la planète sont occupés à faire des transformation et re-transformation entre des modèles de données différents. On peut donc au moins dire que cela a un impact en terme de performance mais aussi en terme environnemental non négligeable (de l’ordre de l’impact carbone sur la planète de toute l’industrie du transport aérien).

Cette question des différences entre les modèles de données n’est pas nouvelle, et elle a d’ailleurs fait l’objet d’une discussion intéressante entre Michel Volle et Laurent Bloch. Plus généralement, elle fait référence à “l’impedance mismatch” de George Copeland & David Maier 1984:

The problem with having two languages is“impedance mismatch ” One mismatch is conceptual – the data language and the programming languages might support widely different programming paradigms. [...]

The other mismatch is structural -thelanguages don’t support the same data types, [...]

Objets versus Tables

Avec les travaux d’Erik Meijer, de chez Microsoft Research, on peut essayer d’aller plus loin dans l’analyse de la situation, et je vais suivre à présent son argumentation, telle qu’il a exposé lors du WebWorkers Camp parisien du 16 avril 2011, et en faisant référence au papier qu’il a publié en Mars 2011 : A co-Relational Model of Data for Large Shared Data Banks.

L’objet-graphe et le stockage par clé/valeur (Key/Value)

Tout commence par une citation de Donald Knuth :

“I do consider assignment statements and pointer variables to be among computer science’s most valuable treasures.”

Pourquoi Meijer souligne-t-il ainsi l’importance des pointeurs pour ensuite assimiler l’équivalence entre le modèle objet et le stockage par clé-valeur ? :

“In the rest of this article we conveniently confuse the words object (graph) and key-value store.”

Deux choses ici :

1. D’une part, l’équivalence entre objet et graphe.
2. D’autre part, l’assimilation du modèle objet au mécanismes de stockage par clé-valeur.

Si l’objet est assimilé à un graphe c’est parce qu’une des caractéristiques de l’objet est d’avoir la structure d’un graphe, à savoir que les objets sont reliés entre eux par des relations qui, en l’occurence, sont dirigées (d’où la flèche) :

Référons-nous à wikipedia (article sur Object Graph) pour comprendre l’assimilation de l’objet-graphe à un mécanisme de stockage des données clé-valeur :

“An object graph is a directed graph, which might be cyclic. When stored in RAM, objects occupy different segments of the memory with their attributes and function table, while relationships are represented by pointers or a different type of global handler in higher-level languages.”

Un Objet est donc stocké en mémoire en encapsulant avec lui avec tout ce qui le caractérise (attributs et fonctions). Si cet objet-graphe est stocké dans différentes parties – ou segments – de la mémoire, les relations entre ces différentes parties, elles, sont représentés par des pointeurs (ou par des mécanismes plus généraux embarqués dans les langages de plus haut niveaux). Les pointeurs étant des types de données dont la valeur est l’adresse vers un autre objet stocké en mémoire.

Paradoxalement, le concept de pointeur rebute souvent les étudiants en informatique alors que l’architecture du web qu’ils utilisent tous les jours en est exactement la mise en oeuvre avec des ressources stockées qui sont accessibles via des relations qui sont représentées par des adresses, les URLs.

Voilà donc pour le côté “stockage en mémoire” des objets manipulés par les programmes. Basiquement, il s’agit d’un mode de stockage de type Key -Value qui représente une part importante de l’utilisation des bases NoSQL et sur lequel, je l’ai dit, repose l’architecture du web (de là à justifier le NoSQL comme mouvement surdéterminé par l’architecture du web, comme son milieu technologique d’émergence, il n’a qu’un pas).

Le stockage de données par tables

Passons maintenant au modèle utilisé par les bases de données relationnelles, représenté non plus par des objets mais par des tables.

Par rapport au modèle objet, la table va fractionner les données pour les lier d’une manière différente du modèle avec pointeur utilisé pour l’objet-graphe.

Alors que la manipulation des donnés en mémoire sous forme de graphe était au plus proche de leur mode de stockage physique en RAM, le modèle relationnel va “plaquer” un mode de stockage et de requêtage qui repose sur le modèle des tables. D’ailleurs, la première chose que l’on fait pour créer une base de données c’est d’écrire :

CREATE TABLE.

Ici il n’y a plus seulement une adresse pour une valeur (Key-Value), mais une valeur ( la primary key) dans plusieurs lignes. C’est la raison pour laquelle le modèle relationnel est aussi appelé Primary/Foreign Key.

Les contournements du modèle relationnel

Le modèle relationnel n’est pas évident dans sa compréhension et dans son utilisation. Meijer souligne tout cela par un raccourcit ironique :

1. Le concepteur de base de données enlève la structure originairement hiérarchique et objet pour lui appliquer un modèle normalisé par Tables ;
2. Le développeur doit ensuite retrouver la forme objet-graphe originale pour son développement. On a ainsi eu une vague d’ORM (Mapping Objet/Relationnel) qui, comme leur nom l’indique ajoutent une sur-couche objet au modèle relationnel afin que le programmeur puisse utiliser le stockage relationnel sans en connaître toutes les subtilités ;
3. Même du côté de la base de données, celui qui l’implémente doit rajouter une couche de stockage objet-graphe et Clé-Valeur en construisant un index de la base de données, en marge du modèle par Tables, pour pré-calculer des réponses à des requêtes.

A croire que, dès qu’on veut utiliser les bases de données relationnelles, il faille changer de modèle de données pour en revenir au modèle objet-graphe et le stockage par Clé-Valeur.

Sortir de l’aporie

Jusqu’ici rien de bien nouveau dans le “dysfonctionnement relatif” entre modèle Objet et modèle Relationnel, si ce n’est la montée en puissance des base NoSQL. Mais celles-ci n’ont pas vraiment de modèle de requêtage très élaboré (pas de modèle mathématique) : en effet il y a plutôt des recettes de requêtage dans le monde NoSQL.

Là où Meijer est intéressant, c’est dans la manière dont il formule le problème pour dépasser la vision d’opposition entre SQL et NoSQL. De la logique d’opposition on bascule alors dans une logique de composition, et les choses deviennent beaucoup plus claires.

Meijer, tel Ménon, fait son petit schéma (fig. 6 pour le modèle objet, et fig.7 pour le modèle en tables) et constate que :

• le modèle objet est défini par intension
• le modèle table est défini par extension.
• et surtout, on voit bien sur le schéma que le sens des flèches est inversé.

Je rappelle brièvement qu’une définition par intension décrit la liste des propriétés qui doivent être vérifiées pour qu’un élément appartienne à l’ensemble ainsi défini. Dans la définition par extension c’est la liste des éléments qui définit l’identité de l’ensemble :

“Toute classe d’éléments peut être définie en extension (en nommant ou en désignant chaque individu qui en fait partie) ou en intension, par une description (spécification d’un certain nombre de prédicats) qui définit la classe. L’intension s’identifie ainsi au concept. »

Par exemple, la classe des rois de France peut être désigné extensionnellement en donnant une liste de noms, ou intensionnellement par le concept « roi de France » (c’est-à-dire le prédicat, la propriété « être un roi de France »).” Intension et Extension, Wikipedia.

En informatique, toute donnée doit être porteuse d’une identité qui la distingue de toute autre donnée. Toute donnée, c’est à dire toute information disponible pour un calcul, doit disposer d’une identité. Et celle-ci passe par un référent (par exemple un identifiant), qui n’est autre qu’une métadonnée (Cf. Sur les métadonnées).

Il se trouve qu’avec le modèle objet-graphe, la métadonnée qui sert de référent pour l’identité de l’objet n’est pas une valeur mais l’adresse d’une valeur (le pointeur). Alors qu’avec le modèle en Tables, la métadonnée est une valeur (c’est la clé primaire).

La métadonnée qui sert de référent peut donc être définie par intension ou part extension :

• par intension, on a une clé qui est une adresse
• par extension, on a une valeur (clé primaire) qui est présente dans toutes les lignes des tables qui constituent l’identité de l’objet.

On comprend aisément la forte contrainte d’intégrité requise pour les bases de données relationnelles : une modification doit se déployer sur l’ensemble du système, de manière extensive, pour en garantir l’intégrité. Avantage à la maîtrise des données mais difficultés à passer à l’échelle du web.

Mais avec son petit schéma, Meijer, remarque que le modèle Objet et le modèle Table sont fort similaires : ce sont des graphes orientés, mais avec une orientation inverse :

Ne manque plus qu’à Erik Meijer de chercher “Mathematics arrow reverse” dans Google pour tomber sur la page Wikipedia de la théorie mathématique des catégories.

Théorie mathématique des catégories et le concept de dualité : “NoSQL is CoSQL”

De la théorie mathématique des catégories, Meijer retient le concept de dualité, ou catégorie duale :

À partir d’une catégorie opposée ou duale, en prenant les mêmes objets, mais en inversant le sens des flèches.

Plus précisément :

Il est clair que la catégorie duale de la catégorie duale est la catégorie de départ :

Cette dualisation extrêmement simple permet de symétriser la plupart des énoncés, ce qui peut être douloureux pour les débutants…

Ce “détour” par les mathématiques permet finalement à Meijer d’affirmer que :

• SQL et NoSQL ne sont pas incommensurables et incompatibles ;
• NoSQL s’appuie en fait sur un modèle de donnée qui reléve d’une catégorie duale où l’on a les mêmes objets mais en inversant le sens des flèches ;
• Donc NoSQL est en fait CoSQL ;
• A partir de là, on peut fonder les modes de requêtes NoSQL sur une théorie mathématique, comme s’était le cas pour SQL, ce qui permettra non seulement de standardiser les requêtes pour différentes bases NoSQL mais aussi de fonctionner pour les bases SQL.

Le rôle d’une interface est précisément de faire cohabiter des modèles différents, qui ne sont certes pas opposé et incompatibles sans quoi l’existence même d’interface ne saurait être possible.

Avec son langage de requêtage “universel” LINK, Meijer ne fait rien d’autre que d’avoir trouvé, via le recours aux théories mathématiques, une interface entre des modèles qui étaient présentés comme apparemment opposés. L’interface est à ce tire une composition.

Bien qu’étant universel sur le papier, LINK reste toutefois implémenté dans le monde .NET. Il faudrait donc une implémentation de cette démarche pour chaque langage pour parler vraiment d’un langage de requête universel.

Langage fonctionnels purs et monades

On connaît l’implication de Meijer dans la valorisation, la promotion des langages fonctionnels et notamment de Haskell (je vous renvoie à mon article Apprendre Haskell dans lequel je donnais les liens vers les tutoriels video de Meijer sur Haskell).

En fait, l’approche qu’il a implémenté avec LINK lui a été soufflé par les monades en Haskell. Pourquoi celà ?

Rendre compatible ce qui est incompatible est précisément le rôle des monades en Haskell. Puisque le langage est pur et fonctionnel (aucun effet de bord et immutabilité) il ne peut interagir avec le monde et le changer, il faut définir un lieu d’où les effets de bord (comme l’impression sur un terminal) seront quand même possibles.

Les effets de bord sont souvent dûs à des erreurs du point de vue des Types des données manipulés. Par exemple la fonction qui affiche l’heure n’est pas pure car à chaque fois qu’on demande la valeur, la fonction produit un résultat différent (l’heure tourne). Donc, un travail sur le Type System peut contourner la difficulté en considérant que la fonction ne revoie pas un INT mais un CHAR : on a contourné l’effet de bord en maîtrisant la définition par intension de la fonction dans la configuration des types.

Pour bien comprendre l’intérêt de cette question, on peut y retrouver un usage dans les architectures RESTful. Ainsi « Idempotence » en REST signifie « Pureté » en langage fonctionnel : la valeur d’une fonction ne change pas dans le temps (pas d’effet de bord). Par où l’on voit que le style d’architecture REST est un style qui s’appuie sur une architecture fonctionnelle pure par défaut : POST n’est pas une fonction idempotente (pure) car elle va modifier l’état du système.

Mais toute approche fonctionnelle pure doit composer avec le non-pur. Les programmes sont faits pour changer les états de systèmes et pour changer le monde. Les monades sont faîtes pour effectuer cette composition en créant des Types qui vont décrire ces effets de bord (IO, Exception, Animation, Collection). Les exceptions sont intégrées et gérées par le système qui conserve ainsi sa pureté grâce à son Type System (il n’y a pas que Haskell qui utilise cette approche par monades, Java aussi avec “throws Exceptions”).

Les monades transforment ce qui est mutable en quelque chose d’immutable (mutable et immutable étant les termes informatiques anglais utilisés).

En fait, je me demande si la modification que l’on fait avec les monades ne consisterait pas à définir de nouveaux Types non plus par intension mais par extension.

SQL et CoSQL à la lumière du concept de métastabilité.

Meijer rapproche l’articulation, qui est composition, entre SQL et NoSQL à celle du Ying et du Yang chinois, l’un désignant l’ouvert et l’autre le fermé. Puis il expose la dualité, au sens mathématique du terme, entre SQL et CoSQL, entre le fermé et l’ouvert :

On reconnaît dans cette distinction celle que j’avais essayé de faire entre technologies de gestion et technologies relationnelles, c’est à dire entre stabilité et métastabilité (Cf. Les technologies relationnelles dans les systèmes d’information et Métastabilité et archtitectures logicielles )

Le sens des flèches : des flèches du web au PageRank de l’index de Google.

Ouverture et métastabilité du web.

J’ai déjà rappelé l’anecdote à propos de Tim Berners Lee qui n’avait pas trouvé d’investisseur lors du Symposium sur les systèmes hypertextes en venant présenter son invention : le web.
Ceux qui pensaient en matière de technologies de gestion et de système clos et stable ne comprenaient pas l’intérêt d’un système métastable comme le web qui ne garantissait pas l’intégrité du système. Par exemple on peut faire des liens vers des ressources qui n’existent pas et provoquer une erreur. Seulement voilà, cet effet de bord est prévu dans le web, c’est précisément l’erreur 404 que connaît et intègre le système (utilisation du principe de la monade) et qui fait qu’un lien brisé n’a jamais empêché le web de fonctionner.

Google : à rebrousse-poils du web

Le projet backrub, qui fut l’ancêtre de Google et du PageRank, prenait le web à rebrousse-poil en se proposant d’identifier les pages HMTL qui lient une page donnée (Cf. L’idée qui fonda Google). C’est prendre le web à rebrousse-poil car les liens HTML sont reconstitués à l’envers : dans un cas la page HTML est le “parent” qui contient les liens vers les pages “enfants”, dans l’autre c’est les pages “enfants” qui lient vers la page “parent” pour lui donner un poids (un ranking).

A ce titre, on peut dire que le modèle d’affaire de Google s’est constitué mathématiquement comme une dualité du web, selon la théorie des catégories : Google = Co(Web).

*

Il serait intéressant de rejouer ce raisonnement en y intégrant ce qu’écarte Meijer, à savoir les bases NoSQL qui ne sont pas sur le modèle document clé-valeur mais sous une forme d’un graphe typé. C’est à dire en prenant en compte les éléments de la présentation (slides) An Overview of Data Management Paradigms: Relational, Document, and Graph, de Marko Rodriguez.

Related posts:

1. Sens et enjeux des RIA Je suis donc intervenu au RIA 2008 d’Adobe en insistant...
2. Prendre soin des données Sur le blog d’Atos Origin je reviens sur les enjeux...
3. Les enjeux de la grammatisation des relations (Les illustrations sont de Pavel.K, dessinateur, caricaturiste et illustrateur, que...

Haskell est un langage de programmation fonctionnelle. Un style de programmation où l’on utilise des fonctions plutôt que des objets, contrairement au paradigme de la programmation orientée objet.

Je ne vais pas refaire ici la liste des caractéristiques de la programmation fonctionnelle et de Haskell en particulier. Le souhaite juste indiquer rapidement quels sont les enjeux et quelles sont les ressources que l’on peut utiliser pour s’y initier.

Pourquoi Haskell ? Parmi les nombreux langages de programmation fonctionnelle de grande valeur (Scheme, OCaml,F#, Erlang, etc), Haskell a un statut particulier car c’est le plus « pur » (il y a aussi Clean, mais plus confidentiel), c’est à dire celui qui vous contraindra le plus à embrasser le paradigme de la programmation fonctionnelle.

Les vertus de la programmation fonctionnelle sont, notamment, de pouvoir appréhender dans de bonnes conditions les problématiques de parallélisation et de concurrence induites par la crise des multicoeurs et les architectures hautement distribuées, ce pour quoi les paradigmes impératifs et objets sont dans une impasse.

L’évaluation paresseuse (lazy evaluation) permet d’optimiser les performances du code car les calculs ne sont faits par le programme que s’ils sont vraiment nécessaires.

Ensuite, le système de typage des données est statique, c’est à dire qu’il faut bien préciser la nature des données manipulées par les fonction quand on les défini. Cela peut paraître plus contraignant que le typage dynamique, mais cela garanti la sureté des programmes.

On peut dire aujourd’hui que tous les langages objets et impératifs tendent, dans leur évolution, à intégrer ce qui fait la force de la programmation fonctionnelle, alors pourquoi ne pas partir directement du modèle de référence plutôt que d’avoir des langages hybrides (scala, clojure, etc.) ?

Pour résumer la situation en matière d’évolution des langages, Simon Peyton-Jones présente le petit schéma que je reproduis ci-après, et dans lequel il montre bien que le Nirvana du programmeur serait d’avoir un langage utile et sain. Pour l’atteindre, soit l’on part du situation dangereuse mais utile (Java, C++, Python, C#, etc.) pour introduire progressivement des approches fonctionnelles dans ces langages, soit l’on part d’une situation saine (Haskell) mais peu utile (« peu utile » car dans l’idéal, un programme fonctionnel n’a aucun effet de bord, c’est à dire qu’il ne modifie pas le monde, il ne sert donc à rien) mais qui va implémenter des possibilités de modification de son environnement.

(on peut trouver sur le web plusieurs enregistrements vidéos de conférences données par Simon Peyton-Jones, toutes relèvent du gai savoir çà vaut le détour.)

On voit que la philosophie Haskell est très cartésienne : on fait une tabula rasa pour partir d’une situation saine à partir de laquelle on va accepter d’implémenter des effets de bords maîtrisés (les fameuses monades) et non arbitraires.

Là où le programmeur Java va passer son temps à gérer les effets de bords dus à son style de programmation (il ne cesse de dire au programme ce qu’il doit faire de manière procédurale puis doit ensuite faire des batteries de tests unitaires pour revérifier son travail) le développeur Haskell va laisser le programme faire son boulot. Par nature, le programmeur Haskell à confiance dans son code alors que le développeur Java est dans une relation de méfiance.

*

En matière de ressources bibliographiques, on commencera par indiquer le livre Introduction to functionnal programming using Haskell de Richard Bird. C’est un livre théorique, donc si vous êtes un développeur sans appétence pour les aspects les plus abstraits et conceptuels, il faut passer votre chemin. Toutefois, il y a fort à parier que c’est un livre que l’on sera amené à consulter régulièrement quand on se retrouvera face à des questions de fond quant à la meilleur manière de faire,  et également pour améliorer son « esprit Haskell ».

Ensuite, une mention spéciale pour l’ouvrage de Graham Hutton, Programming in Haskell, qui est un livre magique. Tout y est : qualité du papier, typographie, excellence pédagogique, le tout en moins de 200 pages. De quoi donner des leçons à tous ces livres informatiques qui ressemblent à des catalogues de la redoute de plus de 500 pages pour ne rien dire d’intelligent. Pour moi, c’est le meilleur ouvrage de programmation qu’il m’ait été donné de lire, à recommander même à ceux qui ne veulent pas apprendre Haskell, c’est dire.

C’est sur la base de ce livre qu’Erik Meijer (une des têtes pensantes de Microsoft, passionné par les langages fonctionnels) propose, sur le Channel 9 de Microsoft, 13 cours vidéos pour s’initier au langage, un vrai régal :

1. Introduction
2. First steps
3. Types and classes
4. Defining functions
5. List comprehensions
6. Recursive functions
7. Higher-order functions
8. Functional parsers
9. Interactive programs
10. Declaring types and classes
11. The countdown problem
12. Lazy evaluation
13. Reasoning about programs

Je signale également le livre Haskell school of Expression, de Paul Hudak, pour ceux qui veulent utiliser la programmation fonctionnelle dans un contexte multimédia et artistique :

 

Paul Hudak que l’on peut voir dans cette vidéo, donnant une conférence sur « Haskell and the arts : How functionnal programmers can help, inspire or even be artists », enregistrée à Qcon San Fransisco en novembre 2008.

Enfin, la consécration, un ouvrage de référence chez O’reilly, le fameux Real World Haskell, que je déconseille toutefois avant d’avoir lu « Programming in Haskell » de Graham Hutton. On a ici un ouvrage mainstream, comme tant d’autres, mais fort utile pour faire du Haskell « dans la vraie vie ».

Sur les autres ressources, on ira sur Haksell.org, le portail qui rassemble toutes les infos utiles. À noter que depuis quelques mois un effort a été fait sur les packages d’installation avec The Haskell Platorm.

Pour les librairies on utilisera le génial Hoogle.

Côté des frameworks web, il y a Happstack, le plus ancien, mais aussi Snap qui, bien qu’en phase beta, semble jouir d’une bonne dynamique et donne des premières perspectives de performances intéressantes (ici les performances d’accès à des fichiers, plus est mieux):

Enfin, et pour terminer,  la petite blague sur Haskell qui a circulé sur Twitter, relativement à « l’évaluation paresseuse » (Lazy evaluation) dans Haskell, où les calculs ne sont effectués par le programme que s’ils sont nécessaires:

Put #Haskell on your resume even if you don’t know it. When asked, say your resume is lazy and you’ll learn it when results are needed.

Bonne initiation !

Related posts:

1. Recrutement Je cherche à recruter un ingénieur junior avec une formation...
2. Introduction à XML Une introduction n’est pas, disait Heidegger, quelque chose de général...
3. Multicore crisis : la crise des multicoeurs La loi de moore ne reflète plus l’évolution du marché...

Le processus de grammatisation décrit par Sylvain Auroux n’est pas à proprement parler le même que celui dont se sert Bernard Stiegler.

Chez Auroux, il représente la constitution de l’outillage grammatical (grammaires et dictionnaires) des langues vernaculaires à partir des travaux effectués par la tradition greco-latine :

«Par grammatisation, on doit entendre le processus qui conduit à décrire et à outiller une langue sur la base des deux technologies qui sont encore aujourd’hui les piliers de notre savoir métalinguistique: la grammaire et le dictionnaire.»

Chez Stiegler, sans qu’il y ait pour autant contradiction avec l’acceptation d’Auroux, il s’agit plus du passage d’un continu temporel (d’un flux) à un discret spatial (un flux engrammé), une forme fondamentale de l’extériorisation des flux dans ce qu’il nomme les rétentions tertiaires :

« J’appelle grammatisation un processus dont la littération n’est qu’un moment. Non pas un moment parmi d’autres, puisqu’il rend possible la pensée de la grammatisation elle-même, mais un moment dans une tendance à la discrétisation du continu, supportée par ce que je nomme des rétentions tertiaires, et qui s’est aussi exportée dans les machines et les appareils. »

Avec Stiegler, le processus de grammatisation n’est plus seulement la grammatisation du language, c’est aussi celle des gestes : la machine outil qui remplace le geste de l’ouvrier est un événement qui s’inscrit pleinement dans le processus de grammatisation.

Cette notion d’engrammage, du grec en (dans) et gramma (écriture), qui se place comme une condition de possibilité du processus de grammatisation compris comme littération, doit être portée à ses limites. Par exemple, en se demandant : est-ce que tout peut être grammatisé, engrammé ? Pour répondre à cette question il faut dévoiler des mécanismes de base du processus de grammatisation.

La grammatisation porte en elle une double tendance. Elle est à la fois :

• analytique : elle distingue et elle découpe (par exemple les lettres de l’alphabet) ;
• synthétique : elle rassemble (par exemple dans des règles de grammaire).

Cette double tendance, comme principe moteur de la grammatisation, relève selon moi de l’algorithmie.

Le devenir algorithmique désigne dès lors le mécanisme inexorable qui est à l’oeuvre dans l’ensemble des processus de grammatisation, celui-là même qui nous pousse vers une numérisation de plus en plus importante de notre monde.

Or qu’est ce qu’un algorithme ? L’algorithme, écrit Philippe Flajolet dans l’encyclopédie universalis, est

«un schéma de calcul, sous forme d’une suite d’opérations élémentaires obéissant à un enchaînement déterminé».

Parler d’algorithme aujourd’hui, au XXI siècle,  c’est évidemment faire référence à un des derniers visages de la grammatisation et de l’engrammage qu’est la programmation informatique. Pourtant, la programmation n’épuise pas la question de l’algorithme, en ce sens que l’on ne programme que ce qui relève déjà du champ de l’algorithme.

A ce titre, on pourrait se demander si ce qui relève de l’algorithme n’est pas plus vaste que la définition mathématico-informatique qui lui est de nos jours systématiquement accolée. Ne peut-on pas affirmer, par exemple, que les activités suivantes relèvent de l’algorithmie :

• rédiger une recette de cuisine ;
• un passant qui vous indique le chemin pour trouver un lieu précis ;
• produire un mode d’emploi ou un guide d’utilisation ;
• écrire une partition de musique ;
• une interaction téléphonique avec une boîte vocale ;
• élaborer un processus de fabrication ;
• préparer et planifier ses vacances ;
• etc.

Il y a un devenir algorithmique dans la mesure où celle-ci joue un rôle de plus en plus important et visible dans nos vies. Ainsi le devenir algorithmique s’inscrit jusque dans ces conversations commerciales que l’on nous impose au téléphone avec les télévendeurs ou téléconseillers :

« La conversation avec le client doit être rapidement référée à un « script », qui sera ensuite lu mot à mot par l’opérateur. Ce dernier peut-être sanctionné lorsqu’il « sort » du script, ne serait-ce que pour faire une réponse intelligente ou compationnelle à son client. Ainsi, les « amorces », réponses aux questions et autres formules de civilités sont prévues en amont de la conversation. Les phrases sont « déclenchées en fonction de l’attitude du client ou de ses questions. Finalement ces scripts sont des manières de « tayloriser » la conversation : celle-ci est découpée en unités de base et exécutée. » Marie-Anne Dujarier, Le travail du consommateur, Ed. La décourverte, 2008, p.27.

Ce devenir algorithmique ne va pas sans poser un certain nombre de questions :

• tout d’abord il y a beaucoup de travail pour réévaluer l’impact et la généalogie de cette tendance et ceci de façon éminemment transdisciplinaire ;
• ensuite parce que l’algorithmisation de nos vies pose un sérieux problème à l’économie libidinale. Comment en effet ne pas s’inquiéter si nos vies deviennent le fruit d’un « schéma de calcul (…) obéissant à un enchaînement déterminé » ?

Il me semble que la question du passage d’une économie de la consommation à une économie de la contribution ne pourra pas faire l’impasse d’un travail et d’une réflexion sur ce devenir algorithmique.

Related posts:

1. Platon, mémoire et grammatisation Dans le phèdre 274c-275b, Platon évoque une légende égyptienne où...
2. Le devenir algorithmique (4) : les jeux d’écriture Dans une précédente note sur les première pratiques scripturales dans...
3. Le devenir algorithmique (3) : l’invention de l’hypothèse Ce que je recherche, c’est l’apparition d’un discours hypothétique. Apparition...

Tristan Nitot se fait l’écho du lancement de Bespin par les Mozila Labs.

Bespin est pensé comme un outil de développement web collaboratif. A l’image de Google Docs pour la bureautique, l’idée et de n’avoir le code source qu’en une instance et de collaborer à plusieurs autour du code. C’est également la possibilité de retrouver son environnement de développement depuis n’importe quel ordinateur connecté au web.

Ça commence léger avec uniquement des codes couleurs pour HTML, CSS et Javascript mais l’initiative est importante, surtout venant d’un acteur du libre comme Mozilla.

Related posts:

1. Littérature de code J’aime bien lire les commentaires de code. Il y a...
2. Le code et l’écriture Après la publication de Littérature du code et la lecture...
3. Les marchés financiers enfin expliqués [kml_flashembed movie="http://www.youtube.com/v/SJ_qK4g6ntM" width="425" height="350" wmode="transparent" /] Vu chez Marc Andreessen ...

La table ronde sur le futur des applications Web, qui a eu lieu dans le cadre du lancement d’eXo WebOS, a été filmé et vous pouvez voir la video sur le blog d’eXoPlatform.

Crédit photo : Didier Girard

Sur la photo :
Michael Chaize (Adobe)
Christophe Lauer (Microsoft)
Eric Mahe (Sun)
Tristan Nitot (Mozilla)
Dave Armstrong (Google)
Benjamin Mestrallet (eXo Platform)
Christian Fauré (Atos Origin)

Related posts:

1. eXo Enterprise WebOS J’aurai le plaisir d’animer la table ronde qui aura lieu...
2. Le code collaboratif en ligne Tristan Nitot se fait l’écho du lancement de Bespin par...
3. Adobe RIA 2008 A l’invitation d’Adobe, Je ferai l’allocution d’ouverture de l’évènement annuel...

Petit à petit, l’écosystème des plates-formes web de développement (DaaS, Developement as a Service) commence à se dessiner.
Dressons une petite liste : il y a Amazon (+Heroku ), SalesForce, récemment Google avec Google Apps Engine, puis de plus petits acteurs comme Bungee Labs, Coghead, Rollbase, et aujourd’hui Intuit.

Même Microsoft semble être de la partie avec l’annonce d’EXP Platform. Ray Ozie est d’ailleurs explicite dans le changement de vision auquel il invite Microsoft :

We have an unprecedented opportunity to run A/B tests with online users and innovate more quickly based on actual user response.
Microsoft needs to shift the culture from planning the exact features to planning a set of possible features, and letting customers guide us
– Ray Ozzie, Chief Software Architect         

Quand on y pense, quoi de plus tentant que de faire faire les développements en crowdsourcing, plutôt que d’avoir à les réaliser soit-même ? C’est une bonne nouvelle car l’accès au développement va se populariser.

Ces plates formes ont un principal indicateur qu’elle doivent suivre : c’est la simplicité et la convivialité de l’ergonomie, et du design, des interfaces de programmation. Car c’est la condition nécessaire pour agréger un nombre important de développeurs qui feront grossir les services et l’attrait de la plate-forme.
Cela sera de plus en plus simple de développer des services web, tout au moins des services de base, et ce, en plus de la simplicité induite par les services d’infrastructure de la plate-forme.

Je crois que c’est là que s’est déplacé l’essentiel de la bataille du web.

Dans cette nouvelle phase, la communauté libre ne devra pas se focaliser sur l’opposition entre « logiciel libre » ou « logiciel propriétaire », mais plutôt s’organiser pour ne pas rester écarté de l’accès aux codes sources.

Related posts:

1. Le web comme un Hub et l’avenir du réseau selon Microsoft L’année qui vient de s’écouler a été une année importante...
2. Ironie du sort Le « slogan » de Microsoft pour décliner sa mutation vers le...
3. Table ronde sur le futur des applications Web La table ronde sur le futur des applications Web, qui...

Après la publication de Littérature du code et la lecture des commentaires à cette note, je me suis demandé s’il y avait des pratiques d’écriture qui évoluaient en s’imprégnant des pratiques du code.

On connaît tous cette pratique qui consiste à écrire, par exemple :

<troll>
Là je dis n’importe quoi
</troll>

Une XMLisation ou HTMLisation des pratiques d’écriture.
Ce qui va dans le sens des commentaires du niveau « humeur » que j’évoquais dans la note précédemment citée. Mais là, c’est l’inverse, puisqu’une syntaxe de programmation s’est invitée dans l’écrit.
Comme si le code pouvait retranscrire une forme de prosodie du discours, une intonation que les techniques d’écritures traditionnelle n’arrivait pas à exprimer aussi rapidement.

Et puis, aujourd’hui, je vois un tweet de Danny Ayers ou l’on peut lire :

« twitter: danja: google to me to dave pawson’s notes, disable-output-escaping= »yes », sorted. »

Enfin, « lire » est un bien grand mot.
Bien sûr, je ne comprends pas la signification du message. Mais j’y vois un étrange mélange d’écriture orthothétique et de code. Comme une phrase mutante.

De deux chose l’une :

• soit on a affaire à un jargon technique et corporatiste, comme peut l’être le louchebem des bouchers. C’est à dire à quelque chose d’anecdotique.
• soit, au contraire, on a affaire à une tendance qui confirme la trace d’une évolution de nos techniques d’écriture.

Je crois qu’en écrivant pour des machines, notre écriture s’en trouve changée. D’ici plusieurs dizaines d’années, peut-être que le texte que vous êtes en train de lire à cet instant paraîtra verbeux et maladroit au regard d’une écriture à venir qui aurait embrassée le charme et les pratiques du code.

<précision>
Je distingue cette écriture mutante du style SMS, qui est autre chose.
</précision>

Related posts:

1. Le stade anal de l’écriture Faites l’expérience suivante la prochaine fois que vous irez sur...
2. Littérature de code J’aime bien lire les commentaires de code. Il y a...
3. Une conséquence de la note précédente Question : savez-vous quelle est la première demande des utilisateurs...

J’aime bien lire les commentaires de code. Il y a une vraie littérature dans ces lignes écrites en langage naturel, dispersées au milieu des lignes de codes.

Bien sûr il n’y a pas que des chefs d’oeuvre, et même souvent il n’y a rien. Et rares sont les programmes que j’ai vu qui exploitent pleinement la force et l’importance des commentaires.

On a tort de penser que l’on écrit du code pour la machine. Je pense qu’on écrit du code pour qu’il soit lu par un tiers. Le cas échéant, ce tiers peut-être l’auteur lui-même.

En pensant que l’on écrit du code uniquement pour qu’il soit interprété par la machine, on oublie les points suivants :

• les langages avec lesquels nous programmons sont des langages bien particuliers car ils ne sont pas « parlés ». Ce ne sont que des langages écrits, sans réels pendant du côté de la pratique orale.
• ils doivent faire plus qu’un langage écrit, et pour cela il faut y introduire l’écriture d’une langue parlée : les commentaires.
• un code qui n’a pas de commentaire n’a donc pas de voix. Il devient potentiellement inaudible.
• un code sans commentaires n’a pas d’avenir, pas d’évolution possible : il peut bien faire ce qu’il fait, mais n’évoluera pas, ou peu. C’est comme s’il n’était pas remis dans le circuit, en circulation, pour pouvoir être modifié et réutilisé, ne serait-ce qu’à des fins pédagogiques.

Il faut dire que les mécanismes de commentaires par défaut sont très monotones.
Généralement un caractère spécial pour indiquer que c’est un commentaire qui va suivre, et c’est tout.

Je vois pourtant un intérêt à distinguer certaines formes de commentaires. Par exemple, avoir la possibilité de commenter sur trois niveaux :

1. Le niveau factuel : le commentaire dit en langage naturel ce qui va être opéré et le décrit. C’est la niveau le plus utilitaire et dont les bénéfices pour la lecture du code sont immédiats.
2. Le niveau contextuel : le commentaire décrit le contexte qui justifie les choix que l’auteur a fait, ou les chemins qu’il a emprunté. Il fait part des erreurs qu’il avait commises avant d’arriver à la solution définitive.
3. Le niveau humeur : c’est un niveau important du commentaire qui permet à l’auteur d’exprimer sa personnalité, de rendre compte de l’unicité et de la singularité de son travail. C’est une activité importante qui favorise la mise en mémoire du code et qui donne « de la couleur à l’architecture logicielle », et cela aussi bien pour un tiers que pour l’auteur lui-même.

Dans la programmation aussi on peut décider de travailler soit sur le long terme soit sur le très court terme.

Related posts:

1. Le code et l’écriture Après la publication de Littérature du code et la lecture...
2. Mise-à-jour des fils RSS Mes fils RSS passent désormais par FeedBurner, ce qui m’a...
3. Le code collaboratif en ligne Tristan Nitot se fait l’écho du lancement de Bespin par...

Internet Explorer et Opera (pas Firefox et Safari) mettent en cache les URLs requêtées. C’est pratique quand on revient sur les mêmes pages car c’est beaucoup plus rapide à l’affichage, étant donné que le navigateur avait l’URL et sa dernière réponse en cache.

Mais quand on fait de l’asynchrone en javascript, les Callbacks du navigateur ne vont pas rééllement voir ce qu’il y a de nouveau à l’URL, car il retourne inlassablement la réponse qui est en cache et qui correspond à l’URL mémorisée.
Pour ne pas avoir de surprise il faut que le javascript génère des URLs bidons à chaque nouvelle requête.

Est-ce bien, est-ce mal ?

Related posts:

1. URI design Je regarde une note de Yves-Marie Pondaven dans laquelle il...
2. getChristianFaureAge ( ) En javascript, la fonction : getTime( ) renvoie le temps...
3. Petit sondage sur Google Vous recevez un mail de Google vous indiquant que la...

En javascript, la fonction :

getTime( )

renvoie le temps écoulé en milisecondes depuis le 1 Janvier 1970.

A quelques jours près, cette fonction donne mon âge.

Related posts:

1. Ars Industrialis sur Twitter Vous pouvez à présent suivre l’actualité d’Ars Industrialis sur Twitter....
2. C’est clair, non ? Le site twitteradar vous tient informé de l’actualité du service...
3. Précieux temps Je viens d’écouter le dernier enregistrement de la séance publique...