gasche a écrit 1151 commentaires

Dans la discussion reddit, quelqu'un pose la question évidente quand on sait ce qu'est un type somme, et qui résoud les faux-problèmes mentionnés ici:

indil7: Why not model types like in Haskell, with sum/algebraic types and interfaces as just types, not values that can be inspected at runtime for the real type? Those are orthogonal ideas, and they reduce errors by keeping you from breaking the interface abstraction.

Réponse de Ian Lance Taylor, la personne qui dit qu'ils ont regardé pour les types sommes et que ça n'avait pas marché—et qui a écrit les propositions sur les génériques en Go:

ianlancetaylor: I'm sorry, I don't understand what that means in the context of the Go language as it exists today. It sounds like you are talking about a different language--like, say, Haskell. Apologies if I'm missing what you are saying.

Ian Lance Taylor est un auteur de compilateur, il a écrit le linker gold qui a été quelque temps en référence sur les performances, et c'est certainement un excellent ingénieur et implémenteur de langages. Mais cette réponse montre qu'il ne connaît rien aux systèmes de types, il n'a pas le niveau de ce qu'on enseigne à des étudiants en M1.

Personne ne peut tout connaître (même si une équipe qui travaille sur un gros langage pourrait faire l'effort d'embaucher des gens qui connaissent). Mais là, on voit que l'équipe Go tout entière a confié des choix importants sur le système de typage de Go à une personne qui n'y connaît rien. Et ça, encore, ça devrait être choquant—et ça montre aussi qu'on ne peut pas leur faire confiance à leur jugement quand ils disent "on a regardé ça mais c'est trop difficile donc on a choisi de ne pas le faire".

C'est un point mineur mais je reviens dessus : je ne suis pas d'accord avec le fait de dire que les type classes (classes de type) de Haskell ne sont "pas pour les débutants". Utiliser une type-class déjà définie est facile, définir une type-class ou déclarer une instance pour une type-class est aussi assez facile, il n'y a rien que j'aurais peur d'enseigner en première année. (C'est en particulier plus simple que l'héritage d'implémentation dans un langage objet.)

Les classes sur des types de sorte supérieure (higher-kinded) sont déjà un plus velues, mais c'est un usage avancé pour des concepts plus avancés. Il faudrait commencer par en montrer juste l'usage avec les cas particuliers de Functor et ensuite Monad, et ensuite seulement introduire l'intérêt de définir de nouvelles instances et enfin de nouvelles classes.

Je ne sais pas exactement à quelle difficulté tu pensais quand tu as écrit ça.

Cette issue pointe vers une discussion Reddit qui pointe vers la réponse "officielle" dans la FAQ (je cite Rob Pike: "The answer hasn't been touched in years, and is still accurate."): Why does Go not have variant types?.

La réponse contient en particulier :

We considered adding variant types to Go, but after discussion decided to leave them out because they overlap in confusing ways with interfaces. What would happen if the elements of a variant type were themselves interfaces?

Cette question (What would happen…) montre que les auteurs de cette réponse n'ont pas vraiment compris ce qu'était un type somme (somme disjointe), car il y a une réponse évidente à cette question quand on le sait : "bah rien, tout se passe bien".

C'est triste.

C'est un non-sens puisque les types sommes sont des sommes disjointes, donc on sait forcément d'où vient la donnée. Quand tu regardes le type A of int | B of int, les deux arguments sont de même type mais on ne se dit jamais "mince, je ne sais pas d'où je viens", puisqu'on a le constructeur pour faire la différence. Ce que discute cette partie de la PR ce sont des types d'union non-disjointe, qui sont beaucoup plus délicats à gérer en théorie et en pratique.

Et ça c'est une conséquence directe du modèle "pas besoin d'étudier le Related Work, les gens de notre communauté vont améliorer le langage avec des pull requests". Si tu commences par faire un langage qui dit merde à la recherche en typage, les gens de ta communauté seront pour la plupart des gens qui n'y connaissent pas grand chose et qui se forment sur le tas, donc les propositions auront plein de problèmes. Jusqu'au jour où tu seras "too big to fail", il y aura tellement d'utilisateur pour ton langage qu'un chercheur américain va se dire que ça fera classe sur son CV de dire "j'ai aidé les concepteurs de Go à implémenter les types sommes", et peut-être qu'un truc va marcher (ou alors tu tombes sur un hobbyiste éclairé, comme l'est Graydon Hoare par exemple, qui te fait une proposition nickel; ça arrive aussi et tant mieux).

Mais pourtant on te l'a expliqué que les développeurs de Go, sur cet aspect, connaissait ce que tu énonçais mais l'ont ignoré pour certaines raisons. Tu peux dire ce que tu veux, mais ils ont fait un choix, un compromis et c'est nécessaire d'en faire sur certains sujets.

Il y a des choix qui sont suffisamment motivés pour être justifiables, il y a des choix qui sont des fautes.

Je ne devrais pas avoir besoin de me justifier sur l'idée suivante : si on est payé pour construire un langage de programmation qui a vocation à être adopté largement, il est naturel et important de se renseigner un peu auprès de gens qui étudient scientifiquement ce domaine. C'est assez facile, c'est gratuit, il suffit de contacter des personnes connues dans la communauté de recherche (ou les bonnes mailing-list) et d'espérer être redirigé vers des personnes intéressées par une discussion ou une collaboration. C'est une faute de ne pas le faire !

Si quelqu'un décidait d'écrire un projet de loi important sans consulter un juriste, de construire bâtiment public important sans contacter un architecte ou un spécialiste de l'accessibilité au handicap, on trouverait ça choquant.

Si on pense que la recherche en langages de programmation ne sert à rien, il faut le dire clairement et on en discute. (Par exemple, j'ai expliqué dans mon document qu'il y a beaucoup d'autres domaines qui pourraient avoir des apports intéressants, un angle de critique serait de dire que ces domaines seraient plus importants et ne sont pas assez explorés.) Mais vous ne pouvez pas dire à la fois "oui, on est convaincu que c'est utile" et "ah mais les créateurs de Go n'en avaient rien à battre, mais il ne faut pas leur en vouloir, tout le monde fait des choix". Quand on se lance dans un projet lourd sur de nombreuses années, et qu'on ne consulte pas une communauté de gens dont les idées sont importantes et utiles pour le projet, on a merdé, pourquoi est-ce si difficile de reconnaître cette évidence ?

Honnêtement, je ne suis toujours pas convaincu que c'est un manque aussi important que tu l'énonces.

C'est peut-être aussi parce que tu n'as pas l'habitude d'utiliser cette fonctionnalité, parce que les langages que tu utilises le plus souvent ne l'ont toujours pas. Les connaissances de la communauté de programmation évoluent très lentement, l'inertie est forte, donc ça bouge lentement. Mais une fois qu'on a découvert, on peut difficilement s'en passer ! Avec Rust et Swift qui ont des types sommes, il y a de plus en plus de gens qui vont découvrir et bientôt ça paraîtra une évidence qu'il faut en avoir dans un langage (comme les fonctions anonymes, les génériques (si le langage est typé), ou la sûreté mémoire par défaut). Go aurait pu être une occasion pour un nouveau public de découvrir, c'est une occasion manquée, c'est très dommage.

(Au passage: Swift est beaucoup plus intéressant que Go comme langage, alors qu'il a les même buts d'offrir une transition en douceur pour des développeurs dans un langage impératif existant (Objective-C). C'est pour beaucoup une question de culture — Chris Lattner est au courant du fait que la programmation fonctionnelle existe — et c'est sur ça qu'on peut influer avec un peu de bonne volonté de tous les côtés.)

En même temps les auteurs de Go font de la communication autour du fait que Go a été pensé pour écrire de très gros systèmes distribués à l'échelle Google… Et c'est pas faux (je suis sûr que pour certains projets Go est un meilleur choix que d'autres langages; on pourrait penser à Erlang/OTP, mais la courbe d'apprentissage est plus rude, etc.), le truc c'est qu'ils ont décidé que pour l'abstraction au niveau des types, avoir juste des séquences et des dictionnaires paramétrés suffirait sans doute à la plupart des usages.

Ce que tu dis est vrai mais s'applique à toutes les fonctionnalités d'un langage de programmation. C'est pareil pour les booléens (qui sont en fait un cas particulier de type somme), et pourtant on ne retire pas if/then/else du langage ! C'est pareil aussi pour les fonctions anonymes (les lambda-expressions), qui ont été apportées aux langages "mainstream" par des théoriciens, et qui sont maintenant très courantes parce qu'on se rend compte, à l'usage, que c'est bien pratique. (D'ailleurs elles existent aussi en Go, donc quelqu'un a fait le choix d'implémenter le truc, d'écrire la documentation, etc. etc.)

Je reste de l'avis que c'est une faute de ne pas l'implémenter. Le coût n'est pas si élevé, surtout si on les prend en compte dès la création du langage, et ça permet vraiment de mieux représenter les données que l'on manipule.

Si un constructeur de voiture ne se tient pas au courant des dernières pratiques de sûreté, et n'applique pas une idée (développée au départ par un concurrent) qui permet d'éviter certains accidents sans surcoût à la production (mais avec le coût de se former dessus, de modifier la chaîne de production, etc.), et qu'il y a des gens qui ont un accident, on peut légitimement dire que le constructeur n'a pas fait son boulot correctement.

Quand il y aura un bug qui fera exploser en vol le système d'administration, codé en Go, du cloud d'un gros fournisseur, l'impact (financier, humain, etc.) peut être énorme. Ce sera peut-être une erreur qui aurait été évitée facilement si le langage avait eu des types sommes. (L'erreur de validation SSL citée dans le document est tout à fait de cet ordre.) Et sans aller vers ce catastrophisme, les types sommes peuvent améliorer la vie des programmeurs tous les jours. (Tout comme le GC, les fonctions anonymes, l'inférence de types, etc.)

Je pense qu'on peut regretter le fait historique que Linux, en tant que projet communautaire de noyau libre, est parti sur un noyau monolithique plutôt qu'un micro-noyau—aujourd'hui le noyau est presque impossible à sécuriser (je parle de sortir du jeu du chat et de la souris des attaques/réponses en rendant toute les classes d'attaques courantes impossibles grâce à la conception du système), et les gens qui veulent un système sûr (Qubes OS par exemple) doivent repartir au niveau des hyperviseurs.

Mais il y a une différence importante, c'est que (1) à l'époque les micronoyaux étaient difficiles à rendre efficace (L4 a fait beaucoup de progrès depuis), et (2) tu parles d'un choix de design fondamental qui demande de complètement tout refaire.

J'ai dit que ne pas inclure les types sommes dans un langage de programmation typé conçu dans les années 2000, c'est une faute. Il ne s'agit pas de demander de tout changer au langage, ou de le transformer en une variante de Coq. C'est une fonctionnalité qui n'est pas copmliquée à expliquer ou implémenter, qui se mélange bien avec la plupart des autres traits du langage, et qui lui donne une meilleure capacité à modéliser les domaines métiers—et donc d'écrire du code plus clair. On n'est pas du tout au niveau du "il faut tout refaire avec un micro-noyau".

Tu parles de récrire des millions de lignes de code, mais au moment où Go a été conçu, il n'y avait aucune ligne déjà écrite dans ce langage (ou alors juste des exemples exploratoires).

Je crois que tu es passé à côté d'un aspect de mon article. Quand je dis qu'il faut faire le travail de formaliser les langages de programmation, je parle de formaliser tous les langages, y compris le C, le Go, le Basic, l'assembleur, le Java etc. Formaliser un langage révèle des irrégularités ou des manques à corriger (c'est pour cela qu'il faut essayer de le faire pendant la conception du langage, et pas seulement apres-coup quand on est mis devant le fait accompli), mais ne demande en aucun cas de le modifier de fond en comble, de lui ajouter des types dépendants et de le transformer en l'hybride monstrueux de Rust, Haskell, Coq et Mathematica !

En général la théorie cherche la solution la plus élégante. Sur le papier, la théorie peut toujours l'emporter sur l'approche pratique. Mais voilà, la pratique c'est aussi les contraintes de la vie : la formation, les outils, les projets existants, l'Histoire.

La formation, les outils, l'histoire, tout cela évolue avec le temps et on travaille tous dessus. C'est un ensemble de choix fait par des gens, et l'un des choix qui se propose c'est de réfléchir à l'apport de la théorie, d'écouter ce qu'elle a à dire et d'entrer en contact avec des gens qui en font. Ça n'est pas la seule chose importante pour obtenir un langage qui réussit, mais je ne pense pas m'aveugler en pensant (à partir d'exemples concrets nombreux) que quand on suit cette démarche, les résultats ne peuvent être que positifs.

C'est pour ça que c'est important pour moi d'expliquer le domaine, les choix faits par certaines communautés, et pourquoi/comment on a confiance en les résultats obtenus. Le but c'est que les gens comprennent l'intérêt de la recherche dans ce domaine au lieu d'avoir une vision un peu simpliste, ou tout simplement de l'ignorer complètement comme l'ont fait, par exemple (mais ils sont loin d'être les seuls), les créateurs de Go.

Je pense qu'on est d'accord sur Go : les vieux de C avaient envie de refaire un langage, ils l'ont adapté pour répondre aux problématiques de leur employeur (Google), et du coup on a obtenu un truc "comme C mais avec un modèle de concurrence raisonnable et avec GC parce que c'est plus pratique". C'est juste aussi de dire qu'ils n'ont visiblement pas vraiment pris le temps de regarder ce qui s'était fait dans les autres langages pour en reprendre les bonnes idées, et que ça se voit dans le langage.

Dire c'est laid pour rire, pourquoi pas, je le fais aussi, mais comme tu insistais pour dire que le Go c'est de la merde, le côté humoristique a disparu.

Je n'ai pas dit ça, je dis que les fonctionnalités du langage lui-même ne sont pas intéressantes (que ce qui fait l'intérêt du langage c'est les outils, le runtime et les bibliothèques) et qu'il ignore, dans sa conception, les résultats de la recherche en langages de programmation.

Mais la BNF ne suffit pas à définir le langage de programmation (même si elle suffit à définir l'objet programme), il faut aussi parler de la façon dont les programmes se comportent, du système de typage s'il existe, etc. Donc si tu veux on peut dire qu'on définit "la syntaxe des programmes du langage" d'abord, et ensuite le langage. Je préfère insister sur l'idée de voir un programme comme un objet mathématique, qui me semble est la clé pour comprendre cette approche scientifique, donc j'en parle en premier.

(Côté "maths usuelles" l'équivalent serait peut-être la définition des ensembles de nombres comme (semi-)anneaux. Tu peux définir, par exemple, l'ensemble support de Q comme un ensemble quotient, tout d'un coup, mais les opérations et les vérifications de leurs propriétés viennent ensuite.)

Je suis pas tellement d'accord avec ton point (2), en tout cas il faudrait développer. "C'est moche théoriquement donc on ne devrait pas faire comme ça" irait à l'encontre d'amélioration selon les dimensions que tu proposes si elles demandaient d'introduire des choses difficiles à formaliser dans le langage. Mais je ne pense pas que ce soit le cas, ou alors c'est très rare ! Au contraire, bien comprendre un langage de programmation (y compris grâce au processus de formalisation) permet souvent de le rendre plus clair, plus simple, de rendre ses implémentations plus correctes et plus efficaces. Je n'ai pas connaissance d'un point où une amélioration théorique irait dans l'autre sens, par contre j'ai connaissance de plusieurs points (par exemple : les tableaux modifiables covariants en Java, qui demandent un test de typage à chaque écriture dans un tableau) où faire une entorse au formalisme a aussi nuit à ces aspects que tu cites.

il me semble que tu prends la chose aussi un peu trop à cœur (ou du moins ta prose en donne l'impression) pour apparaître totalement objectif aussi

Oui, les discussions sur LinuxFR c'est toujours le flamewar automatique, désolé. En vrai je vis les choses assez posément. Je pense que les gens sont défensifs à cause des liens affectifs (et d'intérêt, comme je parlais plus haut) qu'on développe par rapport aux langages qu'on aime. C'est bien de travailler dans un domaine qui nous passionne tellement !

Merci pour le commentaire en tout cas, c'est bien d'avoir des retours de personnes avec du recul.

j'aimerais voir plus d'auto-critique sur certains langages

Ah, je passe mon temps à râler sur les défauts et les manques de OCaml, il suffit de demander (dans un message à toplevel par contre, pas perdu au milieu d'un troll sur Go). J'essaie d'améliorer les choses aussi.

Les lambda-calculs, ce n'est pas nouveau non plus, beaucoup de langages n'en ont pas.

Pas de fonctions anonymes / expressions lambda ? Python en a (mais seulement sur une ligne, oups), Javascript en a, C# en a, Java 8 en a, C++ en a, Go en a… À part C je pense qu'on commence à être au complet. (Bientôt l'inférence de types et les types somme.)

Le plus amusant, c'est qu'on avait eu un débat ici il y a quoi, 2 ans sur ce qui était acceptable en terme de communication, qu'il fallait éviter de froisser les gens. Tu semblais soutenir que c'était possible de parler entre adultes systématiquement sans jamais froisser quiconque tout en pouvant développer une culture communautaire saine. Alors, tu soutiens toujours le même point de vue ?

Bien sûr, je soutiens toujours ce point de vue. D'ailleurs si tu me disais "ah mais attends quand tu écris laid ça peut froisser des gens et faire monter la température inutilement", je serais assez d'accord et j'irais éditer mon message pour reformuler ça plus posément (ah mince, sur LinuxFR on ne peut pas éditer ses messages !). Tu as plutôt choisi de dire que j'étais super condescendant, je me suis mis sur la défensive et j'ai attaqué. Peut-être qu'on démontre ensemble que c'est difficile d'avoir une discussion calme sur LinuxFR, mais moi j'en ai tous les jours dans plein d'autres contextes donc je sais que c'est possible. Tu veux venir commenter sur Zeste de Savoir pour comparer ?

La première version de ce document a été écrit en 2011, 4 ans après la première sortie publique du langage. Quand on sait que les génériques et le sous-typage interagissent mal (ce que n'importe quel chercheur en typage sait dire si on lui envoie un mail pour lui poser la question), c'est clair qu'on ne peut pas juste dire "voici mon langage en l'étant, comment ajouter les génériques sans rien changer ?" (enfin, ça a presque marché pour Java), il vaut mieux le prendre en compte dès la conception pour envisager de changer d'autres aspects en parallèle. Se poser la question 4 ans après avoir posé les briques du langage, c'est déjà trop tard, ou en tout cas c'est rendre le problème plus difficile qu'il n'aurait pu l'être (par exemple, les créateurs de C# ont pensé aux génériques dès le début, y compris dans le design du bytecode .NET, et ça marche très bien).

Ensuite quand tu cherches tu vois que la question avait déjà été posée par des créateurs de Go en 2009 (donc déjà 2 ans après la première sortie publique, c'est déjà trop tard, mais passons). Et là tu vois que la façon dont ils font une recherche dans la littérature, c'est "je publie un billet de blog et je demande des références dans les commentaires". Un peu léger, comme façon d'interagir avec la communauté de recherche, non ? Je n'ai pas de chiffres très précis sur le nombre d'employés Google qui ont une thèse en langages de programmation, mais j'en connais un certain nombre, donc je sais que ça existe.

Alors oui, tu peux peut-être lire cette histoire en te disant : ils n'ont juste pas pensé à demander à des gens avec un bagage théorique de travailler sur des génériques dans Go avant sa sortie. C'est un peu bête.

Peut-être qu'on est en fait d'accord, mais qu'on s'exprime différemment.

Je ne dis pas qu'il faut se passer de théoriciens. Bien sûr qu'ils sont indispensables !

Indispensables, pourquoi ?

Mon point est que les positions à base de « c'est moche théoriquement, on ne devrait pas faire comme ça » sont, elles, problématiques.

Problématiques, pourquoi ?

Mouais, il y a peut-être aussi le fait que Ceylon est fait par un acteur (Red Hat) pas particulièrement reconnu par la communauté Java, alors que Kotlin est poussé par l'éditeur de l'IDE qu'une quantité non-négligeable des gens utilisent, ce qui lui donne directement beaucoup de visibilité et de facilité à être bien intégré aux environnements et outils de développement. (Après je n'ai jamais moi-même écrit de code en Ceylon donc je vais te faire confiance sur le ressenti. J'imagine que ça provient de choix de conception du langage assez indépendants de celui du système de typage.) Par ailleurs je ne veux pas dire que Ceylon est mieux que Kotlin ou quoi, juste qu'il se trouve que quelqu'un a travaillé sur le système de typage de Ceylon; on pourrait sans doute s'intéresser aussi à Kotlin si les concepteurs étaient intéressé par une collaboration.

Le Go a une cible très précise en tête, qui est en gros de remplacer le C tout en étant proche de lui pour la programmation système.

Tu t'inventes ta propre histoire de Go. Je t'invite à relire les mots d'un des créateurs dans l'article Go at Google: Language Design in the Service of Software Engineering (pointé par la FAQ go comme une réponse longue à la question "pourquoi ce projet de langage ?"):

The Go programming language was conceived in late 2007 as an answer to some of the problems we were seeing developing software infrastructure at Google. The computing landscape today is almost unrelated to the environment in which the languages being used, mostly C++, Java, and Python, had been created. The problems introduced by multicore processors, networked systems, massive computation clusters, and the web programming model were being worked around rather than addressed head-on. Moreover, the scale has changed: today's server programs comprise tens of millions of lines of code, are worked on by hundreds or even thousands of programmers, and are updated literally every day. To make matters worse, build times, even on large compilation clusters, have stretched to many minutes, even hours.

Go was designed and developed to make working in this environment more productive. Besides its better-known aspects such as built-in concurrency and garbage collection, Go's design considerations include rigorous dependency management, the adaptability of software architecture as systems grow, and robustness across the boundaries between components.

Tu notes que "remplacer le C" n'est pas mentionné du tout. Les langages mentionnés sont C++, Java et Python. (Bien sûr, aucun de ces langages n'avait de types sommes à l'époque où cet article avait été écrit, même si C++ est timidement en train d'en ajouter).

Le fait qu'il ne soit pas à l'état de l'art du domaine n'est pas le sujet.

Les types sommes ont été introduits par le langage Hope (dynamiquement typé) dans les années 70. Ils sont utilisés à moyenne échelle par les programmeurs ML et Haskell depuis les années 90. (Tous les étudiants qui ont fait l'option informatique une prépa MPSI dans les 20 dernières années en France les ont appris; une partie de ces étudiants travaillent d'ailleurs maintenant à Google.) Ce n'est pas exactement ce qu'on appelle "l'état de l'art".

Attends, je te cite, par exemple

j'ai tendance à préfèrer augmenter la quantité de beauté dans le monde qu'atténuer les souffrances des gens qui vivent dans le laid,

Tu ne trouves pas que de traiter tout ce qui ne répond pas à tes critères comme du laid ne soit pas méprisant ?

J'ai essayé de résumer une position particulière sur un sujet assez riche de façon simpliste — et un peu humoristique. Il me semble que c'est courant pour nous tous, quand on écrit du code, de dire (ou d'écrire) familièrement : ça c'est laid. (Ça ne t'arrive jamais ? C'est forcément, pour toi, un signe de mépris intolérable pour la personne qui a écrit le code, souvent soi-même ?)

déconsidérer des langages en se basant sur leur propreté mathématique ou leur rapport à la recherche

Attention, un langage peut être simple tout en ayant de bonnes propriétés mathématiques. Kotlin a une sémantique des bindings à peu près raisonnable (pas comme nonlocal en Python qui est cassé, ou Coffeescript, cf. ailleurs), on comprend bien la sémantique de l'héritage en Java (ça a été formalisé plusieurs fois selon l'approche de ma communauté), etc. Un autre exemple de Java-amélioré est Ceylon, un peu dans la même niche que Kotlin, et qui a été regardé de près par (le chercheur) Ross Tate qui a fait des choses intéressantes avec. Avoir une sémantique formelle pour un langage de programmation, et corriger les verrues que cela révèle, ne veut pas dire qu'il faut forcément lui ajouter des types dépendants de la mort.

(D'ailleurs j'ai travaillé pendant un moment sur un langage jouet (le lambda-calcul simplement typé) qui n'a même pas de génériques / de polymorphisme, pour y comprendre des questions de base qui ne mettent pas en jeu ces aspects.)

Il ne faut pas croire que "étudier les langages comme des objets mathématiques" veut forcément dire "cracher sur tout ce qui ne ressemble pas à Haskell". On a identifié des problèmes à plein de niveaux simples (comme la portée des variables, ou les tableaux covariants en Java) qui s'appliquent à tous les langages, et on peut très bien formaliser et étudier (et améliorer !) des langages impératifs ou objets assez simples.

Pourtant, quand les fonctions anonymes ont été introduites au grand public à travers Javascript, les gens ont soudain trouvé ça intéressant, et aujourd'hui les "gens de l'industrie" ne crachent pas dessus dans C++ ou Java. (Fonctions anonymes, introduites il y a 85 ans par l'informaticien théoricien Alonzo Church. Laissez-moi vous dire qu'à l'époque non plus, ce n'était pas proche des besoins de l'industrie !)

Ce que tu dis sur Java/Kotlin n'est pas faux, quelques remarques :

• Java est beaucoup plus sûr que C/C++ pour écrire du code sale parce qu'il a un GC, encore une idée écrite par des théoriciens déconnectés des besoins de l'industrie
• aurais-tu envie de te remettre à écrire du code en Java sans les génériques, concept introduit (et ensuite implémenté dans Java) par des théoriciens déconnectés ?

Enfin, quelques questions : d'après-toi, est-ce que les chercheurs en programmation (financés par l'argent public, etc.) devraient avoir comme finalité dans la vie d'aider l'industrie à écrire du code crade et jetable plus vite qu'avant ? C'est peut-être une bonne idée, sur laquelle certains d'entres nous devraient travailler, ou alors c'est clairement notre seule rôle dans le monde, sur laquelle tout le monde devrait travailler ? Et rendre les programmeurs jetables/interchangeables en uniformisant les outils et techniques (une autre chose dont les managers dans l'industrie auraient bien envie), on devrait travailler dessus aussi ? (Et dans les avions, centrales nucléaires, robots tueurs, on fait aussi du crade et jetable ?)

Je pense intéressant d'avoir un débat, et que les gens peuvent avoir des réponses différentes à ces questions. Moi j'ai écrit ce texte pour décrire l'approche de ma communauté scientifique—pas pour convaincre les gens que c'était la chose la plus importante ou urgente du monde. Là on s'éloigne un peu du sujet, mais pourquoi pas.

Je m'excuse d'avoir mal formulé, mais je n'ai pas dit que les concepteurs de C avaient commis une faute professionnelle. Au contraire j'ai dit "à l'époque de C c'était compréhensible, aujourd'hui (à l'époque de Go) c'est une faute professionnelle". Je parle de faute dans le contexte de Go. Oui, je pense qu'on peut argumenter qu'ignorer une fonctionnalité de langages de programmation (les types somme) qui ajoute peu de complexité, améliore la clarté et la sûreté et évite des bugs et des erreurs, quand on est, professionnellement, concepteur de langage de programmation, c'est une faute.

Dire que les gens commettent des fautes, je ne trouve pas que ce soit méprisant.

je trouve que l'ensemble de ton discours sur [..] Go montre une certaine forme de condescendance assez violente de ta part (voire de ton milieu) envers [ce langage]. […] tu sembles tellement obnubilé sur l'aspect théorique que tu perds toute vision des autres critères pourtant essentiels dans le milieu.

Je t'invite à relire la discussion sur Go, qui a évoqué le premier les aspects de Go suivant ?

• les outils autour du langage sont très bien faits
• le runtime (pour la concurrence) est efficace et bien écrit
• la bibliothèque standard est bien faite pour le backend web

Réponse : c'est moi à chaque fois. Ce que anaseto et Nicolas Boulay avaient dit c'est "c'est un langage simple" (bof), et "c'est rapide et ça compile vite". Ils sont au courant des avantages ci-dessus que j'ai explicités, mais c'est moi qui les ai introduits dans la discussion pour rappeler et souligner qu'un écosystème de programmation autour d'un langage, à l'usage, n'était pas défini que par les qualités linguistiques du langage lui-même (tout en critiquant le langage sous-jacent). J'ai aussi appuyé le commentaire de c³ sur le fait que Go ignore (volontairement) les développements en langages de programmation qui ne viennent pas de ses auteurs. Je ne pense pas que rappeler un fait soit un signe de "condescendance assez violente", même quand il n'est pas à l'avantage du langage dont on parle.

Tu as raison sur le fait que la définition des bugs comme des simples erreurs de transcription entre une idée (chez le programmeur) d'un comportement bas-niveau du programme et le code source correspondant est trop restrictive. Il y a aussi des comportements de programme que l'on considère comme des bugs parce qu'ils violent une spécification (là encore, que l'humain a en tête) de haut niveau, alors que le code source ait été pensé (et écrit) d'une façon qui ne la respecte pas. Il me faudrait essayer de reformuler.

Non, les outils de vérification/normes/règles de codage n'ont généralement pas comme objectif d'améliorer la clarté du langage.

Je pense que ton interprétation de ce que j'ai écrit est trop étroite. Pour rappel, j'avais mis :

certaines constructions des langages de programmation nous aident à exprimer notre intention, et les concepteurs et conceptrices de langages de programmation travaillent à concevoir des outils pour vérifier automatiquement que l'intention ainsi exprimée est cohérente avec le reste du texte du programme

Un aspect du langage qui entre dans ce cadre conceptuel est un système de typage. Finalement le fait de dire qu'une variable est un entier, ou une chaîne de caractère, ou bien un pointeur de fonction n'a pas tellement d'importance pour le comportement observable du programme à l'exécution (ça peut en avoir pour une compilation optimisée). Par contre ça en a beaucoup pour la clarté du programme (sans annotation de type, c'est plus dur de lire le code et de comprendre ce qu'il fait), et la redondance apportée par ces annotations permet à nos outils (les compilateurs) de dire parfois "attention, tu utilises la variable x comme un pointeur, mais tu l'as déclarée comme un entier, n'y a-t-il pas confusion ?", ce qui élimine des bugs.

(C'est intéressant de réfléchir au fait qu'un langage ou ses outils ne peuvent faire ça que s'il y a un peu de redondance entre les différentes choses qu'on dit sur notre programme (le code, les types, les assertions de debug/défense, mais aussi à la rigueur les les idiomes / figures de style (if (x = e) contre if ((x = e))), les commentaires, le sens des noms de variable…). Si on ne spécifiait tout qu'une seule fois, sans jamais aucun recouvrement, on ne pourrait pas détecter automatique d'incohérence.)

Sur ce point, tu as très probablement raison, encore que je ne suis pas sûr que ça s'harmonise parfaitement avec le reste du langage, au sens, ça demande d'introduire une nouvelle notion, pas de changer une notion existante (les constantes en go étant déjà utilisées comme enum, le cas particulier d'utilisation le plus courant).

Oui, mais pour utiliser les termes de mon billet ci-dessus, c'est de la complexité essentielle et pas incidente (traduction maison de accidental complexity dont je suis en toute modestie assez fier). Quand on manipule des données, le cas somme (ou manipule une donnée qui est soit de la forme A soit de la forme B) arrive vraiment dans tous les domaines métiers, c'est un concept indépendant du langage de programmation, et il y a deux camps, les langages qui permettent de le représenter et les autres. Go est chez les attardés. C'est compréhensible pour C qui a été écrit par des chercheurs en systèmes à une époque où il y avait peu de communication entre les équipes de recherche (il faut quand même noter que C et ML ont été inventé à la même époque, donc l'idée des types algébriques était déjà dans l'air et aurait pu être ajoutée à C si ses concepteurs avaient été un peu curieux), aujourd'hui c'est une faute professionnelle, appelons un chat un chat.

(C'est quand même vraiment très con d'écrire (a, err) := foo(bar), en sachant que a n'est pas défini si err est nil !)

Mais que juste ceci donne droit aux « 40 années de recherche ignorées » me semble légèrement injuste

Non, toute la conception du langage est comme ça. Quand tu lis la référence du langage Go, tu vois des gens qui se sont bouchés les oreilles pour ne surtout pas entendre parler ou s'inspirer de ce qui ne vient pas de chez eux.

Je ne pense pas qu'on puisse débattre de ce point. Tant pis si ça ne fait pas plaisir aux gens qui ont d'autres raisons (certainement intéressantes et valides) de s'intéresser au langage; après tout, on fait du Javascript sur le web parce qu'on est bien forcé, alors que c'est une daube (qui s'améliore ces temps-ci, parce qu'encore une fois on était bien forcé), personne n'essaie de défendre l'honneur perdu de Javascript, c'est une daube. Go est un langage régressif, autant l'admettre tout de suite et discuter de choses intéressants (par exemple le lien entre langages et outils) au lieu de dire que c'est injuste.

(Je remarque que parfois les programmeurs et programmeuses rechignent à admettre des défauts de leurs langages parce qu'il y a une dimension communautaire voire marketing au choix du langage : on a besoin que les langages qu'on utilise séduisent les gens pour avoir plus d'outils et de bibliothèques, donc il faut avoir un discours positif et ne pas insister sur ses points faibles. Je pense que cette forme de subjectivité est inévitable dans certains contextes, mais elle n'a pas sa place dans le contexte de discussions sur la recherche en langage de programmation, où il faut essayer de s'exprimer au maximum de façon réaliste et précise.)

ce n'est pas qu'une question d'outils, le succès de ce langage, c'est aussi (et peut-être surtout) une question d'approche par la simplicité (au risque d'être simpliste parfois), optique qui n'est pas du tout à la mode et qui manquait visiblement à pas mal de monde ; je pense que des langages avec des systèmes de types plus évolués pourraient essayer de s'en inspirer un peu.

On a du mal à bien comprendre ce qui fait le succès d'un langage plutôt qu'un autre, donc ce que je vais dire n'a pas forcément plus de poids ou de validité que ce que tu as dit, on navigue au jugé. Mais je pense que (en plus du fait qu'il y a de bons outils) "ça vient de Google donc c'est bien" plus "un runtime et une bibliothèque standard bien faits pour faire de la tuyauterie web de bas-niveau" a eu beaucoup plus d'impact que la "simplicité" du langage pour expliquer son succès. Si tu regardes les canaux en Concurrent ML (CML, fin des années 90), c'est tout aussi simple que Go, et pourtant personne ne s'en sert. Je serais prêt à parier que si tu avais pris une équipe de taille non-négligeable à Google pour faire une syntaxe à la Javascript pour ce langage, un bon runtime et une bonne bibliothèque standard, tu aurais quelque chose tout aussi populaire que Go aujourd'hui, et ce serait clairement un meilleur langage de programmation.

Je comprend pas. Un programme écrit dans un langage donné est quelque part déjà un objet mathématique. « et à partir de cela définir le langage » euh, on commence pas par définir le langage avant d’écrire des programmes ???

En mathématiques, pour décrire les ensembles de nombres (nombres entiers, relatifs, rationnels, réels, complexes…), on fait l'inverse. D'abord je définis ce qu'est un entier naturel , et ensuite je définis l'ensemble des entiers . C'est pareil pour les programmes : d'abord je définis ce qu'est un programme que je veux étudier, et à partir de cela je peux définir le langage de programmation.

Alors la façon dont je définis "un programme" c'est en donnant, par exemple, une syntaxe BNF qui, on est d'accord, correspond bien au choix d'un certain langage de programmation. Mais ce n'est pas à ce moment qu'on définit le langage, c'est seulement ensuite, une fois qu'on a défini ses programmes.

Il y a une légère ambiguité dans le texte sur laquelle tu mets le doigt : quand je dis "programme", est-ce que je parle du code source du programme (facile à définir comme un objet mathématique), ou du comportement à l'exécution du programme (plus délicat à définir) ? Dans cette partie du texte, quand je parle de "voir un programme comme un objet mathématique", je parle plutôt du code source (ou d'une représentation plus abstraite mais de même genre), et c'est quand je parle de "sémantique" (ou "signification") du programme que je m'intéresse à la définition (formelle) du comportement à l'exécution.

Par exemple dans le cas d'école du lambda-calcul, on définit d'abord un terme du lambda-calcul (donné par une grammaire et une structure de nommage), c'est ce que j'appelle "définir un programme comme un objet mathématique". Ensuite on définit par exemple une relation de réduction petit-pas , cela donne un modèle d'exécution pour les programmes et cela fait partie de la définition du langage comme un objet mathématique.

J’imagine que par « mathématiquement » tu veux dire « dans un formalisme logique ».
[..]
Ton utilisation de « mathématique » me gène en fait, en tant que personne qui connaît un peu le domaine.

Ce que j'appelle "objet mathématique" c'est un objet qui est défini dans le monde mathématique, pas dans le monde réel. L'adjectif "mathématique" désigne les concepts et objets qui vivent dans ce monde mathématique.

Il y a une différence entre "un programme C", un concept du monde réel, et "l'objet mathématique qui représente un programme C dans mon formalisme". C'est plus facile à voir quand on pense à la différence entre "un processeur qui exécute des instructions assembleurs" et "l'objet mathématique qui définit la sémantique du processeur qui exécute l'assembleur" : on conçoit aisément qu'il peut y avoir une distance importance entre les deux (rayons cosmiques, attaque Row Hammer, etc., qui sont ou ne sont pas modélisés par l'objet mathématique dont on parle). Pour un programme C, la distance est plus petite voire nulle (en fait les programmeurs pensent à l'objet abstrait, pas à une séquence d'octets sur leur disque; mais ma modélisation mathématique ne rend pas forcément compte d'alloca, ou des extensions GNU machin, ou du préprocesseur, etc.). Je préfère garder systématiquement la séparation entre les deux mondes car elle est importante pour comprendre la portée des énoncés formels en général, et l'oublier peut conduire à des erreurs (dans les deux sens : trop promettre à partir d'une preuve formelle, ou alors critiquer une preuve hors de propos car on n'a pas regardé le modèle avec soin).

Je ne suis pas un expert sur ce sujet, mais je ne connais pas d'étude sur l'impact des biais cognitifs et capacités d'abstraction sur l'usage d'un langage.

Mon expérience à moi, à la fois comme programmeur et comme chercheur, c'est que dans tous les cas que j'ai rencontrés où le formalisme suggère un changement ou une modification, c'est effectivement quelque chose qui améliore la vie à l'usage. Ça n'est pas incompatible avec ce que tu dis (il y a aussi des changements qui ne sont pas suggérés par le formalisme et qui sont efficaces, et peut-être qu'étudier nos biais cognitifs peut en suggérer de nouveaux), mais j'aurais tendance à dire qu'il ne faut pas sous-estimer l'approche formaliste qui s'est révélé redoutablement efficace en pratique.

Je ne crois pas que Prolog ait "échoué" (il marche bien dans la niche pour laquelle il marche bien, l'erreur serait de le vendre comme un langage généraliste), mais je pense que les limitations de Prolog peuvent très bien s'expliquer à travers les outils de mon école scientifique (formaliste), sans avoir besoin d'invoquer la capacité des humains à faire du raisonnement logique. Prolog est un langage qui n'est pas du tout déclaratif, dans le sens où la compréhension du modèle d'exécution sous-jacent est absolument indispensable pour comprendre comment écrire des programmes correctement, et des opérations qui devraient en théorie respecter la sémantique du programme (comme le fait d'inverser l'ordre dans lequel deux prédicats sont écrits) cassent en pratique complètement le programme, le faisant non-terminer ou exploser en temps sur les cas d'usage qui nous intéressent.

En gros : tu tiens sans doute une piste intéressante avec l'idée de regarder les limitations de calcul/raisonnement des humains, mais je pense qu'il y a encore beaucoup à apprendre juste avec une approche formaliste et que ce n'est pas nécessairement moins efficace.

(Attention: le fait d'utiliser des raisonnements mathématiques pour étudier les langages de programmation ne veut pas dire qu'il faut forcer les programmeurs et programmeuses à maîtriser ces raisonnements pour bien utiliser ces langages. C'est au contraire plutôt un gage de bonne science que de savoir, même quand on utilise des techniques avancées et compliquées, en tirer des conclusions simples qui sont accessibles aux gens qui ne connaissent pas les outils de travail.)