kantien a écrit 1187 commentaires

Le grand public n'utilisera pas votre logiciel client s'il n'y a pas des offres d'hébergement grand public. La base quoi.

oui bien sûr. Mais j’espère plutôt voir des hébergements locaux/associatifs.

J'ai du mal à te suivre sur cette question, Goffi. Tu ne veux pas qu'XMMP ait du succès (titre de l'article) ? Sans offre marchande, cela restera à jamais confidentiel.

As-tu un problème avec l'économie marchande ? Penses-tu qu'elle pervertie nécessairement tout service ?

À une époque j'étais musicien, je faisais aussi bien de la musique de rue (rémunération au bon vouloir des personnes, similaires au don) que des concerts dans des bars et restaurants avec chapeau en supplément, ou des prestations contractuelles avec rémunération fixée dans les termes du contrat. Je n'ai jamais eu l'impression de me trahir dans le dernier cas, bien au contraire. L'engagement contractuel imposait plus de devoirs et contraintes sur ma personne au niveau de la qualité de la prestation, pouvant prévoir les rentrées d'argent cela libère plus de temps pour préparer la prestation (temps de répétition), et au final les prestations étaient de bien meilleur qualité.

Non, décidément, je ne vois pas où se situe le problème dans une offre marchande de prestation de service.

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

Non bien sûr, les graphes orientés c'est du bon sens populaire, l'autre jour j'en parlais avec ma boulangère. Elle m'a d'ailleurs dit "oublie pas d'étiqueter les arêtes sinon c'est un peu trop simple".

Je ne comprends absolument pas le sens de cette partie de ton commentaire. On va reprendre l'historique de nos échanges, ce sera plus clair.

Tu as commencé par écrire

git ne gère pas des patchs mais un graphe orienté d'états successifs

ce à quoi je te réponds

pijul aussi gère, à sa façon, un graphe orienté d'états successifs : un dépôt c'est une catégorie, c'est-à-dire un graphe orienté qui vérifie certaines propriétés

tu réagis ensuite par

C'est marrant comme il suffit de parler d'un concept mathématique relativement avancé en termes un tant soit peu profanes pour t'invoquer.

et je réponds à cela par

Je n'ai pas vu à quel moment il a été fait mention d'un concept mathématique relativement avancé en termes profanes. Tu disais que git gère un graphe orienté d'états successifs, je t'ai répondu que pijul faisait de même.

À moins que j'ai complètement la berlue ou que j'ai perdu la raison, c'est bien toi qui as parlé de graphe orienté et je ne vois toujours pas en quoi c'était en termes profanes. Que ta boulangère ne sache pas ce qu'est un graphe orienté, personne ne l'a nié, mais là n'était pas la question. Le fait est que pijul aussi gère un graphe orienté d'états successifs, la différence entre les deux outils ne se situe pas à ce niveau là. Que ce graphe soit une catégorie (et c'est peut être cette notion que tu appelais « concept mathématique relativement avancé »), on s'en fout un peu dans le fond, raison pour laquelle j'ai ensuite écrit :

Mais laissons donc de côté le concept de catégorie et gardons donc celui de graphe orienté : il sera compris de tout le monde.

Il va de soi que par mon tout le monde, j'entendais tout programmeur (ce qui exclus ta boulangère, à moins qu'elle ne programme dans ses moments de loisir), c'est-à-dire les seules personnes susceptibles de discuter des entrailles de ce genre d'outils.

Reprenons la distinction entre pijul et git.

les deux graphes colorés un peu différents

D'accord je vois certains cas où le comportement de git peut différer suivant la stratégie choisie. Ce sont des symptômes de "n'importe quoi as a process".

Là je ne comprends pas trop non plus. Les deux graphes en question expose la même situation que celle dans le lien du tout premier commentaire de pamaury, et à ce moment tu ne semblais pas avoir compris. Pourtant ils disent la même chose. En revanche tu continues avec :

J'ai essayé de l'illustrer avec du "vrai code" avec mon histoire de validation d'utilisateur

sauf que ton exemple ne correspond pas du tout à cette situation. Ton code illustre deux branches qui divergent et qui rentrent en conflit quand on les fusionne : ce n'est pas du tout ce qu'illustrent les graphes colorés. Ils illustrent deux stratégies qui ne génèrent pas nécessairement de conflit mais avec deux résultats différents pour git et un seul avec pijul. Ainsi, lorsque tu écris :

dans tous les cas on arrivera sur le même état Q

Premièrement : dans un cas "réel" l'auteur a été obligé d'admettre que pijul n'arrivera nul part, qu'il abandonnera en déclarant un conflit.

tu n'as toujours pas compris. Non, dans un cas réel il n'y a pas nécessairement conflit et pijul arrivera bien toujours dans le même état Q quelque soit le chemin pris dans le graphe, c'est-à-dire quelque soit la stratégie utilisée. Assurément, bien que git fusionne sans se plaindre (il n'y a pas de conflit) le code ne compilera pas, mais cela demandera un travail supplémentaire au développeur ou alors il faudra utiliser un workflow conditionné par l'outil. On est là dans le même genre de problématiques qu'entre typage statique ou typage dynamique : pour éviter les runtime error (un code qui ne compile pas après fusion) il faut prendre ses précautions.

Pour la suite :

là où, par construction, elle est automatiquement satisfaite dans pijul

Non. Cf. point précédent. Ou alors pour mon code de gestion d'utilisateurs, donne-moi le code final automatiquement produit (indice : il est indécidable (ça devrait te plaire comme mot)).

Si ! cette propriété est automatiquement satisfaite par construction dans pijul. Cf. mon point précèdent. Ton exemple de code de gestion d'utilisateur est hors propos pour parler de cette spécificité de pijul.

De plus, personne, mais alors vraiment personne, n'a prétendu qu'il existait un outil de fusion magique qui résout les conflits tout seul. Là n'est pas la question, ni le problème que cherche à résoudre pijul.

Pour la question des patchs indépendants :

Non, tu ne les as pas compris. Cf. argument précédent : si deux patchs ne se recouvrent pas "géographiquement" ils sont interchangeables.

La question n'était pas là mais celle-ci : dans un tel cas, git crée-t-il automatiquement deux branches distinctes dans son graphe d'états pour se faciliter le travail ?

La problématique de fiabiliser la production logicielle m'intéresse réellement.

Je veux bien te croire, mais tu ne sembles pas disposer à faire l'effort d'essayer de comprendre ce que les autres écrivent. Dans un autre journal où j'essayais d'illustrer l'analogie stricte entre typage statique et démonstration de théorèmes, tu m'avais également lu de travers. À moins que tu ne considères pas le typage statique comme relevant de la problématique de fiabiliser la production de logicielle. Une partie du système qui gère les lignes automatiques du métro parisien a été développé selon une telle méthodologie, et il est difficile de remettre en cause pas les faits sa fiabilité.

Je suis un fan de git, mais si concrètement pijul apporte de vraies avancées, j'en parlerai au boulot !

Si git te satisfait pleinement, pourquoi changer d'outil ? Pijul offre certes des avancés (ne serait-ce que celle de fournir une spécification à la notion de fusion), mais pas celles qui semblent correspondre à tes attentes :

Et ça pijul ne le garantit évidemment pas, puisqu'il ne parle pas tous les langages de programmation / de balisage / les langues du monde (si on décide de versionner un manuscrit par exemple), et n'a encore moins conscience des specs du code. Je pense l'avoir illustré par mon exemple de fonction de récupération d'utilisateur. Je ne changerai pas d'avis tant qu'on ne m'aura pas prouvé que pijul résout le problème.

Pijul ne le résout évidemment pas, personne n'a jamais dit le contraire, il n'y a rien à prouver. Tu l'as dit toi même : aucun logiciel ne viendra jamais le résoudre, le problème est indécidable, c'est même pire, il est informulable (le problème n'est pas l'absence de procédure de décision, mais qu'on ne peut même pas l'exprimer formellement).

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

Mais en fait le mouvement est inverse, c'est de simplement rappeler que l'humain est un animal.

Quel est l'intérêt dans un tel contexte ? Ce n'est pas en tant qu'animal que l'humain a des droits, mais en tant qu'animal doué de raison. En conséquence de quoi, il est libre, responsable de ses actes et a les devoirs et droits inhérents à cette liberté. Les autres espèces animales n'étant pas libres (c'est-à-dire autonomes, se donnant à elles même leurs propres lois, mais sont soumises aux seules lois de la nature, ce qui en fait des créatures hétéronomes), elles n'ont ni devoirs ni droits.

Je ne vois toujours pas pourquoi écrire « droits des animaux humains », si ce n'est pour sous-entendre que l'on pourrait également parler de « droits des animaux non humains ». Mais alors quels seraient leurs devoirs ? Peut-on envisager un débat contradictoire avec, disons, une vache ?

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

J'ai pas compris la critique sur la barre oblique.

Ah, les joies de la polysémie et de l'ambiguïté du langage. Je n'ai pas compris leur position de la même façon que toi.

Je comprends leur premier position sur le refus d'utiliser la barre oblique ainsi : le / est utilisé en algèbre pour exprimer l'opération de division (cf la réponse à côté de la plaque de kna, un rapport n'étant pas nécessairement un quotient, là où son « ou » paraît exprimer une synonymie entre les deux termes), mais de son côté la division peut aussi exprimer une opposition, un conflit entre deux camps (comme lorsque l'on dit que telle ou telle mesure politique, ou d'innovation de langage, divise le peuple). Ne voulant pas exprimer cette dernière connotation du mot « division », ils préfèrent ne pas faire usage du / dans la proposition de nouvelle graphie par crainte de l'association d'idée : / ⇒ division ⇒ conflit. De son côté, le point milieu n'ayant pas encore d'usage répandu et fixé par la tradition, il échapperait à cette association d'idée.

Mais alors pourquoi donc écrire « l'enjeu social et discursif du rapport femmes / hommes » et non tout simplement « l'enjeu social et discursif du rapport entre les femmes et les hommes » ? Le / ne serait pas ici porteur d'une connotation de conflit inhérent à un tel rapport, une telle relation ?

Ce qu'ils disent (si j'ai bien compris), c'est simplement que la barre oblique exprime une séparation entre deux groupes, alors que dans l'écriture inclusive, le but n'est pas de classifier "homme d'un côté", "femme de l'autre", mais plutôt d'avoir un "nouveau mot" qui décrit les deux.

Le but est de trouver une graphie qui rend explicite la subdivision d'un concept relativement aux genres des personnes qui peuvent l'habiter.

Idéalement, il faudrait introduire un nouveau genre neutre.

Ce n'est pas ce que fait un genre neutre : il rend la subdivision implicite.

Beaucoup de personne ici donne leur "solution parfaite"

D'une manière générale je fuis comme la peste toute personne prônant une solution parfaite, quelque soit le problème quelle cherche à résoudre : leur caractère tyrannique et despotique me saute trop aux yeux.

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

À coup de sophisme (A => B <=> ¬A => ¬B)

Tiens, c'est marrant que tu utilises la forme des jugements hypothétiques pour exprimer le rapport de cause à effet : c'est justement le principe même de la théorie des catégories kantiennes (regarde les deux tables et la correspondance au niveau des catégories de la relation). Théorie que n'a justement jamais comprise Witttgenstein (ce n'est pas pour autant que je ne partage pas sa position sur son aphorisme 5.6 du Tractacus logico-philosophicus).

Cela étant, pour le cas qui nous occupe, il est peu vraisemblable que le langage soit la cause des préjugés, mais plus vraisemblable (et conforme à la réalité historique) que les préjugés ont contribué à constituer notre langue et qu'ils s'entretiennent à travers elle.

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

ou mieux, les droits des animaux humains.

C'est dans un soucis de faire une distinction avec les droits des animaux non humains, ou c'est un trait d'humour que je n'ai pas saisi ?

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

Et tu fais quoi des agneaux ?

Faudrait demander à Michael Kael.

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

Ma sœur, qui travaille au CNAM, m'a ramené cet été son « Manuel d'écriture inclusive » gracieusement offert par la direction à ses employés (elle savait que ça me plairait, et je dois dire que quand je veux rire un bon coup, je le feuillette).

Ce manuel écrit par l'équipe de mots-cles vaut le détour et contient de magnifiques perles dont celle-ci :

Le point milieu permet d'affirmer sa fonction singulière d'un point de vue sémiotique et par là d'investir « frontalement » l'enjeu social et discursif du rapport femmes / hommes.

Je constate, avec regrets, à quel point les commentatrices et commentateurs de linuxfr ne perçoivent pas assez cette fonction singulière d'un point de vue sémiotique du point milieu. :-P

Dans le style jargon pédant, ils font fort ! Mais là où c'est le plus risible, dans la cohérence de la démarche, est que l'on peut lire sur la page précédente :

Le point milieu nous semble ainsi préférable au parenthèses (qui, en usage, indique un propos secondaire), à la barre oblique (qui connote une division) […]

Voici donc la barre oblique qui, d'un point de vue sémiotique, connote une division mais que l'on utilise une page plus loin sous la forme : « rapport femmes / hommes ». Va comprendre !

On notera également qu'il serait préférable d'employer l'expression « Droit de la personne humaine » en lieu et place de celle de « Droits de l'Homme » (qui fait usage de l'antonomase¹ du mot commun « homme »). Le pléonasme personne humaine est sans doute là pour faire la distinction d'avec les personnes canines, ce qui, soit dit en passant, pose un problème d'exclusion vis à vis des lycanthropes. :-P

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

C'est étrange, normalement le tas mineur a une taille de 2M sur une plateforme 64-bits, un fichier de quelques ko y rentre sans problème. Si tu traitais tes fichiers séquentiellement dans un boucle, je ne vois pas ce qui empêchait le GC de les collecter sans les envoyer dans le tas majeur. En revanche si tu commençais par lire tes 10_000 fichiers, puis que tu les traiter ensuite un par un, là effectivement tu devais solliciter beaucoup plus le GC. Mais dans ce cas ce n'est plus du tout le même algorithme qu'avec un char[] en C ou C++.

Sinon, pourquoi ne pas utiliser un buffer tampon de taille fixe comme tu l'aurais fait en C ou C++ ?

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

Si il y a plein de string partout, cela va bien plus vite, par contre, si il y a plein de string à vie courte, la consommation mémoire s'envole, car il est impossible de réutiliser un buffer.

Pourquoi la consommation mémoire s'envolerait avec des string à vie courte ? Le tas est en deux parties : le tas mineur de taille fixe pour les petits objets à vie courte et le tas majeur redimensionnable pour les objets à vie longue. Le comportement mémoire dépendra du ratio entre le taux de création des string, leur taille et leur durée de vie, mais il est probable qu'elles ne quitteront jamais le tas mineur et seront collectées sans avoir besoin d'être promues dans le tas majeur, seule situation qui pourra provoquer l'allocation de mémoire supplémentaire.

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

Rust n'a pas de GC, mais un système de propriété des variables qui est très marrant à utiliser.

Il me semble qu'il y a avait un GC dans les débuts de Rust, puis ils l'ont retiré. Felix Klock (membre de l'équipe en charge des nouvelles fonctionnalités du langage) a écrit une série d'articles intéressante sur le sujet :

• GC and Rust Part 0: Garbage Collection Background
• GC and Rust Part 1: Specifying the Problem
• GC and Rust Part 2: The Roots of the Problem

Pour ce qui est du multi-cœur en OCaml, c'est justement le GC qui pose problème. Xavier Leroy et Damien Doligez avaient écrit un article en 1993 A concurrent, generationnal garbage collector for a multithreaded implementation of ML qui était resté lettre morte avant de servir de base au projet OCaml-multicore. Comme pour pijul, cela pose pas mal de problèmes théoriques qui doivent d'abord être pleinement résolus avant d'avoir plus qu'un prototype. Le projet avance, mais au rythme de la recherche… ;-)

Même les téléphones portables ont des tas de cœurs, et la communauté OCaml est encore en train d'expliquer à qui veut l'entendre que ce n'est pas la bonne façon de programmer.

J'avais donc vu juste au niveau des besoins de parallélisation ? Je dois reconnaître que j'ai aussi du mal à comprendre la réaction d'une partie de la communauté quand elle explique que ce n'est pas la bonne façon de programmer.

Il y a bien des bibliothèques pour le parallélisme, comme functory, mais elles profiteraient d'un GC adapté au multi-cœur. Je m'étais servi de cette dernière pour faire le test du benchmark game sur les GC et ça rivalisait avec Rust (mais j'ai dû tuner le GC pour arriver à égaler les performances en temps CPU et c'était coûteux en mémoire).

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

C'est clair que ce sont les bugs les plus difficiles à dénicher et que Rust fournit un moyen de minimiser les risques mais je trouve quand même la mécanique super lourde.

Alors rejoins le mouvement des Insoumis et prône l'abolition de la concurrence, ainsi que de la défense de la propriété privée poussée à l'extrême en Rust. Mais je sens qu'un riche milliardaire profitant des innovations technologiques de la firme créée par son père n'est pas prêt à franchir le pas ! :-P

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

loin de moi l'idée d'ouvrir une guerre de paroisses

D'un autre côté, il a déjà du faire face à des commentateurs défendant git, il craignait peut être que ce soit pareil ici (d'autant que les guerres de chapelle entre langage peuvent être âpres).

Qu'est-ce qui ne vas pas avec les threads?

Le parallélisme ? Les approches à la Lwt (ou Async) c'est pratique mais ça ne parallélise pas les calculs sur tous les core du CPU. J'ai l'impression que la propriété de commutativité entre patchs indépendants se prête bien à la parallélisation des calculs. Il y a bien le projet ocaml-multicore (encore chez OCaml Labs) à base de fibres mais il en est encore au stade de la recherche (bien qu'il avance sûrement).

À l'heure actuelle, il faut forker (comme dans cet exemple du benchmark game) pour faire du map-reduce en parallèle, ce qui n'est pas des plus adapté comme solution.

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

je considère un peu rapidement que les sommets d'un graphe et ses arêtes sont des ensembles

Disons que la notion d'ensembles en mathématique est ambigüe (cf. le pardoxe de Russel), alors j'ai tendance à utiliser ce terme pour désigner les objets d'un modèle de la théorie des ensembles (ou les sommets d'un graphe qui est modèle de la théorie). Ce qu'il y a avec ZF (comme avec la théorie des catégories) est que l'on peut réflchir la métathéorie dans la théorie elle-même et aboutir à des théorèmes du style : si ZF est consistante alors elle a un modèle dénombrable (bien que le modèle en question possède des ensembles non dénombrables de son point de vue).

Pour une présentation succincte de la théorie des catégories, il y a le cours Inititation à la théorie des catégories de Gérad Huet qui commence ainsi :

Une catégorie C se compose d'objets et de flèches. On écrit A : C pour dire que A est un objet de C, et f : C(A,B) pour dire que f est une flèche de C reliant l'objet A à l'objet B. En général la catégorie dans laquelle on travail est sous-entendue, et on écrit plus simplement f : A -> B.

Jusqu'ici, une catégorie est un graphe orienté dont les nœuds sont les objets et les arcs sont les flèches. Mais les catégories possèdent la structure minimale donnée par l'associativité de la composition des flèches. Les flèches doivent donc être vue comme les chemins du graphe, quotientés par l'égalité des flèches.

Comme les notations ci-dessus te rappellerons celles utilisées pour les annotations de typage en OCaml, et que CAML signifie Categorical Abstract Machine Language (c'est la machine abstraite du bytecode OCaml), tu pourras aussi jeter un œil à De la déduction naturelle a la machine categorique :

Le titre de cet article résume trois slogans :

• La Déduction naturelle, c'est du lambda-calcul.
• Le lambda-calcul, c'est la théorie des Catégories Cartésiennes Fermées.
• La théorie des Catégories Cartésiennes Fermées, c'est du langage machine.

On réalise ainsi le Programme de Constructivation des Mathématiques :

   preuve       ---->  programme   ---->  combinateur --->    code
intuitionniste         fonctionnel        catégorique       exécutable

Sinon, pour en revenir à pijul, j'ai eu une nouvelle idée pour présenter la notion de fusion dans ce système. Quand on a une relation reflexive et transitive (un préodre), on peut la voir comme une catégorie (en réalité ce sont les catégories ayant au plus une flèche entre deux objets). Prenons, par exemple, la catégorie dont les objets sont les entiers et la relation de préodre « être un multiple de ». Ainsi le schéma de fusion suivant :

peut se lire : A et B sont des mutliples de O (A = p * O et B = q * O) et M (M = r * A = s * B) est un multiple commun de A et B. Mais parmi tous les mutliples communs de A et B, il y en a un qui est plus petit que les autres : c'est lui la fusion !!! Ce qu'exprime ce diagramme :

si je prends un autre multiple F de A et B alors il est multiple de leur ppcm M.

Cette notion, qui est une généralisation de la notion de borne supérieure (le plus petit des majorants si on y voit une relation d'ordre, le descendant minimal dans l'historique du dépôt) est ce que les catégoriciens appellent une somme amalgamée. Comme une telle somme n'existe pas toujours si on prend pour objets des fichiers, il faut prendre pour objets des digles.

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

Il me semble que le principal inconvénient, à l'époque, d'OCaml comme choix a été le support sur Windows.

Et il semble bien qu'un bon support de Windows soit un critère essentiel pour pijul, ils ont même écrit leur propre bibliothèque ssh pour cela (openssh supporte mal Windows). Il y a peut être aussi des raisons liées à la performance, en particulier sur la gestion du parallélisme (les quelques libs que j'ai testées pour faire du map-reduce sont tout de même coûteuses en mémoire, ocaml-multicore devrait résoudre ce problème).

Le mieux serait que pmeunier expose ses raisons, mais il est peut être passé à côté de la question.

Mais bon, si j'ai le temps je pourrais m'y pencher et faire revivre l'implémentation en OCaml :D !

Implémenter git en OCaml ne t'a pas suffit ! ;-D Tu vas devenir un spécialiste des systèmes de gestion de versions.

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

Ce n'est pas plutôt le contraire?

Non, c'est bien ce que j'ai écrit : toute catégorie est un graphe orienté, mais la réciproque est fausse. Une catégorie est un graphe orienté qui doit vérifier un certain nombre d'axiomes; autrement dit, ces axiomes sont des contraintes imposées au graphe et tout graphe qui ne les satisfait pas ne peut représenter une catégorie.

Comme tu évoques la notion d'ensemble, voici un exemple : un modèle de la théorie des ensembles est un graphe orienté qui n'est pas une catégorie. La théorie des ensembles est une théorie axiomatique d'une relation binaire que l'on appelle l'appartenance (notée ) et une relation binaire peut parfaitement se représenter comme un graphe orienté où l'existence d'une relation entre deux objets est signifiée par la présence d'une arête entre les deux sommets du graphe. Pour qu'un tel graphe puisse représenté une catégorie, il faudrait que la relation soit réflexive et transitive : ce qui n'est pas le cas de la relation d'appartenance, ni de nombreuses autres relations binaires.

En revanche on peut toujours, à partir d'un graphe orienté, engendrer une catégorie en prenant sa fermeture transitive :

puis en rajoutant une flèche de chaque sommet vers lui-même.

Pour revenir sur le graphe de l'univers des ensembles, les contraintes imposées par les axiomes sont tels que l'on peut plonger ou encoder n'importe quelle construction mathématique en son sein. La généralité de la notion de catégorie permet de faire la même chose : ce sont deux approches distinctes sur le fondement des mathématiques mais d'égale utilité.

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

C'est marrant comme il suffit de parler d'un concept mathématique relativement avancé en termes un tant soit peu profanes pour t'invoquer.

Je n'ai pas vu à quel moment il a été fait mention d'un concept mathématique relativement avancé en termes profanes. Tu disais que git gère un graphe orienté d'états successifs, je t'ai répondu que pijul faisait de même.

Je sais d'avance que la suite de cette conversation sera, en réponse, un autre pavé encore plus indigeste pour moi, que je ne comprendrai carrément pas, car j'ai arrêté les maths suffisamment tôt pour ma satisfaction professionnelle vu que j'aime mon travail, mais trop tôt par rapport à la maitrise d'icelles que j'aimerais avoir, mais bon je me lance quand même.

Si mes réponse apparaissent comme des pavés indigestes, alors c'est que j'ai échoué à atteindre mon objectif. Mon intention principale, quand j'écris sur ce site, est d'être compris par le plus grand nombre et non d'utiliser des termes pédants et abscons. Ton choix d'avoir arrêté les maths suffisamment tôt pour ta satisfaction professionnelle est on ne peut plus respectable : chacun fait et étudie ce qu'il lui plait. Cela étant, si je peux réussir à te faire comprendre ce qui distingue git et pijul sans entrer dans des détails techniques et théoriques, j'aurai atteint mon objectif.

Du peu que je sais j'ai l'impression que le c'est-à-dire est à l'envers.

Comme te l'a déjà répondu Michaël : toute catégorie peut être vu comme un graphe orienté (on les présente souvent ainsi d'ailleurs) mais la réciproque n'est pas vraie; mon c'est-à-dire n'est pas mis à l'envers. Mais laissons donc de côté le concept de catégorie et gardons donc celui de graphe orienté : il sera compris de tout le monde.

Git stocke en premier lieu des "états"-"sommets" qui représentent concrètement et trivialement le contenu brut du dépôt aux instants T(x), et ajoute par dessus un graphe de relations bête et méchant. J'ai l'impression que pijul travaille dans l'autre sens en ayant comme citoyen de première classe les arêtes avec le patch comme contenu, et en déduit des sommets-"état du dépôt".

De ce que j'en ai lu et compris, pijul aussi a pour sommets dans son graphe le contenu du dépôt aux instants T(x), à savoir les fichiers de la branche de travail. En revanche, pijul voit l'évolution de l'historique d'un dépôt comme un succession de patchs appliqués sur lui et c'est ce que représente son graphe en étiquetant chaque arêtes par un patch. Ce qui donne bien aux patchs un statut de citoyens de première classe, mais il ne passe pas son temps à déduire les fichiers par application des patchs par simple soucis d'efficacité :

Fast algorithms: Pijul's pristine can be seen as a "cache" of applied patches, to which new patches can be applied directly, without having to compute anything on the repository's history.

pijul documentation

Venons-en maintenant à une propriété qui distingue git et pijul : l'associativité. C'est certes une notion mathématique mais simple à comprendre : elle dit, en gros, dans le cas de l'addition, que (a + b) + c = a + (b + c) ce qui fait qu'en général on se dispense d'écrire les parenthèses et que l'on écrit tout simplement a + b + c.

Il est très utile, en pratique, d'avoir des opérations associatives et lorsque ce n'est pas le cas, il faut faire attention à la manière dont on les regroupe. Si je reprend l'exemple de la multiplication des matrices données dans un autre journal pour réduire le nombre de cache miss :

/* traduction directe de la formule du produit */
for (i = 0; i < N; ++i)
  for (j = 0; j < N; ++j)
    for (k = 0; k < N; ++k)
      res[i][j] += mul1[i][k] * mul2[k][j];

/* optimisation pour réduire les cache miss */
for (i = 0; i < N; i += SM)
  for (j = 0; j < N; j += SM)
    for (k = 0; k < N; k += SM)
      for (i2 = 0, rres = &res[i][j],
           rmul1 = &mul1[i][k]; i2 < SM;
           ++i2, rres += N, rmul1 += N)
        for (k2 = 0, rmul2 = &mul2[k][j];
             k2 < SM; ++k2, rmul2 += N)
          for (j2 = 0; j2 < SM; ++j2)
            rres[j2] += rmul1[k2] * rmul2[j2];

Dans son article, Ulrich Drepper précise bien « we ignore arithmetic effects here which might change the occurrence of overflows, underflows, or rounding », et il a raison : l'addition n'étant pas associative en arithmétique flottante, les deux programmes ne sont pas identiques. Mais son intention était surtout de montrer que l'ordre dans lequel les instructions étaient effectuées avaient son importance sur la gestion du cache CPU.

Quittons cette courte digression et revenons à nos moutons. Si l'arithmétique flottante n'est pas associative, il n'en est pas de même des séries d'instructions dans un langage comme le C : (e1;e2);e3 se comporte comme e1;(e2;e3) ou e1;e2;e3. Par contre, la fusion des patchs et commits en git ne vérifient pas cette propriété. C'est ce qui lui est reproché, entre autre, par les promoteurs de darcs et pijul. Le lien du premier commentaire illustrait ce phénomène, et la documentation de pijul l'illustre avec ces deux schémas :

si chaque point illustre des patchs appliqués, disons A B C, alors avec git on aurait : (A;B);C ≠ A;(B;C). C'est ce qui se passe quand on fait du cherry-picking et du rebase. En revanche, pijul vérifie bien cela et c'est ce qu'illustrait ce graphe :

Si l'on part de l'état O du dépôt, qu'Alice et Bob fork pour aller l'un dans l'état B et l'autre dans l'état C. Puis Alice passe ensuite dans l'état M. Peu importe que l'on fusionne d'abord B et C dans l'état N pour ensuite fusionner N et M, ou que l'on fusionne directement C et M : dans tous les cas on arrivera sur le même état Q. Pour revenir rapidement sur la notion de catégorie, cette propriété d'associativité fait partie de sa définition : un graphe qui ne la vérifie pas ne peut être vu comme une catégorie, en revanche une catégorie vue comme un graphe la vérifiera.

Comme l'a dit pmeunier, git ne vérifiant pas cette propriété (pourtant utile et, dans le fond, désirée par les utilisateurs), il y a des guides de bonnes pratiques pour combler cette lacune, là où, par construction, elle est automatiquement satisfaite dans pijul.

Outre cette propriété d'associativité des patchs, il y en a une autre fort utile : celle qui cherche à capter l'essence de fonctionnalités orthogonales ou indépendantes. Si, dans un commit, je modifie une partie d'un fichier, puis dans le commit suivant j'en modifie une autre qui n'a rien à voir : peu importe l'ordre dans lequel je les réalise, on devrait aboutir au même résultat. Cette propriété s'appelle la commutativité des patchs, à savoir p1;p2 fait la même chose que p2;p1 (ou a + b = b + a). Pijul détecte automatiquement de telle situation et transforme (de manière transparente pour l'utilisateur) le graphe de dépendance des états. Dans une telle situation :

pijul va chercher s'il ne peut trouver un patchs a(q) telle que dans le graphe suivant :

la fusion des états A et C donne le même état B que dans la séquence p;q, et en arrière plan on aura dans le graphe de pijul cette situation :

ce qui permet, entre autre, de paralléliser les calculs, mais rend aussi le graphe plus flexible à l'usage. Les guides de bonnes pratiques expliquent également comment obtenir une telle chose en git : avec pijul, rien à faire, elle est fournie de base sans effort de le part des utilisateurs.

Un dernier point, un peu plus technique que ce qui précède, mais pas si difficile à comprendre, c'est là raison d'être des digle. Lorsque l'on cherche à fusionner deux états, on se retrouve dans la situation suivante :

     A
   /   \
  /     \
O        ??
  \     /
   \   /
     B

Le problème est que si l'on prend pour type des sommets celui des fichiers, ce problème n'a pas toujours de solution : c'est ce qu'il se passe lorsqu'il y a conflit. Il y a un principe général qui consiste à dire : si le problème n'a pas de solution, alors agrandissons l'espace du possible et il aura toujours une solution. C'est, pour donner une comparaison, ce qu'on fait les algébristes quand ils ont inventé les nombres complexes : certains polynômes n'ont pas de racines, ce n'est pas grave, il suffit de rajouter des nombres et tout polynôme aura une racine. Raison pour laquelle, en cas de conflit, pijul produit pour sommet un graphe orienté de lignes et non un fichier. De la même façon que l'on peut projeter de plusieurs façons différentes un nombre complexe sur un nombre réel, on peut aplatir de différentes façon un digle en un fichier ou réduire de différentes façons un conflit. Mais cette phase ne résolution, comme dans git, n'est pas effectuée automatiquement par pijul mais reste à la charge des programmeurs.

En espérant avoir éclairci quelques différences entre git et pijul, sans avoir écrit un pavet indigeste.

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

Au delà de l'aspect esthétique – dont l'expérience montre en général qu'un problème mieux représenté est également mieux compris et les traitements afférents sont plus faciles –

Au fond, je n'en doute pas vraiment. J'ai présenté la chose ainsi¹ pour ne pas heurter certaines sensibilités. Si je devait faire un parallèle, le fondement du système me fait penser au passage du paradigme ptoléméen avec ces épicycles au paradigme héliocentrique de Copernic et Kepler.

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

Qu'est-ce que pijul va faire au merge ?

Il va dire qu'il y a conflit, comme git. Mais la différence entre les deux outils (ou plutôt entre leur fondement théorique) ne se situe pas à ce niveau là, c'est-à-dire que ce n'est pas sur ce genre de question qu'ils se distinguent : pijul n'est en rien un outil magique qui résout tout seul les conflits de merge en devinant ce qu'il y a dans la tête des programmeurs.

En fait, je me suis rendu compte que j'ai mal utilisé le terme de « 3-way merge » ce qui t'a sans doute induit en erreur sur le fonctionnement de pijul.

Je n'ai pas le temps de corriger mon erreur de présentation, j'essaierai de voir demain. Sinon, le plus simple est d'aller lire les deux articles de blog que j'ai donné en lien, je voulais juste en faire un résumé et un teaser.

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

Je m'avance beaucoup sur la maitrise de la chose, mais git ne gère pas des patchs mais un graphe orienté d'états successifs.

pijul aussi gère, à sa façon, un graphe orienté d'états successifs : un dépôt c'est une catégorie, c'est-à-dire un graphe orienté qui vérifie certaines propriétés. Les sommets du graphes sont des « fichiers » et les arcs des patchs : si il y a un arcs entre deux sommets alors la cible est le résultat du patch appliqué à la source.

En réalité les sommets ne sont pas des fichiers mais une notion étendue des ceux-ci : des digle (directed graph fi le). Si le graphe est linéaire on a un fichier au sens usuel (ligne à ligne), tandis que l'on obtient un graphe en cas de conflit lors d'un merge.

Résoudre un conflit revient juste à appliquer un patch sur un tel sommet : ainsi pijul garde en mémoire, dans son graphe, le sommet conflictuel au lien de l'effacer.

Un des propriétés marrantes c'est l'associativité des patchs :

Ici on a un 3-way merge¹ qui s'obtient naturellement comme la composition de merge de 2 patchs : quelque soit le chemin pris on arrivera toujours sur le même état final Q. C'est cette propriété que n'ont pas les autres DCVS comme git et qui constitue la reproche des partisans de darcs et pijul.

Après, je ne sais pas si en pratique cela s'avérera d'un grand intérêt et plus souple à l'usage que l'existant, mais la théorie qu'il y a derrière est jolie. Elle est expliquée plus en détail dans ces deux articles de blogs :

• Merging and patches
• Merging, patches, and pijul

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

Bah non ça va plus vite : si tu mets moins de temps pour faire la même chose (O.76 seconde au lieu de 1 seconde), tu vas plus vite. Il a réduit le temps d'exécution de 24% et donc augmenté la vitesse de 31% (1 / 0.76 ~ 1.31).

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

Je me disais que passais à côté de la blague.

Pour calmer des chiens de garde, il faut leur caresser l'échine ? :-P

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

L'exemple avait pour but d'illustrer l'analogie et la correspondance fonctionnelle entre un théorème et un programme, ainsi que le parallèle entre la recherche de preuve et la résolution algorithmique d'un problème. On ne peut nullement en conclure :

• que toute fonction ainsi obtenue est efficace (complexité tant en temps qu'en espace) ;
• que toute fonction ainsi obtenue est inefficace.

Je n'ai jamais soutenu la première (ce que tu laisses sous-entendre), tu sembles fortement insister pour soutenir la seconde. Les deux propositions n'étant pas antinomiques, il reste une troisième possibilité…

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

Je crois qu'il y a un problème de compréhension entre nous.

Non c'est ton interprétation biaisé. L'informatique n'est en rien une branche des mathématiques, sauf dans l'esprit tordu des logiciens qui ne peuvent la concevoir autrement.

C'est exactement ce que je venais d'écrire et je suis d'accord avec toi, m'étais-je mal exprimé ? Ma phrase que tu cites était :

autrement elles ne seraient pas traitée comme deux sciences distinctes, mais la première serait simplement une branche de la seconde.

Que l'on pourrait reformuler ainsi : si l'informatique était une branche des mathématiques alors elles ne seraient pas traitées comme deux sciences distinctes, or elles sont traitées comme deux sciences distinctes (à bon droit), donc l'informatique n'est en rien une branche des mathématiques.

Je ne vois pas comment je peux exprimer plus clairement le fond de ma pensée. À quel moment ai-j écrit (ou peut-on conclure de mes commentaires) que l'informatique est une branche des mathématiques ?

Ah manque d'arguments donc attaque personnelle.

Ce n'était nullement une attaque personnelle. La photo est une caricature grossière : n'importe quelle personne, même quelqu'un n'ayant jamais étudié la physique, comprend que l'équilibre de gauche est totalement instable. C'est en cela qu'il me fait plus penser à la solution proposée par freem à laquelle GuieA_7 reprochée (je le cite) :

À part des cas très spécifiques, par exemple toutes ces conditions sont vérifiées:

• on n'a pas de thread donc pas possible que ça introduise un bug.
• on a vérifié que l'optimisation règle effectivement un problème en production très critique.
• on doit livrer très rapidement une version qui corrige ledit problème mais sans casser l'API, et derrière on fera une version avec une nouvelle API correcte (celle que je proposait par exemple) (on peut même garder la vieille API en "deprecated").

soit on garde la vielle version (lente mais correcte), soit on fait une version rapide et correcte (ce qui en l'occurrence n'était pas bien long, les lignes en plus n'étant quelques déclarations). Mais conseiller en premier une bidouille infâme ne me semble pas une bonne chose ; le C++ est déjà assez piégeux comme ça.

réponse (d'un ingénieur ou d'un scientifique, peu m'importe je ne suis ni l'un ni l'autre, je ne suis dans aucun camp et n'est pas de problème d'égo) qui relève clairement du côté droit de ton image.

Donc l'informatique tout entière peut-être ramenée à un système de typage et un triangle rectangle. Intéressant comme la logique d'un logicien peut parfois être biaisé quand ça l'arrange.

Je n'ai jamais soutenu une telle chose.

Ton pavé ne change strictement rien à ce que je disais.

Tel n'était pas son but. Il avait pour finalité d'apporter une objection à ce propos : « l'idée d'adopter une pensée mathématique quand on code¹ ne me semble pas une bonne idée du tout » et de montrer qu'une pensée structurée mathématiquement² pouvait traiter les problématiques attendues par arnaudus, à savoir : « efficacité de l'algorithme en temps et en mémoire, gestion des arrondis, évolutivité, modularité et clarté du code ».

re-déballe en boucle ses propres examples non corrélés.

Qu'entends-tu pas exemples non corrélés ? Les lignes automatiques du métro parisien (la ligne 14 date de la fin des années 90) est-ce un exemple corrélé et qui te conviendrait ?

L'inventeur de l'atelier B a donné une conférence sur le sujet au Collège de France. Il se présente ainsi :

Il y a deux sortes de chercheurs : les prolifiques et les monomaniaques. Je fais partie de la seconde catégorie, car j'ai toujours pratiqué le même genre d’investigations, à savoir la spécification et la construction vérifiée de systèmes informatisés.

Au sujet du développement de la ligne 14, il y dit :

la RATP décide de supprimer les tests unitaires et d'intégration

Octobre 98 : lancement de la ligne 14

Depuis lors pas de problèmes avec le logiciel développé

avec pour méthode de développement :

86.000 lignes en ADA ont été produites automatiquement

27.800 preuves ont été faites

92% ont été prouvés automatiquement par l'Atelier B

Coût des preuves interactives : 7 hommes-mois

Les preuves interactives sont moins chères que les tests

J'ai du mal à croire qu'un tel système n'est pas à gérer du threading et des I/O.

Du côté de Coq, j'ai du mal à voir CompertCert (un compilateur C certifié) comme un échec des approches formelles. Xavier Leroy a même reçu le prix Milner, entre autre pour cela, et j'avais écrit un journal à l'occasion.

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

Petit ajout, pour reprendre ton image :

L'image de gauche c'est freem rappeler à l'ordre par GuieA_7, l'image de droite c'est ce que je prônes; mais bizarrement j'inverserais les légendes. :-P

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