barmic a écrit 927 commentaires

La meilleure façon de capturer les dépendances – meilleure parcequ'elle est exhaustive et indépendante du compilateur – est de tracer les appels système.

On peut tout de même garder son calme. D'une part tous les langages sorti depuis 10 ou 15 ans ont résolu par conception l'ensemble de ses problèmes (et un tas de langages plus anciens l'avait déjà résolu avant). C'est quelque chose qui est surtout utile pour les langages comme le C, le C++, le fortran, (La)TeX,… qui sont tous de très vieux langages. Ils n'ont pas de notion de module mais font d'include. Je ne connais pas de langages plus récent que l'Objective-C qui ai gardé des includes plutôt que des import.

https://insights.stackoverflow.com/survey/2018/#most-loved-dreaded-and-wanted

Je sais pas trop quelle valeur donner à ce genre de trucs. Aimer ? Genre ils ont entendu parler et ils pensent que c'est cool ou bien ? Vu les valeurs j'ai l'impression que c'est ça (clojure 59.6, julia 52.8, R 49.4,…). Je vois vraiment pas comment comparer bash à 59.4 qui est un langage que je présume les gens ont voté en affirmant qu'ils maîtrisent le langage et Rust à 78.9 où les gens on probablement voté par hype.

Bref, initialement je réagissais simplement à l'utilisation de l'adjectif "tardif" pour qualifier l'apport de RMS, mais savoir qui est le 1er, le 2ème, ou le 3ème … ne présente aucun intérêt à mes yeux.

Qui était en réponse à :

Le mouvement du Logiciel Libre est né de Stallman, […]

Bref, initialement je réagissais simplement à l'utilisation de l'adjectif "tardif" pour qualifier l'apport de RMS, mais savoir qui est le 1er, le 2ème, ou le 3ème … ne présente aucun intérêt à mes yeux.

Ben c'est surtout qu'initialement, il était question de parler de rms comme de celui qui a engendré le mouvement. Tout comme il est question de voir le logiciel libre à travers les yeux de la fsf. La fsf et rms ont grandement contribué au libre comme d'autres acteurs tel que les communautés bsd, l'OSI, Linus, etc. La volonté d'en faire ressortir un et de le présenter comme plus que les autres est un affront fait aux autres. La fsf tente particulièrement de politiser les choses et pour cela crée des bons et des mauvais là où d'autres ne font que partager. Quand je vois rms cacher encore récemment sur les autres (https://www.developpez.com/actu/231162/Richard-Stallman-l-open-source-est-un-substitut-amoral-et-depolitise-du-mouvement-du-logiciel-libre-qui-n-ose-pas-defendre-la-liberte/), c'est sincèrement écœurant. Tout ça pour une lutte de pouvoir futile… Donc oui la fsf et rms en tête font ce qu'ils peuvent pour se mettre en avant en espérant que ça les aidera à peser en tant que lobby, mais c'est pas en dénigrant le reste des acteurs qu'ils vont se faire des amis

Si tu regarde dans le détails (bref si tu t'y intéresse au lieu d'essayer d'invalider des arguments) et que tu suis les liens.

• GPL v1 : 25 février 1989
• MIT : 1988
• BSD : 1988
• LaTeX Project Public License : c'est un peu plus compliqué, mais c'est dérivé de la licence de TeX qui existe depuis le début des années 80's

Bref, la GPL n'est pas la première licence et il existait même au moins la licence de TeX qui est libre et qui est antérieur à la FSF. La FSF fait un gros travaille pour se donner de l'importance, mais il ne faudrait pas déformer l'histoire.

Ça c'est de l'imagination. Est-ce que ça a un impact sensible ? En lisant vite fait le code shell, il me semble que les parties les plus coûteuses (celles qui manipulent les objets git) sont déjà écrites en C. Je ne suis pas sûr que le coût des fork/exec et des io (il y a pleins de redirections) soit significatif. C'est pour ça que j'ai posé ma première question.

Ok donc le gain est surtout pour la portabilité je présume

Revenons sur les nouveautés de la version 2.20.0. En particulier sur git rebase, qui est maintenant complètement (ou presque) réécrit en C (bien qu'il soit toujours possible d'utiliser l'ancienne version en configurant rebase.useBuiltin à false).

Comment c'était avant ? Est-ce que c'est uniquement une histoire de performance ? Pourquoi vouloir le désactiver (uniquement pour d'éventuelles régressions ?) ? Si ce n'est qu'une question de performance comment c'était avant quel gain on peut attendre (dès quelques commits ou bien uniquement sur des historiques immenses) ?

C'est quoi un langage de programmation éthique ?

Est-ce que l'objectif est de défendre Git coûte que coûte, ou de comprendre mes arguments ? Dans le doute, je vais faire comme si c'était de comprendre mon argument.

Sacré procès d'intention. Je suis pas fan de git, je préfère hg et surtout je trouve que l'hégémonie de git est un vrai problème (il rend l'arrivé de nouveaux comme pijul ou fossil par exemple).

C'est un peu plus qu'une bonne pratique, c'est la seule solution pour faire commuter des patchs indépendants, et le seul avantage de Git sur SVN (un gros avantage, on est d'accord). La commutation du travail est la principale intuition derrière le contrôle de versions distribué, c'est le truc que les algos de merge de Git essaient de simuler.

Je ne sais pas ce que tu entends par « commuter ».

Dans Pijul, une branche a un historique linéaire et un ensemble de patchs.

Qu'est-ce que tu entends par historique ? De ce que je comprends il n'y a pas de relation d'ordre entre les patchs pijul, donc je vois pas ce qui est linéaire.

Pour trouver une erreur, j'imagine que tu fais référence à git bisect. C'est carrémment possible dans Pijul, même si on ne l'a pas encore implémenté, et on peut même isoler des ensembles de patchs bien plus finement que dans Git.

Oui et non, je n'ai pas donné le nom d'un outil parce que c'est pas simplement ça. Juste si tu veut comprendre l'historique pouvoir dans ta tête le suivre linéairement aide beaucoup.

Mais au moins, Pijul ne le rend pas plus dur que la vraie vie en introduisant des sources d'erreurs techniques.

Je n'ai pas la sensation que git augmente cette difficulté, mais j'avoue n'avoir rien qui me permettent de l'affirmer.

Mais là, c'est plutôt A(BC) == (AB)C. Et c'est décidable si A, B et C sont des patchs produits par Pijul, puisque c'est toujours le cas (une machine de Turing qui voudrait le décider s'arrêterait tout de suite sans regarder les patchs, et répondrait "oui").

Je pense que j'ai du mal avec ça. Il faudrait que je touche un peu avec pour que ça fasse réellement sens pour moi. Je comprends ce que tu veux dire, mais je vois pas comment ça fonctionne.

J'essaierais de prendre le temps de jouer avec parce qu'il y a trop de choses qui restent abstraites pour moi.

Dans Pijul, les branches ne servent qu'à suivre plusieurs versions du projet en parallèle (branche stable et instable, par exemple, mais pas besoin de branches pour contribuer à un projet).

Du coup ça se passe comment ? Je clone le dépôt. Je fais un truc, mon patch est matérialisé comment ? Il est relié à quoi ?

Git ne te garanti rien du tout. Je suis qu'avoir un historique linéaire est plus compréhensible qu'un historique "asynchrone".

Pour tes remarques, je ne vois pas l'intérêt d'un tris par date. C'est l'ordre d'application qui est intéressant (à partir du moment où on veut un historique linéaire). Les identifiants incrémentaux de commit posent de gros problèmes, quand on réécrit l'historique, un identifiant change de commit. Il n'identifie pas un commit, il représente un index. Ça peut très bien s'ajouter dans un git log et tu peux nativement identifier tes commits par des index decrementaux. C'est pas un véritable problème au final.

Merci pour ton commentaire :)

Git oblige ses utilisateurs à forker (brancher) les dépôts alors qu'ils voudraient en réalité envoyer un patch pour faire avancer le projet. Cette différence, qui, je te l'accorde, paraît évidente après des années de Git, n'a rien de naturel. Et d'ailleurs, git log -p affiche un patch (des changements), pas un commit (une version) !

Hum… Non ? git t'oblige à avoir une copie de travail (clone), ensuite le fait de faire une branche c'est juste une bonne pratique. D'ailleurs c'est une vue de l'esprit, ce que tu fais c'est donner un nom à ta partie de travaille.

C'est pas une contrainte folle.

Git séquentialise tout. Si je veux combiner des changements depuis plusieurs branches librement, il faut que je choisisse un ordre, même si les commits ont été produits en même temps. Ça encore, ça n'a rien de naturel ! D'autant plus que comme Git n'a pas de vrai algo de merge, l'ordre que je choisis ne fera pas forcément la même chose, je ne verrai pas les mêmes conflits, et même sans conflits, parfois pas les mêmes fichiers !

Tu peux très bien te retrouver avec un historique non linéaire en git, mais tu va te faire mal. C'est pas de la faute de git. Comprendre un historique non linéaire est une plaie. Trouver une erreur dans une jungle de patch est à des magnitudes plus compliquées qu'avec un log linéaire. Merger plus de 2 fichiers est aussi bien plus compliqué, déjà qu'en merger 2 est casse gueule.

Le deuxième problème de Git est l'absence d'associativité des changements. Si je git commit A, puis que je git pull B et C en même temps, ça ne fait pas toujours la même chose que si je commit A, puis que je git pull B, puis git pull C. Ça, c'est parce que l'algo de merge de Git est un algo d'optimisation que a parfois plusieurs solutions, auquel cas il en choisit une arbitrairement (sans même en avertir l'utilisateur). Et ça arrive même en l'absence de conflits.

C'est vraiment décidable d'avoir A(B(C())) == A(C(B())) ?

La réponse est purement technique, c'est parce que gérer des patchs, ça rend les changements asynchrones, et qu'on ne comprend pas grand chose à l'asynchronisme, en pratique comme en théorie.

Et qu'avoir un historique compréhensible c'est sacrément pratique pour maintenir ton logiciel ou pour l'auditer. Surtout que je ne vois pas la contrainte que cela pose. Éventuellement tu peux me parler du fait que ça contraint celui qui veux fusionner son code à faire en sorte qu'il fusionne correctement.

Et qui s'appliquent aux ressortissants de ceux-ci.

Tu peux mettre une passphrase forte, on te fera ouvrir ton téléphone. Si vous avez peur de l'État, vous inquiétez pas qu'il se débrouillera pour vous faire parler. De même votre voisin n'a probablement pas besoin d'une arme de seconde catégorie pour te faire donner ton mot de passe.

Sortir des scénarios de films d'actions parce qu'il existe des lanceurs d'alerte, ça n'est pas faire de la sécurité c'est de la masturbation intellectuelle. Les lanceurs d'alertes doivent se débrouiller pour que l'attaquant ne sache pas qui ils sont ou au moins ce qu'ils ont comme info. Au moment où ils sont démasqué, aucune sécurité informatique ne les protégera, ils faut qu'ils soient loin.

C'est vraiment FUD le reste.

Bin notre discussion portait sur le choix (ou non) de la forme async/await par rapport à la forme des promesses traditionnelles.

Mon commentaire parler du fait de partager des variable par rapport au fait de s'envoyer des messages.

Lorsqu'on choisit async/await, on a plus vraiment de fonctions, contrairement aux enchaînements de promesses, puisqu'on écrit la chaîne sous forme d'une suite d'instructions "pseudo-synchrones".

Je ne comprends pas. async, si j'en crois NDM, s'applique uniquement aux fonctions.

Mais en vrai ça ne change rien à mon propos. Si plusieurs fil d'exécution qui s’exécutent de manière asyncrhone accèdent aux même variables on est dans un état partagé, alors que si elles se transmettent des variables, on est dans du passage de message et on obtient pleins de propriétés cool. Tu gagne déjà une bonne partie de ces propriétés si tu fais « comme si ».

C'est suffisamment clair qu'il s'agit d'une question qui ne dépend pas de la syntaxe que tu utilise ?

Sauf erreur de ma part ton code est totalement synchrone… Comme l'objectif était de présenter les API asynchrones ça marche moins bien.

Je trouve cette condition horrible à lire :

if expected, actual := http.StatusOK, res.StatusCode; expected != actual {}

Bref, qu'en pensez vous ?

Beaucoup trop de pub pour un petit bout de code :)

Bien sûr que tu n'a pas un langage pur, ce n'est pas le question. Tu as des pratiques qui poussent à écrire des fonctions pures, même si ce n'est pas obligatoire. https://linuxfr.org/users/barmic/journaux/adopter-un-style-de-programmation-fonctionnel

Je n'ai pas compris le rapport avec async/await par contre ?

C'est un changement qui peut paraître anodin, voir juste une contrainte, mais c'est bien plus que ça. Tu passe de l'utilisation d'une mémoire partagée à un passage de message entre tes traitements. Ça change pas mal de propriété de ton code (possibilité d'écrire des fonctions pures, robustesse au modèle d'exécution, etc). C'est pour ça qu'à titre perso, je trouve que la petite gène vaut largement les gains.

    public static void searchTotoz(String query) {
        HttpClient client = HttpClient.newHttpClient();
        HttpRequest request = HttpRequest.newBuilder()
                .uri(URI.create("https://totoz.eu/search.xml?terms=" + query))
                .build();

        client.sendAsync(request, HttpResponse.BodyHandlers.ofString())
                .thenApply(HttpResponse::body)
                .thenApply(SmokeTestsApplication::extract)
                .thenAccept(System.out::println)
                .join();
    }

    public static Collection<String> extractNames(String body) {
        try {
            DocumentBuilder builder = DocumentBuilderFactory.newInstance().newDocumentBuilder();
            Document document = builder.parse(new ByteArrayInputStream(body.getBytes()));

            XPath xpath = XPathFactory.newInstance().newXPath();
            String expression = "/totozes/totoz/name/text()";

            XPathNodes nodes = xpath.evaluateExpression(expression, document, XPathNodes.class);
            return StreamSupport.stream(nodes.spliterator(), false).map(Node::getNodeValue).collect(Collectors.toList());
        } catch (Exception e) {
            throw new RuntimeException(e);
        }
    }

Complètement à l'arrache, mais c'était l'occasion d'utiliser le nouveau client http de Java 11. C'est assez verbeux (oui c'est java) et la gestion d'erreur est pourrie.

Mais tout dépend de ton besoin[…]

Non tout ne dépend pas de ton besoin. modulo c'est une opération mathématiques clairement définie, pas un desiderata utilisateur. JS s'invente des mathématiques non conventionnelles et joue avec. Si ça fait plaisir à certains très bien, mais il ne faut pas faire comme si ce n'était pas une étrangeté.

Alors oui, un bon développeur JS doit réapprendre une arithmétique. Si ça lui fait plaisir tant mieux. Mais es tu vraiment incapable d'admettre que remettre en cause l'arithmétique standard que tu as appris pendant 20 ans (et qui est issu d'un consensus sur plusieurs siècles), laisse une grande place à l'erreur d'utilisation ?

Le commentaire de Baud est très pertinent¹, si tu commence à imaginer que "12" est paire voir "12.3" qu'en est-il de "12,3" ou "12 300" ? Ça dépende de la locale ? Tenter de trouver une explication à toutes ces choses c'est redéfinir une arithmétique. Vouloir le faire n'a rien d'intéressant. Pourquoi js en aurait besoin là où tu as tant de langage qui n'en ont pas besoin ? Surtout que l'on parle du langage, ça n'empêche pas de faire une arithmétique loufoque dans une bibliothèque.

Note que JS n'est pas le seul dans ce cas là PHP sait faire aussi.

Ça dépend vraiment de ce dont tu as besoin.

On est entrain de parler de comment savoir si on a une variable est paire ou non.

Pour faire ça tu as le choix entre :

• les langages qui refusent d'exécuter un code qui n'a pas de sens mathématiques (ce qui n'a pas de sens mathématiques n'a pas de sens dans ces langages)
• les langages qui passent en erreur si tu leur demande quelque chose qui n'a pas de sens mathématiques (ce qui n'a pas de sens mathématiques est une erreur dans ces langages)
• les langages qui n'ont pas compris ton code mais qui tentent d'y répondre (« attends-tu veux savoir si c'est une représentation d'un entier impair ou s'il s'agit d'un entier impaire ? »)

On est pas entrain de parler de choses métiers complexes, mais de faire des opérations mathématiques donc d'exécuter du code qui a une définition formelle accepté par tous. Je comprends tout à fait que le typage de js peut être avantageux, mais le fait de ne pas avoir de définition simple et accepté par tous de propriétés mathématiques triviales me semble représentatif d'un problème tu ne pense pas ?

C'est pas compatible http 2 ni http 3 par exemple.

Les connecteurs que tu présente utilisent websocket ou du long polling. Mercure remplacé websocket avec à minima l'intérêt de fonctionner en http 2 et 3.

Donc on pourrait voir apparaître des connecteurs mercure pour activemq ou rabbitmq, c'est juste pas les même couches réseau.