anaseto a écrit 2229 commentaires

Outre le cas de gestion des erreurs en renvoyant un type somme, il me semble étrange qu'un langage moderne ne dispose pas de types sommes. Cela ne rend pas le système de type plus complexe, ni plus dur à implémenter.

Pour ce qui est des types somme en soi, ce n'est effectivement pas compliqué à implémenter : en fait, les interfaces de Go (qui sont des valeurs) peuvent être (et au besoin sont) utilisées exactement comme les types somme à l'aide d'un type switch (le cas courant de l'énumération se fait d'habitude avec des constantes). La seule différence, c'est que le nombre de types qui peuvent implémenter une interface n'est pas limité, contrairement aux types somme, ce qui veut dire qu'on ne peut pas faire de vérification d'exhaustivité. Une façon d'implémenter les type somme en Go sans introduire un concept trop différent, ce serait une façon de spécifier une liste fixe de types implémentant une interface explicitement (les interfaces sont implémentées implicitement autrement). Pour le moment, on dirait qu'ils n'ont pas considéré le bénéfice (check d'exhaustivité) suffisant pour introduire un nouveau concept, même s'il n'y a pas non plus d'opposition claire.

D'ailleurs, pour reprendre une partie de ton journal, c'était moins lourd de travailler avec des exceptions que des type option ou result.

Pour le coup, les exceptions peuvent conduire à du code concis, oui, sauf que c'est la méthode la moins explicite, invisible dans les signatures de fonction en OCaml, et offrant les bugs les plus inattendus.

Heureusement, depuis un an, on peut écrire un code moins abscons et plus proche de la version avec exception, mais c'est très récent.

J'ai pas vu passer ça ! J'imagine que c'est une extension ppx, ou alors directement intégré dans le langage ? Est-ce que ça couvre le cas des erreurs, idéalement avec une façon permettant de l'annoter ?

N'ayant jamais utiliser Rust, on doit s'y prendre comment pour travailler dans une telle monade

En Rust, ils se sont contentés de sucre syntaxique à l'aide d'une macro ? spécifique au cas du type option pour une erreur (type Result). C'est possiblement un bon compromis, surtout qu'ils ont fait l'effort de trouver une solution pour les annotations simples d'erreur (implémenter un trait de contexte pour Result).

Go exige d'utiliser une variable définie au moins une fois : ça implique la solution que tu proposes, au détail près qu'il n'y a pas de garantie qu'on n'utilise pas malgré tout la valeur retournée par la suite.

Ce n'est pas évident d'imposer mieux au niveau du langage. En Go les erreurs sont juste une valeur comme les autres, elles ne sont pas traités spécialement par le compilateur ou le langage : il s'agit juste de conventions et d'une interface error prédéfinie au même titre que d'autres types prédéfinis (comme int).

La façon classique d'empêcher à 99% (à unwrap ou exception près) d'utiliser une valeur retournée malgré une erreur, c'est les types option et filtrage par motifs qu'on trouve dans les langages avec des types algébriques (OCaml, Rust, etc.).

En Go, on a l'obligation d'utiliser au moins une fois err et, ensuite, on peut chercher plus de garanties avec des analyses statiques heuristiques (comme errcheck), indépendantes du langage avec risque de faux positifs et négatifs. En pratique, d'après l'institut de statistiques pifométriques, ça empêche uniquement 98% des problèmes (contre 99% avec OCaml ou Rust), mais permet en échange de conserver un typage simple et de ne pas forcer une imbrication du flot de contrôle. Ce n'est pas un problème facile : en cas d'erreurs imbriquées, l'approche des types option et filtrage par motifs demande, soit du sucre syntaxique ad hoc comme en Rust ou Elixir (comme ? ou with qui encouragent à traiter uniquement le chemin où tout se passe bien), soit des concepts avancés comme les monades en Haskell ou des réimplémentions ad hoc de celles-ci. Autrement, ça peut devenir difficile à lire et maladroit.

C'est toute la question des avantages et désavantages entre algorithmes de recherche de solution approchée (souvent plus simples et plus rapides au prix de ne pas offrir de garantie absolue) et algorithmes de recherche de solution exacte (plus lents et conduisent souvent à plus de complexité).

Ceci dit, avec les deux approches, rien ne garantie, par contre, que l'erreur est gérée proprement (d'un point de vue sémantique), ce qui arrive plus souvent en pratique et est un problème bien plus difficile qui ne peut être traité par les types que dans les langages avec types dépendants comme Coq.

Common Lisp est un langage multi-paradigme, pas purement fonctionnel donc, compilé et fortement typé

Oui, ils ne sont pas purement fonctionnels (OCaml non plus, ni même vraiment Haskell). Par contre même si le typage est fort, ils sont, de base, typés très dynamiquement (il est possible d'écrire des expressions, autres que des casts, qui vont produire une erreur de typage à l'exécution, ou changer impérativement le type d'une variable, par exemple). La notion de typage fort n'est d'ailleurs pas bien définie, j'imagine qu'ici ce que tu veux dire c'est l'absence de conversions implicites et autres caractéristiques de typage laxistes (qu'on peut retrouver dans C qui lui est statiquement typé, mais faiblement), ou peut-être la possibilité d'écrire certaines déclarations optionnelles de types (mais qui, en général, ne sont pas toujours validées statiquement).

Il existe aussi typed-racket.

C'est pour cela que j'avais précisé « par défaut », car, effectivement, à l'aide des macros on peut construire, a posteriori, du typage statique (comme pour typed-racket). Mais je suis content que tu le mentionnes, car construire un système de typage avec des macros, c'est quand même une chose impressionnante et qui mérite d'être connue !

Car Common Lisp permet de déclarer ses types un peu partout, quand on veut. On peut vraiment partir à la chasse à l'optimisation.

Oui, sauf que pour le coup, même si SBCL fait un peu d'inférence, elle n'est pas complète ni garantie, ce qui veut dire qu'il faut choisir un degré de safety pour les déclarations (safety 0) si on veut optimiser agressivement : on risque alors de ne pas être type safe. À utiliser avec modération :-)

Je suppose que tu voulais dire "un peu plus impératif" !

Oups, oui, bien sûr !

Concernant Quicklisp et les bibliothèques, je suis allé un peu vite et mon impression est peut-être faussée, ça fait longtemps que j'ai pas plongé dedans.

C'est une bonne question. Je dois dire que je ne pense pas avoir appris la plupart de ces termes dans un livre ou ressource unique. La plupart du temps, c'est en lisant des articles de blog de la communauté d'un langage spécifique qu'on découvre les termes (en sachant que, parfois, d'un langage à un autre, les termes peuvent avoir des sens un peu différents, comme pour les traits ou interfaces). Souvent l'article n'explique pas le terme, donc on cherche sur wikipédia, ou on tombe sur stackoverflow ou ailleurs.

Le wikipédia anglais est vraiment pas mal pour ce genre de choses, par exemple, pour le typage on va facilement trouver des liens vers tous les termes typiques (typage dépendant, graduel, dynamique ou statique, fort ou faible, inféré etc.). Par exemple, un système de typage est dit expressif s'il permet de décrire des pratiques, contraintes et structures complexes ; c'est un terme un peu vague. En particulier, un typage expressif permet d'écrire plus de programmes de façon type safe, ce qui veut dire en pratique en détectant plus d'erreurs à la compilation.

L'absence de GC n'est pas la seule raison d'essayer (et de préférer) Rust.

Tout à fait, ce que je voulais dire, c'est que ce serait une raison qui me donnerait la motivation additionnelle pour me lancer sans hésitation.

(result, nil), (result, err), (nil, err), (nill, nil). Et si les cas 2 et 4 semble improbables et inutiles, il n'y a pas besoin de chercher très loin dans la doc de la lib standard pour trouver des exemples (read par exemple, qui peut retourner des données et un EOF).

Pour le quatrième, j'ai pas de souvenir d'avoir eu à gérer ça ?

Autrement, il y a pas mal d'outils d'analyse statiques (en plus de go vet) pour Go qui peuvent aider (comme errcheck).

Ce journal est une invitation à venir critiquer en disant : "mais non t'as rien compris, ce langage est beaucoup plus riche que ce que tu as pu tester, la preuve …" mais comme certains le feront mieux que moi, je m'en vais relire la petite BD de Boulet pendant ce temps.

Héhé, peut-être bien :-) Le côté que j'aime bien, c'est qu'on découvre que certaines features sont super importantes pour certains, secondaires pour d'autres, voire pas rentables. Parfois, ça donne des pistes sur le type d'utilisation qui est donnée au langage, ou le background du programmeur. D'autres fois, ça nous montre juste à quel point le ressenti est individuel et l'importance des goûts et sentiments en programmation : se sentir à l'aise et épris d'affection avec un langage, indépendamment de l'objectivité statistique du sentiment, c'est important si on va passer beaucoup d'heures avec.

Sinon qu'est-ce qui t'attire dans le fait de tester différents langages comme ça ? Je suppose qu'en prenant le temps de te familiariser avec l'environnement, installer une chaîne de compilation, découvrir les librairies,, voir comment tout ça s'articule ça doit te demander pas mal de temps ?

Les langages de programmation, c'était un de mes passe-temps pendant quelques années. Tout comme toi avec APL, j'avais une sorte de fascination sur les différentes idées qui pouvaient exister pour représenter un programme. Et puis j'aimais tester suffisamment pour ressentir personnellement le truc, découvrir l'effort cognitif que le langage me demande, l'impact des différentes idées sur ma façon de programmer, découvrir la communauté, les outils, tout en jouant le jeu : essayer d'écrire du code idiomatique, ne pas fuir les exceptions ou les modules/foncteurs en OCaml, ni les monades/type class/foncteurs en Haskell, profiter des effets de bord et de la syntaxe flexible en Perl, programmer de façon fonctionnelle et tacite en J, ne pas fuir les macros en Tcl ou Lisp, ne pas essayer d'implémenter les monades en Go, ce genre de choses.

Ton journal m'a donné envie de découvrir J, je sais pas j'ai comme une sorte de fascination pour APL, il faudra un jour que je m'y mette.

Si tu aimes APL pour ses primitives (et que tu n'étais pas attaché à l'utilisation de symboles Unicode), tu devrais trouver effectivement ça intéressant : beaucoup de primitives sont des généralisations de celles d'APL, et le langage est, en général, plus fonctionnel (de quoi plaire à un OCamliste !), avec pas mal de fonctions d'ordre supérieur (qu'ils appellent adverbes et conjonctions) et la possibilité de définir les siennes facilement.

Et sinon, pour troller un peu, de mon côté j'aime beaucoup OCaml. Le langage me permet de mettre tellement de contraintes dans mon code, qu'au moment où il compile enfin j'ai l'impression d'avoir traversé l'Amazonie avec mon briquet et mon couteau.

C'est un bon exemple de ce que je dis plus haut : bien qu'on n'évalue pas précisément le temps que nous sauve la richesse extra des types en OCaml par rapport, par exemple, à Go, en fonction de comment on ressent le fait de devoir débugger un nil raté de temps en temps ou un switch non exhaustif, on va soit trouver ça génial (j'étais comme toi ici à une époque), soit être assez indifférent (je suis proche d'ici maintenant), voire trouver ça pas rentable (par exemple quelqu'un pour qui réussir à compiler du OCaml est pénible, à cause des messages d'erreur un peu difficiles).

D'ailleurs, je sais pas trop pourquoi mon ressenti sur nil ou le check d'exhaustivité des filtrages par motif a évolué. Peut-être que je fais moins d'erreurs maintenant ou que je programme des trucs différents qu'avant ?

Quel sorte d'application tu développes ?

Sinon, effectivement, Tcl est plus lent que Perl ou Python pour les trucs un peu intensifs.

C'est vrai, j'avais regardé à quoi ressemblait Elixir à un moment, sauf qu'à l'époque la programmation concurrente me disait pas grande chose, du coup je suis passé à côté.

s/0.06/1.5/ centièmes, erreur de calcul :-) Et ça, c'est sans compter qu'on porte dûment le masque avec bonne volonté.

Si tu te balades avec une maladie contagieuse pour laquelle il n’existe pas de traitement, tu peux causer la mort de dizaines, de centaines, de milliers… de personnes.

Jusque là, le patient zéro de la covid‐19 a causé la mort de 1,3 millions de personnes dans le monde.

À ce rythme là, tous nos ancêtres sont des criminels et j'espère que tu n'as jamais passé un rhume ou une grippe à quelqu'un, car tu continues peut-être à tuer des gens par effet papillon tous les ans.

Je trouve ce genre de culpabilisations extrêmes malsain : sans mesures, chaque personne contamine autour de 5 personnes (et encore, si tu habites en zone peu dense beaucoup moins), donc avec une mortalité d'autour de 0.3%, chaque personne tue en moyenne 0.06 centièmes de personne dont l'espérance de vie est en moyenne quelque chose comme dix ans.

Et encore, on passe sur toutes les personnes qui s’en tirent avec des séquelles pulmonaires, cardiaques

Les accidents et les suicides provoquent aussi beaucoup de séquelles dont on n'entend jamais parler.

Ton argument, c'était l'age des victimes. J'ai tiqué sur cet argument, que je trouve dégueulasse, pas sur le reste.

Pour toi, le décès d'un enfant ou d'un jeune parent est équivalent au décès d'une personne très âgée ? Pour moi, c'est comparer une tragédie terrible, qui s'accompagne de forts traumatismes et lourdes de conséquences pour la société (qui paye les retraites et la Santé ?) à un évènement triste mais auquel on se préparait déjà mentalement.

le traitement des addictions

La situation actuelle avec l'alcool, c'est que l'État, grâce aux taxes, fait de l'argent avec la santé des gens, ce qui n'est pas cool.

Les suicides, tu as raison, l'interdire va sûrement les arrêter, pourquoi n'y avons nous pas pensé plus tôt ?

Même s'il s'agit d'un sujet tabou très peu traité officiellement (impossible de trouver grand chose sur le site de l'insee, par exemple), on sait quand même des choses : l'endettement, l'isolement et la solitude sont des contributeurs majeurs et pas de mesures drastiques pour lutter contre ceux-ci.

Il y a d'autres contributeurs que la malveillance pure ou la maladress/incompétence, comme le désintérêt, le manque de sérieux, se sentir à l'abri de tout reproche, faire ce qu'on te dit sans réfléchir, avoir une perspective déconnectée de la réalité, etc.

Je te retourne la question : pourquoi ces phénomènes (accidents, suicides), qui se répètent en plus tous les ans, ne mériteraient-ils pas aussi des mesures drastiques ?

J'ai l'impression que tu mets sur le même pied la mortalité quel que soit l'âge ou la situation. La mortalité, c'est un indicateur, il ne prend pas en compte toute l'information : les piscines tuent annuellement plus d'enfants que le covid, et les suicides et les accidents de la route tuent plus de jeunes ou jeunes parents.

J'ai beau rappeler qu'il est inutile d'attribuer à la malveillance ce que la maladresse et l'incompétence peut expliquer je vois des théories plus alambiquées chaque jour sortir autour de moi.

Le problème d'essayer de réfuter une théorie alambiquée en mettant en avant la maladresse, c'est que tu peux être interprété comme voulant faire passer le politicien pour quelqu'un qui veut bien faire, mais n'y arrive pas parce que son métier est trop dur. En cas de répétition, ça peut être perçu comme une défense de l'élève qui oublie toujours de faire ses devoirs ou qui a un réveil qui ne marche jamais. Il n'y a pas que la maladresse d'une part, et les théories alambiquées d'une autre : dans le cas de l'élève, il est peut-être maladroit ou fainéant, ou bien il subit des problèmes sociaux, ou il n'est pas intéressé par le cours, ou un peu de tout, etc.

Le cerveau aime attribuer les faits à une cause unique, que ce soit une théorie alambiquée ou un mot-clé comme l'incompétence. Réfuter une croyance de cause unique (théorie alambiquée) avec une autre croyance de cause unique (maladresse) ne fait que renforcer leur croyance qu'il est normal de vouloir chercher une cause unique et, réaction humaine, ça renforce leur croyance dans leur cause unique plutôt que la tienne.

Plus le nombre d'explications et facteurs contributeurs considérés est grand, plus c'est difficile de se retrancher dans une seule explication rocambolesque.

Mais on ne peut pas mettre les chiffres de la mortalité ou de la contagion sur le dos des mesures gouvernementales uniquement.

En effet, en France on a eu grosso-modo les mêmes mesures partout, avec des résultats très variables pour la première vague suivant les régions (insee), allant de la vague haute avec 2x ou 3x fois le nombre de décès normaux (île de France) à la mer en calme (Nouvelle Aquitaine).

L'idée ce n'est pas d'imputer le résultat aux mesures, mais plutôt de savoir à quel point les mesures qui ont des effets secondaires sur l'économie et les libertés ont contribué. Même sans preuve de résultat, personne ou presque ne se plaindrait si l'État avait investi dans l'aération des lieux fermés denses, déplacé les personnes âgées en dehors des EPHADs vers des lieux moins à risque, ou encore fait une campagne médiatique pour embaucher des jeunes afin de faire les courses à la places des personnes âgées, leur évitant des lieux à risque. Suivant la nature des mesures, les gens ne demandent pas le même effort de transparence.

La Norvège a fait à peu près comme la Suède (aux écoles fermées près, je crois), sauf qu'avec de meilleurs résultats.

La méthode c'est important, mais les résultats aussi si on veut pouvoir en justifier une drastique.

Ouais, et j'oubliais : une loi interdisant de plonger dans la dette, surtout au-delà d'où on a pied ; du moins jusqu'à ce qu'on développe des branchies (ce qui résoudrait le problème des piscines aussi).

Je préfère le choix suédois.

Surtout qu'au final on va avoir en France des statistiques covid similaires, sauf qu'en deux vagues (enfin, à voir suivant les régions), dont une première très pointue, plutôt qu'une seule à forme aplatie.

Ben, je sais pas, j'imagine que ce serait possible d'utiliser un framapad ou quelque chose du style. Ceci dit, faut voir déjà ici si ça se prête vraiment à une écriture collaborative, sur ce genre de sujets où même les questions peuvent apparaître comme subjectives, c'est pas évident :-)

Et puis, qu'en faire après de toutes façons ?

Pour faire un parallèle plus réaliste, je proposerais :

• Le confinement des voitures non essentielles jusqu'à ce qu'un vaccin contre les accidents et la pollution soit prêt.
• L'alcool disponible uniquement en pharmacie, avec prescription d'un médecin obligatoire, sans taxes.
• Interdiction des piscines, en particulier les privées (source majeure de décès chez les enfants).
• Une loi interdisant aux personnes âgées de vivre seules (source d'accidents graves détectés trop tard).
• Une loi confinant les politiques, les médias et la diffusion de pensées négatives en général pour lutter contre les suicides.

Quelques autres questions :

• Avez-vous investi dans l'aération des lieux fermés denses ?
• Quelles sont vos conclusions relatives aux urbanisations denses ? les EPHAD ?
• Qu'est-ce qui a empêché d'avoir une vague plus aplatie (ou pas de vague) dans certaines régions et pas d'autres ?
• Quel est votre retour sur l'utilité des tests massifs en période de circulation généralisée du virus ?
• Est-ce que les conséquences économiques vont impacter à long terme le service public, en particulier la Santé ? les retraites ?
• Est-on proche de l'immunité de groupe chez les personnes utilisant les transports publics denses ? dans les écoles ?
• Avez-vous évalué les effets de rendre les mesures obligatoires plutôt qu'utiliser des recommandations ?
• Est-ce que les mesures obligatoires sont rentables dans toutes les régions ?
• Avez-vous étudié les effets psychologiques des mesures et de la médiatisation ?
• Le stress permettrait-il de mieux résister à la maladie ? (c'est une blague celle-ci :-)

Combien de contaminations dans la rue ?

Ça fait un peu doublon avec la question précédente sur les contaminations à l'extérieur.

Je pense que ton disclaimer de l'avant dernière phrase, c'est mieux de ne pas le mettre, ça risque de détourner sur d'autres problématiques avec du vocabulaire guerrier. D'ailleurs, peut-être qu'il faudrait utiliser moins l'impératif et moins d'accusations ici et là : j'ai beau ressentir tout ça comme toi, ces parties ont le plus de chances de faire réagir négativement un lecteur. Formuler sous forme de questions pour faire réfléchir, c'est surtout ça qui est bien dans ton idée, je trouve.

Même pas : il n'y aura pas de wildcards dans les paramètres en Go ! Ni de type erasure :-)

Le draft qui décrit le truc est intéressant. Perso, je trouve qu'ils ont bien fait de prendre leur temps pour trouver un design unique vraiment adapté à Go : pour les pressés il y a l'embarras du choix en langages avec cette feature déjà. J'aurais trouvé ça décevant s'ils avaient implémenté direct un des premiers drafts qui collaient pas vraiment au langage juste pour faire comme les autres.

Je trouve les idées du jeu sympa : ça me rappelle certains roguelikes de survie, mais avec un mixte temps réel/tour par tour pour permettre le jeu multi-joueur tout en évitant de transformer ça en jeu de réflexes. C'est inspiré de ces jeux, ou c'est une coïncidence ? Les graphismes et le fait d'utiliser des conventions ascii pour définir les cartes rappellent aussi beaucoup les roguelikes.

Par contre, j'ai pas réussi à compiler sous OpenBSD : la dépendance openssl-sys ne gère pas encore les dernières versions libressl, donc je vais devoir attendre pour tester. Faut dire qu'avec les projets rust, qui ont tendance à avoir énormément de petites dépendances, j'en ai souvent une qui pose problème :-(

Je pense que le sens des termes dépend beaucoup d'où on les utilise : sur linuxfr le mot « libre » est en général interprété dans un sens assez spécifique (licence libre) donc faut faire attention et être précis avec ce mot ici, je suis bien d'accord. Mais sinon, les mots sont en général polysémiques, ambigus et vagues.

Par exemple, un « groupe libre » a un sens mathématique précis, mais en dehors d'un forum de mathématiques ce sera interprété de diverses façon suivant le contexte. Sur linuxfr on pourrait penser à un groupe qui fait de la musique sous licence libre, par exemple, et d'en d'autres contextes ça pourrait être interprété comme un groupe indépendant d'un pouvoir externe (genre les cités libres du moyen âge). Et même pour un film, en dehors de linuxfr, ça pourrait être interprété comme un film qui dénonce grave, voire aïe un film gratuit (en dehors de linuxfr la liberté d'avoir accès à la culture sans payer est plus populaire que celle de pouvoir modifier et redifuser les modifications).