kantien a écrit 1256 commentaires

Je ne comprends pas cette obsession autour de git revert et de l'idée d'annuler des patch.

Ce n'est pas une obsession, c'est juste la continuité de la discussion autour de problème que j'ai posé. Pour ce qui est de l'idéé d'annuler un patch, c'est une des fonctionnalités que tu attends d'un VCS :

est-ce qu'il me permet de défaire ce que j'ai fait?

La solution avec git, sans réécrire l'historique, c'est d'utiliser git revert. Personnellement, c'est la réponse à laquelle je m'attendais (même si la tienne fait la même chose, c'est moins idiomatique) et c'est ce qu'a proposé El Titi.

Néanmoins, le problème que j'ai posé était un piège tendu de ma part. ;-) En utilisant git revert (ou ta commande), vous prenez le risque de mettre 3-way merge dans la panade plus tard. Voilà comment Linus préconise d'annuler un merge foireux : un exemple typique du besoin de lire une bonne pratique pour effectuer une action de base sans avoir de problème.

Ce défaut est propre au VCS qui utilise 3-way merge comme algorithme de fusion, ce qui n'est pas le cas de pijul. D'ailleurs, pour quelqu'un qui aime la précision sémantique des mots utilisés, c'est bien là le problème de tous ces VCS : ils n'ont pas de définition claire de ce qu'est une fusion, un comble pour une opération si fondamentale dans un tel outil ! :-) À ce sujet, tu pourras lire mon commentaire qui traite de la question qu'est-ce qu'une fusion ?

Et au-delà de ce problème (qui reste central dans tous ces VCS), il y a celui de déterminer l'indépendance entre patchs. Dans mon problème, je précisais bien que les modifications des branches B et C étaient indépendantes de celles de la branche A. C'est à cette seule condition (l'indépendance) qu'il suffit de revert le merge entre A et B pour défaire ce qui a été fait. Si l'on souhaite définir formellement (et donc clairement) ce que signifie ce mot indépendance, cela consiste à dire que les patchs commutent. Voilà pourquoi pmeunier insiste tant sur cette notion de commutation de patchs. En conséquence, s'il n'y avait pas commutation il faudrait aussi défaire d'autres patchs que ceux de la branche A (ce que ne saura pas faire git revert ni ta commande : il faudrait résoudre le problème à la main). Par exemple si, après la fusion de la branche C, j'ajoute un patch p qui dépend du travail de la branche A alors il sera aussi défait automatiquement par pijull rollback AB mais pas par git revert (ni ta commande).

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

Quel va être l'apport de pijul rollback face à un git revert ?

Déjà, on n'aura pas besoin de revert le revert ou faire du rebase dans certaines situations afin de ne pas mettre le 3-way merge dans la panade (mais ça c'est une propriété générale de la fusion sous pijul).

En revanche je me pose la même question que toi : est-ce que pijul rollback se contente d'inverser les patchs passer en arguments ou est-ce qu'il inverse aussi ceux qui en dépendent ? Autrement dit, prend-t-il en compte la relation de dépendance entre patch ?

Si j'ai cet historique :

O -> p -> q -> r -> A

que r dépend de p mais que q commute avec eux, lorsque je fais pijull rollback p, est-ce que r est aussi inversé ? C'est là pour moi un avantage important de pijull face aux autres : ne pas avoir à résoudre manuellement un problème qui peut être fait automatiquement (et qui pourrait s'avérer difficile à résoudre à la main, n'ayant pas nécessairement bien en tête les relations de dépendances entre patchs). C'est-à-dire, pijull rollback p applique p' ou r'; p' (le ' dénote l'inverse) ?

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

Autre question ?

Pas spécialement, c'est la réponse à laquelle je m'attendais (utiliser git revert). Mais il semblerait que ce ne soit pas aussi simple que cela, ensuite, pour la gestion future de la branche : how to revert a faulty merge avec explication en détails, par Linus, des pièges à éviter.

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

Si il faut plus d'une commande, fouiller dans les bonnes pratiques, chercher sur le net pour résoudre une question aussi triviale, alors git (ou autre VCS) a un problème.

La conclusion de cette phrase est dommageable parce que du coup tu digresses (tu le dis d'ailleurs toi-même à la fin). Il aurait été préférable de dire à la place "alors cela vaut peut-être la peine de s'intéresser à un outil qui prétend offrir une approche plus simple et rigoureuse".

Elle est peut être malheureuse, du fait qu'elle a amené une digression de FantastIX, mais je la maintiens. :-P

Je précise que j'ai qualifié ce problème de trivial (il l'est, je donne même la solution juste après) et qu'il fait parti du cœur de métier d'un VCS. Un problème trivial touchant à l'usage même d'un outil devrait être résolu facilement par l'utilisateur, sinon c'est un défaut de conception du logiciel.

Pour l'exemple, il est analogue au cas d'étude du rebasing dans le livre de référence sur git. On a trois branches que l'on rebase :

On peut bien supposer qu'il y a indépendance entre les modifications des parties clients et serveurs. Maintenant supposons, qu'après tous ces rebases on se rende compte que les commits sur le code client ont introduit une faille de sécurité. La correction la plus rapide est de supprimer ces commits en attendant d'analyser le problème et de le résoudre : comment faire avec git vu que les derniers commits présents (ceux du serveur) en dépendent ? On souhaiterait un commande du style git undo client : peut-on l'implémenter simplement autour du cœur de git ? J'en doute, mais je ne demande qu'à être contredit. En tout cas, elle l'est autour de celui de pijul (c'est la solution que j'ai donné manuellement et ce que devrait faire pijull rollback ou pijull unrecord).

Pour bien montrer à quel point le problème est trivial, je vais l'illustrer en prenant des nombres entiers au lieu de fichiers pour les sommets du graphe :

   /-- *2 -> 2 -- *3 -> 6 -- *5 -> 30 ----\
  /                                        \
1 ---- *7-> 7 -- *11 -> 77 -- *13 -> 1001 --> 30030 --> 9699690 -- ?? = /30 -> BC = 323323
  \                                                  /
   \-- *17 -> 17 -> *19 -> 323 ---------------------/

Annuler la branche A c'est annuler la multiplication par 30 c'est à dire diviser par 30. Dans les cas des fichiers c'est pareil : il faut inverser le patch global de la branche A, c'est-à-dire prendre l'inverse du composé de a1; a2; a3 puis l'appliquer à l'état ABC.

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

Ensuite, j'affirme en effet ne pas avoir de problème avec Git et j'explique (en gros) pourquoi.

Je suis intrigué par cette remarque, alors je pose un cas pratique n'étant pas un fin connaisseur de git. Prenons un historique de cette forme :

   /-- a1 -> A1 -- a2 -> A2 -- a3 -> A3 -\
  /                                       \
O ---- b1 -> B1 -- b2 -> B2 -- b3 -> B3 --> AB --> ABC -- ?? -> BC
  \                                             /
   \-- c1 -> C1 -> c2 -> C2 -------------------/

Les lettres majuscules désignent des instantanés du dépôt et les lettres minuscules des patchs. On a trois branches A, B et C avec leurs patchs et commits successifs. On fusionne A et B, puis ensuite on fusionne C. La dernière fusion génère un conflit qui est résolu. On suppose que les changements de la branche A sont totalement indépendants de ceux des autres branches, le conflit venant seulement de la fusion des modifications de B et C. Question : comment, à partir de ABC, annuler les changements apportés par la branche A ? (hint : avec pijul, une seule commande devrait résoudre le problème).

Si il faut plus d'une commande, fouiller dans les bonnes pratiques, chercher sur le net pour résoudre une question aussi triviale, alors git (ou autre VCS) a un problème. Il s'agit ici uniquement d'appliquer sur l'état ABC le patch inverse du composé de a1; a2; a3.

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

Un petit complément auquel j'ai pensé après coup.

Je trouve qu'elle explique mieux l'astuce de l'utilisation des graphes et elle n'utilise même pas le terme de graggle, bravo :) (quand je parlais de simplification de la représentation du fichier, c'est exactement ça, mais plus clairement exprimé en partant de la richesse du graphe au lieu de la "simplification/relaxation" de la liste).

Pour le terme de graggle, il semble être propre à Joe Neeman : Pierre-Étienne Meunier ne le connaissait pas. En revanche, un point sur lequel je n'ai pas insisté est que ces graphes de lignes étaient inéluctables pour résoudre la question : qu'est-ce qu'une fusion ? C'est parce que les autres systèmes n'ont pas de définition claire de cette notion qu'ils leur arrivent de se prendre les pieds dans le tapis (comme dans l'exemple donné avec git, où le problème viens de l'agorithme three-way merge si j'ai bien compris).

Revenons un instant sur nos graphes :

On a par exemple une flèche entre les sommets O et A marquée par un patch p. Je dirais que A est un descendant de O par la relation p. Si on prend par exemple des entiers pour sommets, comme dans mon premier commentaire, on dira que 2 est un descendant de 1; ou bien que 6 est un descendant commun de 2 et 3.

Maintenant prenons le graphe qui illustre la propriété fondamentale de la fusion de deux états :

Dans le cas des entiers, je prenais pour fusion le ppcm. Ce qui importe dans le ppcm ce n'est pas qu'il soit le plus petit des multiples communs, mais que tout multiple de A et B soit aussi un multiple de leur ppcm M. Autrement dit : parmi tous les descendants de A et B, il y en a un qui est un ancêtre commun de tous les descendants. C'est cette propriété qui caractérise la fusion.

Dans le cas où l'on travaille sur des fichiers, lorsqu'il y a conflit, c'est cet état de conflit qui est l'ancêtre commun de tous les états futurs du dépôt. Or, pour le représenter, il faut utiliser un graphe de lignes. Et, ce qui est le plus important, lorsque l'on l'on travaille avec des graphes un tel descendant commun existe toujours et c'est lui que l'on appelle la fusion. Mais, ce qu'il y a de pire avec les autres systèmes, c'est que faute d'une telle définition formelle de la fusion ils ne choisissent pas toujours un tel descendant même s'il existe sans conflit (voir l'exemple de pmeunier).

Enfin, comme un état de conflit est un sommet comme les autres dans le graphe de l'historique, résoudre un conflit revient à lui appliquer un patch pour le ramener sur état similaire à une liste, i.e un fichier normal, et pijul garde en mémoire tant l'existence du conflit que sa résolution.

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

J'ai juste un doute sur les deux dernières lignes: commit et merge sont bien des fonctions prenant les 2 premiers éléments en paramètre et faisant un résultat du type du dernier élément ?

Plus ou moins. La réponse de barmic est plus proche de la vérité, et c'est effectivement une pratique courante en programmation fonctionnelle (connue sous le nom de curryfication). Si j'écris le type de commit avec des parenthèses, cela donne :

val commit : patch -> (state -> state)

C'est une fonction qui prend un patch et retourne une fonction des états dans les états. Pour prendre une notation utilisée en mathématiques, il faudrait prendre la notation indicée. commit décrit une famille de fonctions indexées par des patchs. Ce qui correspond bien à ce qu'exprime le diagramme :

Les flèches entre sommets sont des transformations indexées par des patchs. Lorsque j'ai écrit :

• A = commit p O

il faudrait lire (en rajoutant des parenthèses) :

• A = (commit p) O

soit la fonction commit p appliquée à O, ou avec des indices :

De la même manière, une suite de fonctions des réels dans les réels a pour type nat -> real -> real.

Il y a bien une correspondance entre cette approche à la Curry et celle où les fonctions prennent un couple. Elle traduit cette égalité algébrique :

L'exponentiel de l'exponentiel est égale à l'exponentiel du produit. C'est liée à l'algèbre des types : là où le produit cartésien correspond au produit, le type des fonctions correspond à l'exponentiel.

Si un type A a 2 éléments et un type B a 3 éléments, alors le type A -> B a 3^2 = 9 éléments (A -> B = B ^ A).

Pour en revenir à la fonction commit, elle associe chaque patch à une fonction des états sur eux-mêmes. Lorsque l'on dit que l'on applique un patch, c'est un abus de langage, en réalité on applique la fonction associée au patch via commit. Et lorsque l'on dit que les patchs sont associatifs, c'est parce que la composition de fonctions est associative. En notant . la composition de fonction on a les égalités :

  (commit r . commit q) . commit p
= commit r . (commit q . commit p)
= commit r . commit q . commit p

Ce qui revient à « appliquer » les patchs dans l'ordre p, q, r.

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

⚠ Je ne te demande pas de me le réexpliquer avec d'autres mots, et surtout pas des termes mathématiques! ⚠

En complément du commentaire d'Adrien Dorsaz, je vais quand même essayer. Mais ne t'inquiète pas, ce sera des mathématiques simples : de l'arithmétique élémentaire avec les nombres entiers, et un peu de graphes.

Une image que j'aime bien et qui représente des historiques possibles d'un dépôt est celle-ci :

On peut résumer le cœur d'un gestionnaire de version à cette interface rudimentaire :

type patch
type state
val commit : patch -> state -> state
val merge : state -> state -> state

Il y a deux concepts : les patchs et les états, puis deux fonctions pour appliquer un patch sur un état ou fusionner deux états. Ainsi, sur le graphe du dessus, on a par exemple :

• A = commit p O
• M = merge A B

Plutôt que de travailler avec des fichiers et des répertoires, commençons plus simple et travaillons avec des entiers naturels. Les états (ou sommets du graphes) sont des entiers et les patchs sont aussi des entiers où la fonction de commit est la multiplication. Le graphe relie alors deux entiers s'ils sont multiples et l'arrếte est étiquetée par le coefficient multiplicateur. La fonction de fusion (merge) calcule le plus petit commun multiple.

On peut par exemple partir de l'état initial 1 et prendre pour les trois patchs du graphes les nombres suivants : p = 2, q = 3 et r = 7. Je remets le graphe :

On aura ainsi le sommet A = 2, le sommet B = 3 et leur fusion M = 6. Ce qu'exprime le graphe, c'est que quelque soit le chemin que l'on prenne pour fusionner ces trois patchs, on tombera toujours sur Q = 42. Cela parce que la multiplication est associative et commutative.

La première propriété (associativité) n'est pas satisfaite par les autres CVS : fusionner A et N ou bien fusionner M et C ne donnera pas toujours le même résultat. C'est cela qu'illustre ces deux schémas dans la documentation de pijul :

Le pire étant que ces CVS peuvent fusionner le tout, sans signaler de conflit, et faire n'importe quoi. Tel était l'exemple donné par Pierre-Étienne Meunier.

Ensuite, à la place des nombres entiers, on peut prendre un Rubik's cube. Ici les états seraient ceux du cube, et le patchs les transformations qu'on peut lu faire subir. Avec un tel système, on aura toujours l'associativité des transformations. Que je fasse p ; (q ; r) ou (p; q) ; r cela ne change pas grand chose et l'on dit que l'on a effectué ces trois transformations à la suite p; q; r, sans mettre de parenthèses. Par contre, sur un rubik's cube, deux patchs ne peuvent pas toujours être appliqués dans n'importe quel ordre, lorsqu'ils bougent des zones communes. Dans ce cas, on dit qu'ils ne commutent pas. Il en est de même avec les CVS : des fois ça commute, des fois ça ne commute pas; mais pijul est capable de déterminer si deux patchs commutent ce qui lui permet (non de réécrire l'historique) mais de réécrire le graphe de dépendance entre les patchs pour faciliter la gestion du dépôt : on peut supprimer facilement l'effet d'un patch sans toucher aux modifications qui lui sont postérieures et indépendantes.

Il reste un point à éclaircir : la représentation interne des conflits. Revenons au cas des nombres entiers ou la fonction de merge était le calcul de plus petit commun multiple. Et regardons, ce graphe :

Ici, nos sommets sont toujours des entiers, M est le ppcm de A et B et F est un multiple quelconque de A et B, mais aussi un multiple de M. Ce que fait pijul c'est généraliser cette notion de ppcm aux fichiers. Pour cela, on considère un fichier comme une liste de lignes. Malheureusement, il n'y a pas toujours de ppcm pour deux fichiers : c'est le signe d'un conflit lors d'une fusion.

La solution est de prendre un type plus riche que les liste pour les sommets du graphe : à savoir des graphes de lignes (dont les listes sont un cas particuliers). À ce moment là, deux graphes de lignes ont toujours un « ppcm » que l'on appelle leur fusion. Si ce graphe est similaire à une liste alors il n'y a pas de conflit sinon c'est qu'il y a conflit :

If the two following conditions are both met:

• the graph is acyclic, and contains a path passing through all the vertices.
• for each vertex v, all incoming edges of v have the same label ("alive" vs. "deleted").

Then the task of presenting the file to the user is relatively straightforward: just go along the path and output all alive vertices. Else, we say the file has a conflict, and presenting the state of the file to the user in an intelligible way is not obvious.

pijul documentation

Comme pijul travail avec des états qui sont ces graphes de lignes, il a une représentation interne des conflits (des graphes qui ne sont pas des listes) et peut travailler sur eux comme il le ferait avec des fichiers normaux : on peut leur appliquer des patchs, les fusionner… et les aplatir vers des fichiers (résoudre les conflits) quand on veut.

D'une manière générale, j'aime bien ce principe : Theorise first then implement is the stairway to heaven. Implement first then theorise is the highway to hell. D'autant que Jimmy page était, sans nul doute ni contestation, bien plus fin et subtil qu'Angus Young. :-P

Comme pijul a choisi la première voie, c'est plus simple et plus naturel; les autres systèmes reposant sur une mauvaise analyse de l'algèbre des patchs et des états.

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

Je ne suis pas sûr de savoir ce que sont les graggle, j'imagine que c'est le graphe des lignes.

Oui c'est cela, c'est le nom que leur a donné Joe Neeman. J'avais lu ces articles de blog pour comprendre la théorie derrière pijul, sans avoir à me farcir les articles académiques.

Justement pas trop, parce que le renommage ne produit pas juste une liste.

Là je ne comprends pas trop. Il y a d'autres forme de graphes que les listes pour représenter un état sans conflit ?

Pour ce qui est du dictionnaire de renommage, pourquoi ne pas le mettre comme tag sur le patch ? En admettant qu'il soit facilement décidable à quel sous-type de patch on a affaire : pijul remarque que A propose un patch de renommage, de même que B, et il marque chacun des patch avec leur dictionnaire. Puis lors de la résolution de conflit, pijul spécifie la cause du conflit (conflit de renommage) et propose une solution spécifique : choisir les noms de A ou ceux de B.

Si j'ai bien compris l'idée des patchs sémantiques, le principe est d'avoir un type générique patch avec plusieurs sous-type (déplacement, renommage, indentation…). Le problème étant, en autre, de savoir s'il est facilement décidable de savoir à quel sous-type appartient un patch donné. Mais, si c'est le cas, l'information devrait être attachée au patch et non au graphe de ligne.

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

encore une fois, que doit-on faire si Alice et Bob décident en parallèle de renommer la même variable avec deux noms différents ?

Il y a conflit ? Le merge est un graphe qui n'est pas une liste et il y a conflit à résoudre.

Si j'ai bien compris les principes derrière pijul, il y a au fond deux opérations primitives commit : patch -> graggle -> graggle et merge : graggle -> graggle -> graggle. Elles ont de bonnes propriétés algébriques, de telles sorte que le graphe ci-dessous commute :

Mais comme tu le dis dans un autre commentaire, pijul n'a pas besoin de patchs sémantiques pour fonctionner correctement. À la rigueur, cela pourrait être utile pour l'UI et fournir des informations plus détaillées à l'utilisateur lorsqu'il doit résoudre un conflit.

Dans le fond, ces patchs sémantiques sont juste une subdvision du type des patch (des sous-types) mais l'essentiel pour pijul c'est que ce soit des patchs. N'est-ce pas cela ? Dans ce cas, la seule chose que cela peut apporter serait d'ajouter des tags sur les patchs (comme les différentes variantes d'un type somme sont tagguées par un compilateur) et s'en servir pour adapter les messages au niveau de l'interface utilisateur, mais sans rien modifier sous le capot au niveau de la gestion des fusions et conflits.

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

Dans une économie de marché purement libérale (pas de socialisation de pertes, risque réel pour les prêts), un tel gonflement ne serait pas arrivé et on pourrait comparer une telle approche purement libérale par rapport à l'approche qui décapitalise le logement.

C'est là que j'ai du mal à te suivre. Tu admets qu'un des problèmes c'est l'intervention étatique sur le marché (qui déresponsabilise certains acteurs), et comme solution tu prônes encore plus d'État. Que les marchés puissent être défaillants, c'est certain, mais il y a une chose encore plus défaillante que les marchés : l'administration. L'école de Chicago :-)

En passant, tu demandes des sources à Nicolas Boulay dans un autre commentaire, tu les as dans le lien que te proposais barmic :

Pour remédier à cet état de fait, les auteurs de l'étude recommandent de "réfléchir à des politiques structurelles visant à augmenter l'élasticité de l'offre de logements" par la "simplification et l'accélération des procédures d'autorisation de construction dans un cadre juridique maîtrisé".

[…]

Pour le CAS, "les effets de l'inélasticité de l'offre peuvent être atténués par des politiques visant à favoriser une meilleure allocation du parc de logements". "Celle-ci passe notamment par une réduction des freins à la mobilité résidentielle: distorsions fiscales liées au traitement différentiel des propriétaires et des locataires, et coûts de transaction (droits de mutation)", propose le CAS.

Le problème reste bien celui d'une pénurie d'offre dans certains secteurs.

Sur tes tautologies, j'ai du mal avec la dernière :

« Capitaliser sur le logement, c'est capitaliser sur un bien et droit fondamental. »

J'ai toujours eu du mal avec cette notion de bien et droit fondamental. Quel sens lui donner ? Et quels sont les critères pour qualifier ainsi un bien et un droit ?

Je ne peux me représenter avoir un droit sans qu'autrui est un devoir en contrepartie (et réciproquement, en vertu du principe d'égalité juridique, autrui a ce droit et moi ce devoir), mais quel devoir mettre en face du droit fondamental au logement ?

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

Je ne veux pas revenir sur l'ensemble de ton commentaire, mais il y a tout de même un passage qui m'a vraiment fait tiquer plus que les autres :

Pourquoi ne ressentons nous pas de mouvement (Et là c'est le pire: Galilée affirme que la mouvement de la terre est en fait la cause les marrées, alors que ça n'a rien à voir)

Là pour moi ce qui est pire est que tu omets totalement le cœur de la question et la solution fondamentale de Galilée. Sa réponse, c'est le principe d'invariance galiléen, autrement appelé principe de relativité restreinte par les physiciens. Ramener cela à la question des marées, c'est au pire de la mauvaise foi, au mieux de l'ignorance.

Il justifia ce principe dans son Dialogue sur les deux grands systèmes du monde à travers des expériences de pensée impliquant un homme enfermé dans sa cabine sur un bateau et qui, à partir des expériences qu'il y mène, ne peut constater le mouvement de son navire. C'est à partir de cela que Newton tira son Principe Fondamental de la Dynamique, et qu'Einstein développa encore plus dans ses deux théories de la relativité (qui est donc son homme enfermé dans sa cabine, pour qui inertie et gravité sont identiques dans leur principe, si ce n'est un lointain cousin du personnage de Galilée ?).

Ceci étant, dans son ouvrage, il y a effectivement un idiot du nom de Simplicio : celui qui s'attache avec acharnement aux principes de la physique d'Aristote et de sa théorie du mouvement.

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

Les angles y sont corrects. ;)

Que vient faire le fair-play britannique dans cette histoire ? :-P

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

De mon point de vue, se baser sur un document comportant de telles erreurs [mathématiques] n'est pas pertinent, car il ne saurait être considéré comme une source fiable ou crédible.

Ah, mais je partage ton avis sur le document en question, et ce n'est pas que sur le plan mathématique qu'il est douteux, il l'est aussi : philosophiquement (philosophie du droit) et économiquement (du au premier point, mais aussi sur la partie historique en fin d'ouvrage). Seulement, en dehors de lui, je ne connais personne qui emploie le terme monnaie libre, il me semblait donc que c'était à cela que faisait référence El Titi et je répondais alors à la question de Marco.

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

si on peut me définir une monnaie libre ça serait sympa aussi

Les principes de la monnaie libre sont présentés dans la théorie relative de la monnaie et pour la définition de monnaie libre c'est, plus particulièrement, ici.

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

CNR ? Comité National Révolutionnaire ?

Encore pour PPA, je peux comprendre, c'est un acronyme qui ne doit être compris et connu que dans certains milieux idéologiques. En revanche, pour celui-ci, cela relève de l'histoire de France : Conseil National de la Résistance. Bien qu'il fût initié par De Gaulle sous la direction de Jean Moulin, afin d'unifier les différents mouvements de résistance durant la seconde guerre, son programme politique de 1944 était très empreint de communisme (comme on peut le constater à la lecture des premiers articles sur la presse).

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

Art. 1. La presse n’est pas un instrument de profit commercial, mais un instrument de culture ; sa mission est de donner des informations exactes, de défendre des idées, de servir la cause du progrès humain.

Intéressant article auquel je propose celui-ci en miroir :

Art. 1. La boulangerie, l'élevage et l'agriculture ne sont pas des instruments de profit commercial, mais des instruments d'alimentation ; leur mission est de donner de la nourriture de qualité, en quantité suffisante, de servir à la survie de l'espèce humaine.

Ce dernier étant, à mon sens, bien plus important que celui du CNR : à quoi sert de pouvoir s'informer si l'on n'est même pas assurer de survivre ?

Il faudra un jour que l'on m'explique ce qu'il y a de malsain, par principe, dans une relation commerciale.

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

Au-delà de comment quelques individuEs

et c'est tellement peu intuitif que tu l'utilises sur un nom masculin.

Il eut été plus simple d'écrire « Au-delà de comment quelques personnes… »

Ceci étant, avec cette nouvelle écriture, il faudrait écrire comment ?

• unE personnE
• quelques personnEs

ou bien garder la graphie actuelle ? Dans ce cas pourquoi ne toucher que les substantifs génériques du genre masculin ?

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

Ça n'est pas parce qu'Indiana Jones ressemble comme deux gouttes d'eau à Harrison Ford

D'autant que, il est nécessaire de le rappeler, Indiana c'était le nom du chien ! Mais ils ont peut être pris aussi des images de chiens pour alimenter leur algorithme… :-D

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

le lien pointe bien vers une page vide.

Ça doit venir de chez toi. Le lien de l'annonce pointe bien vers une annonce pour un poste de « gestionnaire projet informatique » à Malancourt-la-Montagne en Moselle.

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

Il est dans une superposition d'état quantique : le plus sûr, s'il s'approche de la frontière, c'est de tirer une balle et de voir comment se réduit sa fonction d'onde. :-P

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

Sommaire

• Le cas Ken Thompson
  • Étape 1
  • Étape 2
  • Étape 3
• La recension de SamWang

Et descend de ton piédestal tu vas prendre froid.

Je viens de voir que vous avez effacer son compte et supprimer certains de ses messages. Comme j'étais en train de rédiger un long commentaire pour exposer sa profonde ignorance au grand jour et que je ne veux pas avoir perdu du temps pour rien, je le mets quand même ici. Il pourra servir comme référence, au cas où il revienne avec un autre compte.

Voici une analyse de sa confiture que nous ne savons pas apprécier au sujet de l'article de Ken Thompson.

Le cas Ken Thompson

Alors que Ken Thompson reçoit le prix Turing en 1983 pour son œuvre, lors de son discours de remerciement, il présente le programme le plus malin (cutest)¹ qu'il ait jamais écrit. Son discours est retranscrit sous forme d'article et publié dans un bulletin de l'ACM sous le titre Reflections on trusting trust.

Le programme en question est fortement lié au présent journal, puisqu'il consiste à corrompre un compilateur C dans la chaîne de bootstraping, de tel sorte que tout compilateur C qui lui succède introduise une porte dérobée dans le programme de login d'un système Unix.

Son exposé se décompose en trois étapes que nous présenterons brièvement dans ce qui suit.

Étape 1

La première étape consiste à écrire un programme qui, lorsqu'il s'exécute, reproduit son propre code source sur la sortie standard. Un tel programme est dit autoreproducteur. En voici un exemple minimal en OCaml :

(fun x -> Printf.printf "%s %S" x x) "(fun x -> Printf.printf \"%s %S\" x x)";;
(* ci-dessous le retour de l'exécution, identique au code source *)
(fun x -> Printf.printf "%s %S" x x) "(fun x -> Printf.printf \"%s %S\" x x)"

Étape 2

La seconde étape traite un problème posé dans un autre commentaire du journal par redo_fr : comment ajouter de nouvelles fonctionnalités à un langage en compilant le nouveau compilateur avec une version antérieure, qui ignore, donc, les nouvelles fonctionnalités ?

Il y traite un exemple simple avec l'interprétation des séquences d'échappement dans les chaînes de caractères. Il montre comment boostraper l'interprétation de la séquence \v comme une tabulation verticale. Ainsi, même si, à la génération N, la séquence \v n'est pas valide, à partir des générations N + 1 et suivantes, tous les compilateurs pourront l'utiliser dans leur propre code source.

Étape 3

C'est l'étape finale où il décrit comment introduire la porte dérobée sans laisser aucune trace dans le code source du compilateur.

Dans une représentation idéalisée du fonctionnement d'un compilateur, celui-ci lit le code source du programme puis applique une routine compile(s) sur les parties du code. Pour introduire une porte dérobée, on peut tester la correspondance de la fonction à compiler sur un motif donné et introduire dans ce cas compile(backdoor).

Le défaut de cette approche est que même une lecture superficielle du code source du compilateur risque de découvrir le pot aux roses, en voyant l'exécution conditionnelle de l'instruction compile(backdoor).

La solution consiste, alors, à combiner les techniques des deux premières étapes afin d'effacer la supercherie du code source du compilateur. À la génération N, on introduit la porte dérobée sous forme d'un programme autoreproducteur (étape 1), que l'on boostrape (étape 2), puis l'on distribue ce binaire comme compilateur C officiel qui reproduira son comportement dans toutes les générations successives.

Le lecteur intéressé par les détails de chaque étape pourra toujours se reporter à l'article de Ken Thompson.

Maintenant, chers lecteurs, attardons nous quelque peu sur l'analyse détaillée de cette succulente confiture gracieusement offerte par SamWang, que, nous autres, pauvres cochons, n'avons pas su éstimer à sa juste valeur. Ça vaut le détour ! :-)

La recension de SamWang

Lui, ô grand chasseurs devant l'éternel de coquilles, coquillages et autres crustacés, se propose de nous révéler quelques une de ses prises, suite à sa lecture du papier l'été dernier. Et quelles prises ! :-D

Avant cela, il tente un résumé de l'article qu'il semble n'avoir pas totalement saisi. Pour lui, l'article expose l'injection d'une porte dérobée dans la compilation du fichier login.c. Puis Ken Thompson mettrait ensuite « en garde contre le risque d'injection de code malveillant par un compilateur malveillant dans tout programme qu'il compile, y compris un compilateur ». J'espère que tout lecteur attentif de ma présentation aura compris que c'est un peu plus subtil que ça.

Passons, à présent, aux coquilles mineures relevées. Il en trouve deux :

• inversion de légendes entre deux figures du papier ;
• placement de figures dans la mauvaise section.

S'il y a bien inversion de légende entre deux figures (celles qui illustrent comment ajouter la séquence d'échappement \v au langage) et que tout lecteur attentif corrigera de lui-même, je suis au regret de lui apprendre que la seconde n'en est pas une.

SamWang ne devant pas être habitué à la lecture d'article académique, il a pris pour une coquille ce qui n'est rien d'autre qu'une mise en page, on ne peut plus classique, dans ce genre de papier. Les figures liées à la section 2 sont reportées en bas de page, qui, dans le cas présent où chaque page est en format deux colonnes, se trouve en bas de la seconde colonne. Cela lui donne l'illusion qu'elles sont insérées dans la section 3 dont le texte commence sur cette deuxième colonne.

C'est déjà quelque peu amusant, mais le plus beau reste à venir. Dans le fond, SamWang a une âme d'explorateur : il rêve d'une terre remplie de K-zino, avec son comparse zind dans sa logique LFC, inspirée des travaux de Rudolph Carnap, pour faire de la LNC. Malheureusement pour lui, depuis dix ans qu'il en parle, il ne navigue toujours par sur l'océan à la recherche de la terre promise. Nulle Santa Maria, ni même le moindre radeau, et tous ses bateaux semblent prendre l'eau. Alors, seul sur le rivage, admirant au loin l'horizon, il doit s'ennuyer un peu : il part donc à la pêche aux coquillages.

Et là, mazette, quelle récolte ! Ken Thompson ne sait même pas écrire correctement du C. Oui, vous avez bien lu : Ken Thompson est une bille en C, il ne sait pas écrire un programme de quelques lignes syntaxiquement valide, et en plus il propose ça en publication à l'ACM qui valide le tout. Mais dans quel monde vit-on ?

Voyons voir cette grossière erreur un peu plus à la loupe. Elle se trouve dans l'étape 1, lorsqu'il traite des programmes autoreproducteurs. Son code commence par la déclaration d'une chaîne de caractères :

char s[] = {'t', '0', '\n', '}', ';' ... }

Puis, dans la boucle principale, il parcourt cette chaîne pour l'imprimer caractère par caractère. Ni une, ni deux, SamWang arrive à la conclusion fatidique : si je commence par écrire cette séquence de caractère au tout début d'un fichier, je n'aurais pas un code source C valide. En conséquence, alors que le programme d'exemple devait afficher son propre code source, il affiche un texte qui n'est même pas valide en C. Quel escroc ce Ken Thompson ! encore un qui essaye de jouer au paralogisme, mais on n'échappe pas à la surveillance assidue du SamWang.

Rassurez vous, rien de tout cela dans le code de Ken Thompson, c'est juste que l'idiot de service à oublier de lire l'instruction qui précède la boucle for :

printf("char\ts[] = {\n");

C'est vrai que, finalement, il a un certain sens de l'humour notre SamWang : certes à ses dépends, mais c'est drôle quand même. :-)

Après, pour être tout a fait exact, son exemple n'est pas un programme autoreproducteur mais génère un tel programme. Il le précise lui même :

The purist will note that the programm is not precisly a self-reproducing programm, but will produce a self-reproducing programm

Ken Thompson

Ce qui est encore plus drôle (deuxième effet kiss cool) est que, à la toute fin de son commentaire, SamWang pointe un lien vers un vrai programme autoreproducteur « dans lequel le tableau de données est lu deux fois et interprété différemment les deux fois.[…] une solution bien astucieuse » (les mots sont de SamWang). Tout lecteur de bonne foi, comprenant le C, réalisera sans peine que cette solution astucieuse est identique, dans l'esprit, à celle de Ken Thompson.

Comme autre perle de sa pêche aux coquillages (heureusement que je sais ouvrir les huîtres), on trouvera celle-ci. S'interrogeant sur l'utilité de cette étape dans le corps de l'article, notre cher ami écrit, je cite :

Je suppose que s'il passe par cette étape, c'est pour justifier la possibilité, pour un compilateur malveillant, d'injecter sa malveillance en tant que code source ajouté au code source légitime qu'il compile. Bien que son propos manque d'articulation logique, je pense qu'on peut légitimement inférer ce que je viens de supposer.

SamWang au sommet de sa forme.

Je laisse le lecteur libre de juger à quel point l'étape 1 est cruciale pour l'étape 3 (d'après ma présentation), et si, dans son article, Ken Thompson ne le signale pas explicitement selon une articulation logique sans faille. Ce qui manque, assurément, d'articulation logique, ce sont les commentaires à ralonge de SamWang.

Arriver à ce stade, toute personne sensée, avec un minimum d'humilité, aurait du se dire : « j'ai du raté un truc » (en l'occurrence oui, à savoir, une ligne de code). Mais comme rien n'arrête notre SamWang, il va bien plus loin : par une réduction à l'infinie, il entend, dans un premier temps, nous convaincre que le problème que cherche à résoudre Ken Thompson n'a même pas de solution. Non seulement il ne peut toujours pas naviguer sur l'océan à la recherche de découverte pleine d'espérance, devant se contenter du rivage et de ses coquillages, mais le voilà maintenant chutant inexorablement dans le tonneau des danaïdes, ce puit sans fin dont il desespère de ne pas voir le fond.

Ce genre de problème de point fixe est on ne peut plus courant, mais il semble l'ignorer : étant donné une fonction f trouver une valeur x tel que f (x) = x ; où ici la fonction f, dont on cherche un point fixe, est la composée de deux autres f = run . compile, de telle sorte que l'on cherche source satisfaisant l'équation :

(run . compile) (source) = source

Il se met alors à chercher des contournements au défi, en assouplissant les contraintes, afin d'y arriver. Il envisage, par exemple, un programme qui ouvre son fichier source puis l'affiche, ce qui nécessite d'avoir toujours à disposition le code source d'un tel programme. Là où l'on voit qu'il n'a rien compris à l'article, étant donné que le compilateur compromis ne sera distribué que sous forme binaire tout en ayant la capacité de « parasiter » tous les futurs compilateurs qui
l'auront comme ancêtre.

Incompréhension totale de l'article confirmée par ce qui conclut cette partie du commentaire (qui constitue la moitié, en volume, du commentaire complet) :

Tout ceci étant exprimé, est-il impératif d'avoir une solution viable au défi pour que l'exposé de Ken Thomson tienne la route par ailleurs ? Ma réponse est non.

SamWang dans sa chute ne voyant toujours pas le fond

Assurément que si, c'est impératif ! comme je viens de le rappeler.

Enfin, nous touchons au sublime avec la conclusion du commentaire, où, sautant du coq à l'âne, dans une articulation logique à toute épreuve, l'on apprend dans la foulée de cette question-réponse que, si, finalement, on peut écrire des programmes autoreproducteurs et que l'on appelle cela des quine (en l'honneur du philosophe analytique William Quine, je précise). SamWang a donc passé la moitié de son commentaire à nous expliquer que c'est pas possible, pour, finalement, nous dire que c'est possible. Effectivement, ça valait le coup ! :-D

Non vraiment, je ne vois pas ce qui a bien pu m'amener à écrire :

Pour le reste tu passes ton temps à essayer d'employer des notions et des concepts auxquels tu n'entends absolument rien, et cela face à des personnes qui, elles, les comprennent.

et le voir me répondre :

Bing ! La formule magique, l'échappatoire à deux sous !

Ce qui précède doit bien apporter la preuve irréfragable de ce que j'avançais. Pour ce qui est de l'autre fil de discussion, ce n'est guère mieux, mais j'ai déjà assez perdu de temps comme cela pour devoir le justifier.

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

j'ai sollicité la bienveillance d'un expert en science de la sagesse.

Tout d'abord mon domaine d'expertise est avant tout les mathématiques pure et la logique formelle, mais j'ai néanmoins une connaissance approfondie de la philosophie kantienne et une certaine érudition au sujet de la pensée philosophique.

Maintenant, je te le dis : tu es un parfait crétin doublé d'un malotru. Non, pour reprendre ton expression sur l'autre fil de discussion, qu'il n'est plus nécessaire de polluer, nous ne sommes pas en bonne compagnie ! On ne colle pas de quenelles pour sodomiser Kant à titre posthume ! Quand bien même on appelle cela de l'humour : ton sens de l'humour m'est parfaitement incompréhensible.

Ton problème principal de longueur dans tes textes n'est pas une pathologie (comme la logorrhée) mais tout simplement de la micrologie : c'est-à-dire de l'inutile précision dans les détails.

Pour le reste tu passes ton temps à essayer d'employer des notions et des concepts auxquels tu n'entends absolument rien, et cela face à des personnes qui, elles, les comprennent.

Au sujet de ton projet de LFC, tu devrais t'associer à Mr BG est son projet de C-Cool. Quand vous en serez à la phase de bootstrap, vous nous ferez un journal…

Vu que tu aimes Carnap, tu devrais lire ça : Carnap, Cassirer, and Heidegger: The Davos Disputation and Twentieth Century Philosophy, c'est incroyable à quel point Kant est omniprésent dans un article où son nom n'est même pas mentionné dans le titre.

Et globalement sur tes délires de projets :

Faire des plans, c'est bien souvent se laisser aller à une activité intellectuelle ostentatoire et fanfaronne : on se donne une apparence de génie créateur en demandant ce qu'on n'est pas capable d'exécuter soi-même, en dénigrant ce que l'on est cependant incapable de surpasser et en prônant ce dont on ne saurait dire où le trouver.

Kant, prolégomènes à toute métaphysique future.

À l'avenir, ne prends pas la peine de répondre à mes commentaires en espérant que j'y réponde, tu y trouveras systématiquement la porte fermée. Considère notre canal de communication comme définitivement clos : je ne donne pas à manger aux cochons sans aucune éducation.

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

T'as de la chance que je sois de bonne constitution et que je ne te traite pas d'idiot. Tu te rends compte que tu viens de traiter Kant d'être un auteur de paralogisme ? Ça te viendrait à l'idée en lisant un texte d'Einstein, où tu ne comprends pas bien un passage, d'en conclure qu'il a commis une grossière faute dans l'application des principes de la physique ? Non, parce que là c'est ce que tu viens de faire, sauf que la science en question, c'est la logique. ;-)

Avant de clarifier ton incompréhension (oui, la définition est bien tautologique), il me semble nécessaire de préciser un léger point. Kant était un philosophe allemand vivant en prusse orientale, dans la ville de Königsberg aujourd'hui en Pologne, il écrivait donc en allemand. Les lourdeurs de styles et les problèmes de syntaxes sont la faute du traducteur ! Bon, allez, je te donne la version que j'ai dans ma bibliothèque :

La liberté de droit (par suite extérieure) ne peut pas être définie, comme on a coutume de le faire, par l'autorisation de faire tout ce qu'on veut pourvu qu'on ne fasse pas de tort à autrui. Car que signifie autorisation ? La possibilité d'agir dans la mesure où l'on ne fait de tort à personne. Ainsi l'explication serait celle-ci : la liberté est la possibilité de l'action qui ne fait pas de tort à autrui. On ne fait de tort à personne (quoi qu'on fasse d'ailleurs) à condition de ne faire de tort à personne. Par suite, c'est une tautologie vide. — Il faut au contraire définir ma liberté extérieure (de droit) ainsi : elle est l'autorisation de n'obéir à aucune autre loi extérieure que celles auxquelles j'ai pu donner mon assentiment. — De même l'égalité extérieure (de droit) dans un État est le rapport des citoyens selon lequel personne ne peut obliger l'autre, de droit, sans que, en même temps, il ne se soumette à la loi qui peut l'obliger réciproquement et de la meilleure manière. (Le principe de la dépendance de droit qui se trouve déjà dans le concept d'une constitution d'État en général n'a pas besoin d'explications.)

Traduction par Jean-François Poirier et Françoise Proust.

La syntaxe de l'ensemble te sied-elle mieux ?

Maintenant, venons-en à l'analyse de la tautologie. Tu dois avoir un problème dans ton interpréteur du français. Commençons par un exemple simple, issu de l'interprétation de code dans un langage de programmation :

let double = (fun x -> x + x)

(* Comment procéder à l'interprétation du terme suivant : *)
double 2

(* on commence par substituer à `double` sa définition : *)
(fun x -> x + x) 2

(* puis on remplace le paramètre formel par la valeur de l'argument *)
2 + 2

(* et on calcul *)
4

Jusqu'ici tu suis ? Et bien, dans le texte de Kant, c'est la même chose : on substitue un terme par sa définition, comme dans le cas de double ci-dessus.

On commence par la définition courante de la liberté :

• l'autorisation de faire tout ce qu'on veut pourvu qu'on ne fasse pas de tort à autrui

Puis comme pour double, on se demande : mais au fait c'est quoi la définition de autorisation ? Et l'on a :

• la possibilité d'agir dans la mesure où l'on ne fait de tort à personne

Ensuite, on substitue. Là je le fait textuellement (ne viens pas te plaindre de la syntaxe qui n'est pas correcte en français) :

• [la possibilité d'agir dans la mesure où l'on ne fait de tort à personne] de faire tout ce qu'on veut pourvu qu'on ne fasse pas de tort à autrui

ce qui, une fois qu'on redonne une forme syntaxiquement correcte en français, mais sans changer le sens (la sémantique), devient :

• la liberté est la possibilité de l'action qui ne fait pas de tort à autrui. On ne fait de tort à personne (quoi qu'on fasse d'ailleurs) à condition de ne faire de tort à personne

C'est la mise en forme avec une syntaxe correcte et préservation de la sémantique qui te pose problème ? Dans la première phrase on retrouve la définition de autorisation, mais le défini (et donc sa définition) était soumis à la condition de ne faire de tort à personne (pourvu qu'on ne fasse pas de tort à autrui) et cela quoi que l'on fasse (faire tout ce qu'on veut) : d'où la deuxième phrase. Est-ce plus clair maintenant ?

---

Après ce préambule, quelque peu fastidieux pour une telle trivialité, jetons un œil à tes autres questions.

Non, si le savoir humain n'était assuré que par de tels principes, il n'en vaudrait pas rien pour autant. Imagine 1000 ans d'observations de tel phénomène menant à l'élaboration de telle loi jamais contredite par une quelconque observation, même sans le fondement de principes issus de sciences pures, ça conserve un intérêt (certes limité) pour se projeter dans l'avenir.

Bah ce que tu décris est notre situation bien réelle. Ce que je dis c'est que ces observations, qui forment un savoir objectif, n'est possible que par l'intervention de principes qui, eux, ne sont pas d'origine expérimentale. ;-) Sans ces principes purs nous n'aurions que des jugements de perceptions (à valeur subjective) et non des jugements d'expériences (à valeur objective). Mais, assurément, les jugement d'expériences ont également besoin d'une autre source que la seule pensée pure : à savoir les jugements de perceptions.

Des jugements empiriques, s’ils ont une valeur objective, sont des jugements d’expérience ; mais ceux qui n’ont qu’une valeur subjective sont de simples jugements de perception. Ceux-ci n’ont besoin d’aucune notion intellectuelle pure, mais seulement de la liaison logique de la perception en un sujet pensant. Ceux-là, au contraire, demandent toujours, indépendamment des représentations de l’intuition sensible, des notions particulières produites originairement dans l’entendement, qui donnent au jugement d’expérience sa valeur objective. […]

C’est ce que nous allons expliquer. Qu’une chambre soit chaude, que le sucre soit doux, l’absinthe amère, ce sont là des jugements d’une valeur purement subjective. Je ne demande pas de sentir toujours ainsi, ou que chacun sente comme je dois sentir. Ces jugements n’expriment qu’un rapport de deux sensations à un même sujet, moi-même, et moi seulement dans mon état actuel de perception, et ne valent par conséquent pas relativement à l’objet ; je les appelle donc des jugements perceptifs. Il en est tout autrement du jugement expérimental. Ce que l’expérience m’apprend dans certaines circonstances, elle doit me l’apprendre toujours et à chacun, et sa valeur ne se borne pas au sujet ou à son état du moment. J’énonce donc tous ces jugements comme objectivement valables, lors, par exemple, que je dis : L’air est élastique, ce jugement n’est immédiatement qu’un jugement de perception ; je rapporte deux sensations l’une à l’autre dans mes sens. Pour que je puisse l’appeler un jugement d’expérience, il faut que cette liaison soit soumise à une condition qui la rende universellement valable. Il faut donc que je sois toujours et que chacun soit comme moi dans la nécessité de faire cette liaison dans les mêmes circonstances. […]

Pour qu’il y ait expérience par perception il faut encore un jugement tout différent de celui-là. L’intuition donnée doit être subsumée à une notion qui détermine la forme du jugement en général par rapport à l’intuition, qui relie la conscience empirique de l’intuition en une seule conscience en général, et donne ainsi aux jugements empiriques une valeur universelle : cette notion est une notion intellectuelle pure a priori, propre seulement à déterminer la manière dont une intuition peut servir aux jugements. Soit donc la notion de cause ; elle détermine l’intuition qui lui est subsumée, par exemple celle d’air, par rapport à ce jugement en général, que la notion d’air, en ce qui regarde la dilatation, dans le rapport d’antécédent à conséquent, a son usage dans le jugement hypothétique. La notion de cause est donc une notion intellectuelle, entièrement différente de toute perception possible, et qui ne sert qu’à déterminer la représentation à elle soumise, par rapport au jugement en général, par conséquent à rendre possible un jugement d’une valeur universelle.

Il faut donc pour qu’il puisse y avoir jugement de l’expérience par un jugement de perception, que la perception soit subsumée à une notion intellectuelle, par exemple, l’air est soumis à la notion de cause, notion qui détermine comme hypothétique le jugement sur l’air par rapport à l’expansion. Et alors cette expansion n’est pas représentée comme appartenant simplement à ma perception de l’air dans mon état, ou dans plusieurs de mes états, ou dans l’état de la perception des autres, mais comme y appartenant nécessairement ; et ce jugement : L’air est élastique, devient d’une valeur universelle, et un jugement expérimental par le fait que certains jugements précèdent, qui subsument l’intuition de l’air à la notion de cause et d’effet, et déterminent ainsi les perceptions, non pas purement entre elles dans mon sujet, mais par rapport à la forme du jugement en général (ici la forme hypothétique), et donnent ainsi au jugement empirique une valeur universelle.

Kant, Prolégomènes à toute météphysique future qui voudra se présenter comme science.

Si tu trouves des choses à redire dans la syntaxe, cette fois incrimine le traducteur et non Kant. ;-) Ici, il fait jouer la catégorie de la causalité (pur concept d'entendement) pour transformer un jugement de perception (à valeur subjective) en jugement d'expériences (à valeur objective). C'est celle dont je parlais dans mon premier message en rapport avec la logique de Hoare. Et ce processus mental nous le faisons tous, naturellement, même si on n'en a pas conscience : M. Jourdain faisait bien de la prose sans le savoir. ;-)

En quoi la mathématique pure et la logique formelle ne sont-elles pas suffisantes comme fondement a priori ?

Bien trop long à expliquer, et, à dire vrai, il vaut mieux être spécialiste dans ces deux disciplines (ce qui est mon cas) pour le comprendre. Mais déjà, pour envisager la possibilité d'une telle insuffisance, pose toi cette question : les notions de liberté et de droit dont on parlait précédemment, sont elles d'origine empirique ou rationnelle ? Dans le seconde cas, appartiennent elles au domaine de la mathématique ou de la logique ? Ou sinon, pour invoquer deux autorités reconnues en physique et logique : Einstein, dans un article qu'il consacra à Russell, reconnaissait être heureux de savoir que celui-ci disait que l'on ne pouvait se passer de métaphysique. L'un et l'autre n'étaient certes pas satisfaits par la solution kantienne sur la constitution de la métaphysique, mais il n'avait rien de mieux à proposer en échange, et, pour ma part, je ne trouve pas leurs objections recevables.

Que rajoute la solution kantienne

Et bien, à mon goût, elle a mis, pour la première fois dans l'histoire de l'humanité, la métaphysique (ce savoir dont on ne peut se passer) sur la route sûre de la science.

ou l'informatique théorique enseignée par Xavier Leroy cette année au Collège de France

les schémas de pensée qui y sont enseignés sont analogues à ceux qu'utilisa Kant pour mettre la métaphysique sur le chemin sûr de la science. Mais dans le cas de l'informatique théorique, c'est plus simple à comprendre. Pour reprendre l'exemple de Pierre Jarillon, il est plus simple de comprendre cette égalité 2^3 + 34 = 42 que celle-ci . Pour être honnête, lorsque j'étais encore un jeune étudiant en logique mathématique et informatique fondamentale, que l'on m'enseigna les principes du lambda-calcul typé (programmation fonctionnelle avec typage statique, le cœur du cours de Xavier Leroy), j'étais déjà kantien depuis plusieurs années et maîtrisais parfaitement sa logique transcendantale. Résultat la chose me paru évidente quand on me l'enseigna, c'était du « déjà connu », et j'obtins 20 comme note pour ce module.

Qu'est-ce qui te retient d'ajouter du sucre syntaxique pour former des énoncés clairs ? En effet, énoncer que tous les hommes sont mortels, est-ce une question de droit, est-ce le fait d'un pouvoir législatif ? Non, alors que veux-tu exprimer ? S'il te plait, exprimes-le clairement.

Si tu te donnes la peine de relire le texte de Kant que je cite juste en dessous, tu sauras ce que j'ai voulu exprimer.

En espérant avoir éclairé ta lanterne.

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

« scientifique » est une démarche plus une confrontation avec ses pairs, sens qui est tout de même assez récent : 19e siècle, je crois que c'est dans Kuhn.

Je vois ce que tu veux dire, mais publier un traité pour fonder une science nouvelle (telle était sa prétention), n'est-ce pas se confronter à ses pairs ? Pour quelle raison penses-tu qu'une personne publie un traité, si ce n'est pour rendre public sa pensée et la confronter à ses pairs ? Et les prolégomènes, publiés trois ans après la CRP, c'est pour quelle raison ? À son époque, la métaphysique était bien enseignée comme une science à l'université. Il occupait même la chaire de Logique et métaphysique à l'université de Königsberg. Ce qu'il a fait, avec la CRP, c'est globalement dire à ses pairs : « tout ce qu'on le prenait jusqu'ici pour de la science n'est que du vent, l'édifice de notre soit disant science n'est qu'un tas de ruine, voici le plan qu'il faudrait mettre en pratique pour le reconstruire et faire enfin de la métaphysique une science. Qu'en pensez-vous ? ». Et tu n'appelles pas cela se confronter à ses pairs ? Raison pour laquelle il a, en autre, qualifié sa démarche de « révolution copernicienne » tout comme Copernic a remis en cause le modèle géocentrique admis à son époque.

De plus, c'est bien une volonté de réfutation du kantisme (comment peut-on vouloir réfuter quelqu'un qui ne se confronte pas) de la part de Frege qui a aboutit à l'avènement de l'informatique.

Au XXème siècle, la notion de calcul s'est développée en relation avec celle du raisonnement. Avant d'aborder l'histoire du calcul, faisons une courte digression pour nous intéresser à celle du raisonnement. Nous avons laissé cette histoire aux logiques d'Aristote et des stoïciens, qui n'était suffisantes, ni l'une ni l'autre, pour exprimer les raisonnements mathématiques, car la grammaire des propositions dans ces deux logiques étaient trop fruste. Ce problème de trouver une grammaire pour les propositions mathématiques n'a pas avancé jusqu'à la fin du XIXème siècle, malgré quelques tentatives courageuses, comme celle de Leibniz. Le principal artisan de ce renouveau est Gottlob Frege, dont les motivations étaient surtout philosophiques : il s'agissait pour lui d'éclairer, et de contredire, un point de la philosophie d'Emmanuel Kant.

Gilles Dowek, Les métamorphoses du calcul.

Ce que voulait contredire Frege était l'affirmation kantienne selon laquelle tout les jugements mathématiques étaient synthétiques a priori. C'est ce qui engendra la formalisation de la théorie des ensembles de Cantor-Frege, les paradoxes de Burali-Forti et Russell, la crise des fondements de mathématiques, le programme de Hilbert puis, in fine, les théorèmes d'incomplétude de Gödel et l'impossibilité de résoudre le problème de l'arrêt par Turing. Voilà, en gros résumé, un fragment de l'histoire des mathématiques qui part de cette simple volonté de réfuter Kant. Et que retient-on aujourd'hui ? Et bien que Kant avait raison. Du moins c'est ce que laisse comprendre Gilles Dowek (chercheur INRIA) ainsi que Jean-Yves Girard (mathématicien et logicien, ancien chercheur CNRS, auteur entre autre du système F, système de types à la base de langage comme Haskell ou OCaml, et de la logique linéaire) dans son dernier livre.

Le principal bénéficiaire de cette visite non guidée aura été l'auteur, tout surpris d'y trouver matière à de futurs développements techniques. Et de découvrir la surprenante adéquation du kantisme — au sens large — à la logique contemporaine. Ce qui n'est pas très étonnant après tout : que veut dire "raison pure", sinon logique ?

Jean-Yves Girard, Le fantôme de la transparence.

Ces derniers travaux portent même le nom de Syntaxe transcendantale :

La syntaxe transcendantale est la justification technique des thèses du fantôme de la transparence. Le programme est exposé dans l'article La syntaxe transcendantale, manifeste (Février 2011)

Même s'ils ne partagent pas toutes mes opinions sur le kantisme (il faudrait, si je les comprends bien, une sorte de kantisme renouvelé à la lumière des progrès de la logique, tout comme Einstein a réformé Newton), on est plus proche d'un accord sur l'importance de la révolution kantienne en philosophie. Et ce genre de confrontation avec la pensée d'un auteur, même mort il y a deux cent ans, j'ai du mal à ne pas la voir comme de la confrontation avec ses pairs.

Pour en revenir sur ce que n'acceptait pas Frege (ce qui a engendré des travaux de recherche aboutissant à l'ordinateur), c'est cela :

Les jugements mathématiques sont tous synthétiques. Cette proposition semble avoir échappé jusqu'ici aux observations des analystes de la raison humaine, et même être exactement opposée à toutes leurs conjectures, bien qu'elle soit incontestablement certaine et très importante dans ses conséquences. En effet, comme on trouvait que le raisonnement de mathématiciens procédaient tous d'après le principe de contradiction (ce qu'exige la nature de toute certitude apodictique) on se persuada que les principes aussi étaient connus à partir du principe du contradiction : en quoi ces analystes se trompaient; car une proposition synthétique peut bien être saisie d'après le principe de contradiction, mais de telle sorte qu'une autre proposition synthétique soit présupposée, d'où elle puisse être déduite, mais jamais en elle-mếme.

Kant, Critique de la Raison Pratique.

On peut noter aussi, qu'à l'époque ou naquit la polémique, Poincaré écrivit des articles sur la logique et les mathématiques pour défendre Kant face à, entre autre, Russell et Hilbert.

Tout cela pour montrer, que ce soit Kant lui même de son vivant, ainsi que d'autres penseurs après sa mort n'ont eu de cesse de se confronter entre pairs sur les principes fondamentaux de sa philosophie.

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.