Journal Pourquoi la recherche en langages de programmation ?

Posté par gasche le 17 octobre 2017 à 11:10. Licence CC By‑SA.

Étiquettes :

oct.

2017

Sommaire

Pourquoi la recherche en langages de programmation ?

Je fais de la recherche en langages de programmation. Dans le journal ci-dessus, j'explique pourquoi et comment, en essayant d'être accessible pour des gens qui connaissent peu (ou mal) la programmation et/ou la recherche.

Pourquoi la recherche en langages de programmation ?

Les programmeurs et programmeuses ont inventé de nombreuses représentations symboliques des programmes qui sont exécutés par un ordinateur, représentations que l'on appelle langages de programmation. On peut les voir comme des langages utilisés pour parler avec l'ordinateur, un programme étant un texte dans ce langage, le code source. Mais il est important de se souvenir que la programmation est aussi une activité sociale: la plupart des programmes sont écrits par plusieurs personnes travaillant ensemble, et les programmes écrits par une personne seule sont souvent réutilisés, inspectés et modifiés par d'autres. Un programme transmet une intention à l'ordinateur, mais il la communique aussi à des humains.

Quand on programme, on est facilement irrité par les défauts du langage de programmation qu'on utilise; il est très difficile de concevoir un bon langage de programmation. On lui demande au moins les trois qualités suivantes :

la concision: Les tâches simples doivent être décrites par des programmes simples, pas par des programmes gros ou complexes. Les tâches complexes nécessitent des programmes complexes, mais la complexité du programme doit venir uniquement du domaine métier (les spécificités de la tâche requise), sans complexité incidente imposée par le langage de programmation.

Par exemple, les premières recherches en intelligence artificielle ont révélé le besoin d'un bon support, par le langage de programmation, du backtracking (retour en arrière) : annuler une série de décisions prises pour atteindre un certain but, en cas d'échec, pour commencer à nouveau selon une méthode différente. Certains langages de programmation rendent beaucoup plus facile d'exprimer cela que d'autres.
la clarté: En lisant le texte d'un programme, il faut qu'il soit facile de comprendre l'intention des personnes qui l'ont écrit. On dit qu'un programme a un bug (un défaut de fabrication) quand sa signification (pour l'ordinateur) ne correspond pas à l'intention de ses auteurs—une erreur a été faite pendant la transcription des idées dans le texte du programme. La clarté est un composant essentiel de la sûreté (éviter les comportements inattendus et dangereux). Pour l'améliorer, 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.

Par exemple, l'un des pires problèmes de sécurité découvert en 2014 (le fait que tous les ordinateurs et téléphones Apple ne vérifiaient pas correctement l'authenticité des sites webs demandant une connection sécurisée) était causé par une ligne dans le texte d'un programme qui avait été dupliquée—écrite deux fois au lieu d'une seule. La différence entre l'intention du programmeur (vérifier l'authenticité des communications sécurisées) et le comportement réel du programme (permettant à des mauvais acteurs de se faire passer pour votre banque ou boîte email, intercepter vos paiement en ligne, etc.) était considérable, et pourtant ni les humains ni les outils automatiques qu'ils utilisaient n'avaient repéré cette erreur.
la cohérence: Un langage de programmation devrait avoir une structure très régulière, pour qu'il soit facile pour ses utilisateurs et utilisatrices de deviner comment utiliser les parties du langages qu'ils ne connaissent pas encore bien. En particuliar, la cohérence aide la clarté : retrouver l'intention derrière le texte du programme demande une bonne connaissance du langage, et plus le langage est cohérent, prévisible, plus faibles sont les risques de mécompréhension. C'est un cas particulier d'un principe de conception plus général, le principe de surprise minimale.

Bien sûr, la liste (non exhaustive) ci-dessus n'est que l'opinion informelle d'une personne pratiquant la programmation (moi-même), et non pas une affirmation scientifique établie rigoureusement. La programmation est un domaine riche qui met en jeu de nombreuses activités, donc la recherche scientifique sur les langages de programmation peut être entreprise, et devrait être entreprise, depuis de nombreux angles différents. Entre autres, les mathématiques (la formalisation), l'ingénérie, le design, les interfaces homme-machine, l'ergonomie, la psychologique, la linguistique, les neurosciences, la sociologie, et les personnes qui pratiquent la programmation ont toutes leur mot à dire sur comment concevoir de meilleurs langages de programmation.

Pour ma part, je travaille au sein d'une communauté scientifique qui utilise la formalisation mathématique comme son principal outil pour étudier, comprendre et améliorer les langages de programmation. Pour travailler sur un langage, on lui donne une sémantique formelle (ou plusieurs) en définissant les programmes comme des objets mathématiques, au même titre que les nombres ou les fonctions. La sémantique d'un langage est alors donnée par une relation (mathématique) entre les programmes et leur comportement. On peut ainsi prouver des théorèmes sur les langages de programmations eux-mêmes, ou sur les analyses et transformations de programmes.

Voir dans le détail comment la formalisation mathématique d'un langage de programmation peut guider sa conception est absolument fascinant—c'est une approche très abstraite d'une activité très concrète. Ma communauté de recherche a défini un certain nombre de propriétés qui peuvent s'appliquer ou non à la formalisation mathématique d'un langage donné (l'objet mathématique que l'on a défini pour représenter le langage), et qui capturent certains aspects de l'utilisabilité du langage. Il s'agit en quelque sorte d'un ensemble de tests pour évaluer un langage. Cet ensemble de tests évolue au fil du temps, car nous affinons notre compréhension de ces propriétés formelles et nous en proposons de nouvelles, à partir de nos expériences d'utilisation des langages existants ou expérimentaux.

Avoir une sémantique formelle d'un langage que l'on étudie est une façon de comprendre ce que les programmes de ce langage veulent dire, ce qui est une première étape nécessaire pour évaluer ou améliorer la clarté du langage—un programme ne peut pas être clair si on ne commence pas par se mettre d'accord sur ce qu'il veut dire. Construire cette formalisation est un travail difficile (technique) et chronophage, mais son pouvoir de simplification ne peut pas être surestimé. Le travail de formalisation agit comme une loupe qui grossit les irrégularités, et suggère naturellement des changements du langage qui peuvent améliorer drastiquement sa cohérence. Il nous encourage à construire (ou reconstruire) le langage autour d'un petit ensemble de concepts centraux et indépendants, ses briques de base—c'est la meilleure façon de rendre la formalisation plus facile. Il peut donc améliorer aussi la concision, puisque des concepts avancés peuvent être décrits de façon simple en combinant ces briques de base. Bien sûr, trouver les bonnes briques de base demande une connaissance du domaine métier (celui des programmes dont on veut améliorer l'écriture dans ce langage); pour avoir des idées vraiment nouvelles il faut souvent explorer avec des prototypes ou faire des études d'usage, en dehors de l'activité de formalisation. La méthode de conception de langages que je préfère, c'est donc la co-évolution d'un langage et de sa formalisation, les activités de formalisation et de programmation ayant lieu en même temps, pour informer et diriger le processus de conception.

# Super texte …

Posté par Thomas Douillard le 17 octobre 2017 à 12:15. Évalué à 3.

Je trouve ça dans l’ensemble très clair et très intéressant, même en étant pas la cible. Après je pense que la première phrase est un peu sèche pour un béotien (« représentation symbolique », ça peut faire peur, ce serait dommage). Et tu ne reparles pas de symbole dans la suite, donc l’utilité est sans doute discutable.

Quelques remarques :

Je pense aussi que tu peux intervertir « formalisation mathématique d'un langage de programmation » et « sémantique formelle ». Le second est plus technique, utiliser la première expression en définissant la seconde.

on lui donne une sémantique formelle (ou plusieurs) en définissant les programmes comme des objets mathématiques

Un peu ambigu je trouve, mais c’est pas très grave, et peut être un peu confusant : le programme peut être considéré comme la spécification d’un algorithme dans un langage, alors que la sémantique formelle peut être considérée comme la spec du langage lui même. Ou alors tu veux dire que si le langage n’a pas de sémantique formelle, on ne peut pas considérer le programme comme un objet mathématique ? Mais je pinaille peut être un peu beaucoup pour ce que tu cherches à faire.
- [^] # Re: Super texte …
  
  Posté par gasche le 17 octobre 2017 à 12:54. Évalué à 4.
  
  Merci pour les retours !
  
  Après je pense que la première phrase est un peu sèche pour un béotien (« représentation symbolique », ça peut faire peur, ce serait dommage).
  
  Comment est-ce que tu définirais ce qu'est un langage de programmation ? J'aimerais trouver quelque chose qui soit accessible aux non-spécialistes, mais qui soit aussi correct. Je n'aime pas trop le fait de dire "c'est comme une langue humaine, mais pour parler à l'ordinateur", parce que ça met les gens sur de fausses pistes (trop comparer aux langages humains).
  
  on lui donne une sémantique formelle (ou plusieurs) en définissant les programmes comme des objets mathématiques
  
  Un peu ambigu je trouve, mais c’est pas très grave, et peut être un peu confusant : le programme peut être considéré comme la spécification d’un algorithme dans un langage, alors que la sémantique formelle peut être considérée comme la spec du langage lui même. Ou alors tu veux dire que si le langage n’a pas de sémantique formelle, on ne peut pas considérer le programme comme un objet mathématique ?
  
  L'idée c'est qu'on peut représenter un programme (dans un langage donné) comme un objet mathématique, et à partir de cela définir le langage. Intuitivement on pense à le définir comme un ensemble de programmes, mais en fait il faut aussi donner leur sémantique, c'est-à-dire donner le lien entre le programme (le texte) et le comportement quand on le lance (aussi représenté comme un objet mathématique.
  
  Attention, on peut aussi représenter mathématiquement un algorithme, mais l'objet mathématique qui correspond à un programme C par exemple n'est pas le même que celui qui correspond à l'algorithme implémenté (on peut montrer qu'il y a un lien entre les deux, mais c'est du travail, puisqu'en particulier cela revient à prouver que le programme est correct, qu'il ne contient pas de bug).
  - [^] # Re: Super texte …
    
    Posté par Thomas Douillard le 17 octobre 2017 à 14:23. Évalué à 4.
    
    Je dirai que « les informaticiens ont inventé de nombreuses manières de décrire les programmes qui sont exécutés par un ordinateur » conviendrai dans un premier temps. Tu peux rajouter « souvent ils sont écris sous forme de texte, parfois d’autres formes, ou d’autres formes symboliques (« graphiques » par ex. https://scratch.mit.edu/) ». Dans tous les cas, le formalisme qui permet de les décrire constitue ce qu’on appelle un « langage de programmation ». »
    
    L'idée c'est qu'on peut représenter un programme (dans un langage donné) comme un objet mathématique, et à partir de cela définir le langage.
    
    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 ??? Peut être qu’il faut que tu parles de sémantique (en général) d’un langage de programmation, sinon pareil je pense que ça peut ne pas être clair pour un débutant.
    Je propose :
    
    «Les informaticiens apprennent souvent par l’exemple et la pratique (et un prof et ses explications) ce qu’est supposé faire un programme et se forgent une intuition de la signification du code qu’ils écrivent, Ensuite, on essaye de le faire tourner pour voir si « ça marche » … et parfois, « ça marche ».
    
    Les approches formelles s’appuient sur autre choses que l’essai et l’erreur et s’appuient sur la logique et les mathématiques pour décrire le comportement attendu d’un programme (indépendamment de ce qui se passe vraiment quand on le teste). La sémantique formelle (cette fois) d’un langage permet de faire le lien entre chaque programme écrit dans ce langage et ce comportement attendu. Votre boulot est en partie de l’écrire et de l’imaginer.»
    
    Du coup vous vous nourrissez de la rigueur des maths pour détecter d’éventuels problèmes, et le point de vue différent offert peut donner de nouvelles idées et définir des choses précises là ou les langages de programmation « défini par l’implémentation ou la doc » sont moins précis et solides, peuvent avoir des trous et des points non documentés ou on est vraiment obligé de tester pour savoir ce que ça fait « en vrai ». Non ?
    
    Intuitivement on pense à le définir comme un ensemble de programmes, mais en fait il faut aussi donner leur sémantique, c'est-à-dire donner le lien entre le programme (le texte) et le comportement quand on le lance (aussi représenté comme un objet mathématique.
    
    « Intuitivement on pense à le définir comme un ensemble de programmes » Mmm certainement pas l’intuition d’un débutant … En fait ce que tu entend par « programme » n’est pas forcément clair. Et cette intuition de programme en tant que composition de programme interroge sur une notion de « programme primitif » qui est un peu HS et pas du tout intuitive pour quelqu’un qui ne connait pas la programmation. C’est un peu une impasse, je pense.
    
    J’imagine que par « mathématiquement » tu veux dire « dans un formalisme logique ».
    
    Attention, on peut aussi représenter mathématiquement un algorithme, mais l'objet mathématique qui correspond à un programme C par exemple n'est pas le même que celui qui correspond à l'algorithme implémenté
    
    Il faut que tu utilises soit un langage algorithmique basique, qu’on peu facilement assimiler à un langage de programmation, soit des formules déclaratives (dans une logique) pour décrire des propriétés du résultats. La preuve visera à démontrer que les opérations décrites par l’algo réalisent bien les propriétés attendues. Ton utilisation de « mathématique » me gène en fait, en tant que personne qui connait un peu le domaine.
    
    Autre remarque :
    
    La sémantique d'un langage est alors donnée par une relation (mathématique) entre les programmes et leur comportement.
    
    Je pense que c’est clair uniquement pour ceux qui savent ce qu’est une relation mathématique.
    - [^] # Re: Super texte …
      
      Posté par gasche le 18 octobre 2017 à 11:15. Évalué à 5. Dernière modification le 18 octobre 2017 à 11:16.
      
      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 $\mathbb{N}$ . 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 $t_1 \to t_2$ , 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).
      - [^] # Re: Super texte …
        
        Posté par Thomas Douillard le 18 octobre 2017 à 18:35. Évalué à 3.
        
        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.
        
        Ça se discute. Tu notes une relation de temporalité (voire de causalité) qui n’existe pas forcément dans le monde mathématiques. On ne définit pas les entiers en donnant tous les exemples d’entiers, et une fois qu’on l’a fait, on définit les entiers. On donne des axiomes qui permettent de décider si un objet du formalisme est ou pas un entier. Par l’axiome d’extensionnalité, à tout prédicat correspond une extension : « Étant donné un ensemble A et une propriété P exprimée dans le langage de la théorie des ensembles, il affirme l'existence de l'ensemble B des éléments de A vérifiant la propriété P » https://fr.wikipedia.org/wiki/Sch%C3%A9ma_d%27axiomes_de_compr%C3%A9hension . Mais à chaque propriété sur un ensemble correspond une seule extension … que tu définis « en même temps » que tu donnes la propriété. En complexité, on définit même un problème de décision comme l’appartenance ou pas d’une chaîne à un ensemble. Le prédicat associé à l’ensemble n’est même pas évoqué … En gros dans mon esprit la BNF (le prédicat) définit l’ensemble (le langage). Sauf si tu assimiles l’écriture de la BNF à la définition d’«un» programme, mais c’est pas du tout ma vision des choses. Enfin cette manière de décrire les choses correspond peut être à une vision constructiviste des choses ;).
        
        Sinon je suis entièrement d’accord pour ce que tu dis sur la formalisation, avoir un accord parfait entre la théorie et l’expérience est un acte inaccessible. Cela dit, je pense avoir identifié un truc qui manque dans ton texte : il est considéré comme implicite que le programme est destiné à être exécuté. Du coup la métaphore du « parler » tombe un peu à plat. Quand je fais une requête google, je « parle » à la machine, pourtant je ne la programme pas. Un programme est destiné à être exécuté, et peut être exécuté pleins de fois. ça ne transparaît dans ton texte que quand tu parles de comportement du programme. Ce qui pourrait lever ton ambiguïté d’ailleurs.
        
        (et je poste en l’état parce que j’y ai déjà passé trop de temps)
        
        [^] # Re: Super texte …
        
        Posté par gasche le 18 octobre 2017 à 18:46. Évalué à 3.
        
        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.)
        
        [^] # Re: Super texte …
        
        Posté par Thomas Douillard le 18 octobre 2017 à 19:46. Évalué à 2. Dernière modification le 18 octobre 2017 à 19:47.
        
        Ah oui pardon, j’ai dû être trompé par « Dans cette partie du texte, quand je parle de "voir un programme comme un objet mathématique", je parle plutôt du code source ». Toujours cette satanée confusion … c’est absolument pas naturel pour moi de considérer le code simplement comme un programme.
        
        On est pas aidé par des expressions comme langage formel. En fait un langage de programmation (ou sa formalisation) est du côté des système formels, un langage formel en fait simplement partie. Le système formel est constitué du couple (langage formel, sémantique), et on est d’accord que la grammaire définit la partie « langage formel ».
  - [^] # Re: Super texte …
    
    Posté par Alex G. le 17 octobre 2017 à 16:32. Évalué à 7.
    
    Comment est-ce que tu définirais ce qu'est un langage de programmation ? J'aimerais trouver quelque chose qui soit accessible aux non-spécialistes, mais qui soit aussi correct. Je n'aime pas trop le fait de dire "c'est comme une langue humaine, mais pour parler à l'ordinateur", parce que ça met les gens sur de fausses pistes (trop comparer aux langages humains).
    
    Que dirais tu de prendre l'approche contraire : "c'est une codification des instructions donnée à la machine, qui cherche à être le plus possible intelligible par un humain".
# À propos des qualités et la co-évolution

Posté par anaseto le 17 octobre 2017 à 14:05. Évalué à 3.

D'abord merci pour ce journal intéressant.

Par rapport aux qualités, un point peut-être à mentionner, c'est le cadre d'application d'un langage, qui doit donc être concis, clair, cohérent etc. pour ce quoi il est prévu, mais du coup ça peut beaucoup varier, et c'est parfois difficile d'avoir toutes ces qualités en même temps. Il faut donc faire des compromis qui dépendent du champ d'application du langage et du public visé.

Et par rapport à la co-évolution, je suis d'accord que c'est quelque chose qui est très souhaitable. J'y rajouterais aussi l'importance d'essayer d'avoir des retours par les potentiels utilisateurs en utilisant dans la mesure du possible un échantillon varié du public visé, avec différents degrés de compétence, parce que ça peut mettre en évidence des points obscurs qui autrement passent inaperçus. Je trouve par exemple intéressant l'approche incrémentale de rust, qui essaie à la fois d'attirer les formalisations et les programmeurs, tout en s'inquiétant de l'accessibilité (même si clairement il y a du progrès à faire encore sur certains points, par exemple concernant les temps de vie des variables, il me semble, mais j'ai pas beaucoup testé le langage).
# Le cerveau n'est pas logique

Posté par Alex G. le 17 octobre 2017 à 16:48. Évalué à 4.

Merci pour l'article.

Un risque avec la modélisation mathématique est peut être de passer à coté de la facilité d'utilisation du langage. En effet le cerveau n'est pas si fort que ça en logique, même celui d'un programmeur moyen.
D'une part certaines erreurs que fait le programmeur sont dues à ce manque de logique (la pensée rapide), d'autre part, il est incapable de manier un système logique trop complexe. C'est, il me semble, l'échec de langage de programmation comme Prolog. C'est aussi illustré par ce jeu sur Clips (langage).

Bref y-a-t'il des travaux qui inclues nos biais cognitifs / capacité d'abstraction dans l'étude des langages de programmation ?
- [^] # Re: Le cerveau n'est pas logique
  
  Posté par anaseto le 17 octobre 2017 à 17:20. Évalué à 3.
  
  En effet, une sémantique formelle simple et des preuves mécaniques simples ça ne veut pas forcément dire intuitives pour l'humain : il suffit d'avoir un peu utilisé un assistant de preuve comme Coq pour s'apercevoir que notre vision du simple et du compliqué est souvent en désacord avec celle de la machine. Ceci dit, je dirais quand même qu'en pratique, dans le doute, viser une sémantique formelle simple et adaptée raisonnements formels a des chances d'aider à obtenir un langage plus simple pour l'humain aussi (l'idéal étant d'avoir les deux); et puis je dirais rajouter des irrégularités que lorsqu'on a une bonne raison, comme par exemple viser à être moins général et utiliser une solution plus ad hoc lorsque c'est plus raisonnable d'un point de vue humain.
  - [^] # Re: Le cerveau n'est pas logique
    
    Posté par Nicolas Boulay (site web personnel) le 18 octobre 2017 à 09:30. Évalué à 3.
    
    Je me demande si des ergonomes se sont penché sur les langages. J'imagine qu'il aimerait plutôt des dessins type UML simplifié pour décrire les objets, la preuve : on documente de cette façon. Mais je ne connais pas beaucoup de langages qui fonctionnent avec une parti graphique non anecdotique.
    
    Je trouve aussi qu'il n'y a jamais de moyen pour forcer une architecture. Dans un gros projet, le plat de spaghetti arrive quand tout dépend de tout, alors qu'il faudrait définir quel ensemble de module ne doit dépendre de rien et quelle sont les groupes de modules indépendants. En gros, il faudrait pouvoir décrire la barrière conceptuelle qu'il y a entre un ensemble de classe/type à la manière des membres privés d'un objet. C'est souvent ce mélange à terme qui rend les micro-services à la mode : pouvoir séparer "violemment" le code.
    
    "La première sécurité est la liberté"
    - [^] # Re: Le cerveau n'est pas logique
      
      Posté par Lutin le 18 octobre 2017 à 13:18. Évalué à 2.
      
      Mais je ne connais pas beaucoup de langages qui fonctionnent avec une parti graphique non anecdotique
      
      On peut considérer LabView comme un langage ? Sinon il y a Piet.
- [^] # Re: Le cerveau n'est pas logique
  
  Posté par kantien le 18 octobre 2017 à 10:44. Évalué à 3. Dernière modification le 18 octobre 2017 à 10:49.
  En effet le cerveau n'est pas si fort que ça en logique, même celui d'un programmeur moyen.
  
  M'est avis que le programmeur moyen devrait s'y former un minimum, il y aurait moins de bugs dans les programmes. Les systèmes à typage statique étant en grande partie basés sur la logique formelle, ils imposent déjà, de fait, une certaine hygiène logique aux développeurs.
  
  La logique est une science rationnelle non seulement selon la forme, mais selon la matière : une science a priori des lois nécessaires de la pensée, non pas relativement à des objets particuliers, mais bien relativement à tous les objets en général : c'est donc une science du droit usage de l'entendement et de la raison en général, non pas de façon subjective, c'est-à-dire non pas selon des principes empiriques (psychologiques) : comment l'entendement pense — mais de façon objetive, c'est-à-dire selon des principes a priori : comment il doit penser.
  
  Kant, Logique.
  
  Le graissage est de moi. ;-)
  
  C'est aussi illustré par ce jeu sur Clips (langage).
  
  Je n'ai pas bien compris ce que devait illustrer ce jeu. Si ce n'est que certains niveaux ont une morale douteuse :-P
  - pour survivre dans la jungle urbaine, il faut aller au travail enivré : vous ne serez pas payer, n'aurez pas d'argent mais au moins vous resterez en vie ;
  - pour épouser la femme de vos rêves, pousser votre rival dans les bras d'une psychopathe pour qu'elle le tue.
  Le premier cas correspond au problème technique suivant pour un programmeur : trouver un environnement de tel sorte qu'un état possible du système ne soit jamais atteint. Le second au problème inverse : trouver un environnement pour qu'un état soit atteint.
  
  Le jeu ayant une sémantique avec effet de bord, ce que cela montre surtout c'est qu'il n'est pas toujours évident de raisonner en présence d'effets de bord : ce dont les logiciens et les adeptes de la programmation fonctionnelle n'ont jamais douté. ;-)
  
  Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
  - [^] # Re: Le cerveau n'est pas logique
    
    Posté par Nicolas Boulay (site web personnel) le 18 octobre 2017 à 10:55. Évalué à 4.
    
    Le cerveau n'est pas fait pour la logique. Comprendre une suite de if avec un simple AND ou OR est facile, si le nombre de variable augmente, il est souvent bien plus lisible d'imbriquer les if ou d'utiliser un pattern matching ocaml.
    
    "La première sécurité est la liberté"
  - [^] # Re: Le cerveau n'est pas logique
    
    Posté par Alex G. le 19 octobre 2017 à 17:22. Évalué à 4.
    
    En effet le cerveau n'est pas si fort que ça en logique, même celui d'un programmeur moyen.
    
    M'est avis que le programmeur moyen devrait s'y former un minimum, il y aurait moins de bugs dans les programmes.
    
    C'est pas que je dise le contraire, je suis d'accord, mais je vois l'échec en pratique… Donc au delà de l'apprentissage, il faut peut être des outils pour aider à appréhender la logique et éviter aussi de faire tomber le cerveau dans des pièges. Par exemple pour moi le développement avec des tests unitaires m'aide souvent : il me montre via des exemples que je suis encore tombé dans le panneau de mon intuition !
    
    C'est aussi illustré par ce jeu sur Clips (langage).
    
    Je n'ai pas bien compris ce que devait illustrer ce jeu. (…) cela montre surtout c'est qu'il n'est pas toujours évident de raisonner en présence d'effets de bord
    
    J'avoue j'ai un peu placé la référence au jeu car il m'a bien plu :-) Et je suis d'accord que c'est surtout les effets de bords qui sont difficiles à appréhender.
    
    Ceci dit en tant que programmeur je suis souvent le gardien de la logique des spécifications fonctionnelles, et je peux dire que c'est un métier difficile ! Réussir à expliquer au client que ce qu'il demande pose des problèmes de logique… c'est constant dans le métier de l'informatique. La plupart de ces incohérences n'apparaissent d'ailleurs que quand on est en train d'écrire le programme… (ça ne ment pas) !
    - [^] # Re: Le cerveau n'est pas logique
      
      Posté par kantien le 20 octobre 2017 à 00:59. Évalué à 4.
      
      Donc au delà de l'apprentissage, il faut peut être des outils pour aider à appréhender la logique et éviter aussi de faire tomber le cerveau dans des pièges. Par exemple pour moi le développement avec des tests unitaires m'aide souvent : il me montre via des exemples que je suis encore tombé dans le panneau de mon intuition !
      
      Le typage statique est un tel outil. La plupart des systèmes de types n'évitent pas la nécessité de recourir à des tests unitaires, mais ils permettent de capturer certaines erreurs de raisonnement. Que la logique expose les lois de notre pensée ne signifie (malheureusement) pas que nous les respectons toujours, les erreurs de raisonnement sont plus ou moins fréquentes selon les personnes.
      
      J'avoue j'ai un peu placé la référence au jeu car il m'a bien plu :-)
      
      Il m'a bien plu aussi, merci pour le partage. Si l'on reprend, par exemple, le niveau 4, celui-ci illustre les problèmes de concurrence d'accès aux ressources. On a un processus (steve) qui s'accapare toutes les resources (de type female), pose un verrou dessus et ne les libère jamais. La solution : créer une ressource qui le tue avant qu'il ne bloque l'accès aux autres. :-)
      
      Ceci dit en tant que programmeur je suis souvent le gardien de la logique des spécifications fonctionnelles, et je peux dire que c'est un métier difficile ! Réussir à expliquer au client que ce qu'il demande pose des problèmes de logique… c'est constant dans le métier de l'informatique.
      
      Je veux bien te croire qu'il s'agit là d'une tâche difficile.
      
      La plupart de ces incohérences n'apparaissent d'ailleurs que quand on est en train d'écrire le programme… (ça ne ment pas) !
      
      Comme lorsque l'on cherche à véritablement démontrer une proposition qui, au premier abord, nous semblait évidente ou plus que plausible. ;-)
      
      Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
      - [^] # Re: Le cerveau n'est pas logique
        
        Posté par Nicolas Boulay (site web personnel) le 20 octobre 2017 à 10:30. Évalué à 2.
        
        Le typage statique est un tel outil. La plupart des systèmes de types n'évitent pas la nécessité de recourir à des tests unitaires, mais ils permettent de capturer certaines erreurs de raisonnement.
        
        Le problème est que tu n'attrapes pas grand chose comme erreur avec un système de typage. La seul architecture que j'ai trouvé pour aider est de transformer un arbre en un autre, sans aucune information redondante ni inutile. Ainsi, un mauvais usage ne compile pas, et on ne traine pas l'entrée à l'intérieur du code. Cela marche bien dans les "filtres unix" mais dans rien d'autre, pour des raisons de performances si les données sont énormes ou pour des raisons pratiques comme l'optimisation d'un AST qui doit donner aussi un AST.
        
        Si on regarde le gadt, la complexité est encore plus grande sans réellement attraper une énorme quantité de bugs supplémentaires. En gros, la complexité devient exponentielle, pour attraper des bugs de façon linéaire.
        
        J'ai discuté avec l'auteur français de smarteffel(?), qui utilise beaucoup les contrats, il disait qu'en codant, il violait régulièrement même des contrats de base présent dans les containers, car la pile d’héritage en bénéficiait (les contrats n’héritent). C'était d'une grande aide pour lui.
        
        Le problème est que le contrat est runtime et nécessite un test pour s’exercer. Il n'est pas possible d'avoir des contrats compile-time ou de vérifier leur cohérence entre eux ?
        
        "La première sécurité est la liberté"
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Blackknight (site web personnel, Mastodon) le 20 octobre 2017 à 11:48. Évalué à 4.
        
        Le problème est que le contrat est runtime et nécessite un test pour s’exercer. Il n'est pas possible d'avoir des contrats compile-time ou de vérifier leur cohérence entre eux ?
        
        Il y a le même problème en Ada 2012 où les contrats sont effectivement là pour générer des assertions (cf. le wikibook) et donc seulement à l'exécution. Heureusement, cela est débrayable lors de la livraison au moyen d'une pragma.
        Par contre, ces mêmes contrats sont la base de la programmation en Spark (pas le truc Apache, hein !) et sont, dans ce cas, traduits en langage intermédiaire, le Why3 (avec du Ocaml dedans), pour être ensuite passés aux moteurs de preuves
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Nicolas Boulay (site web personnel) le 20 octobre 2017 à 13:56. Évalué à 4.
        
        Il y a un rapport entre why3 et coq ?
        
        "La première sécurité est la liberté"
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par auve le 20 octobre 2017 à 14:41. Évalué à 6.
        
        Il y a un rapport entre why3 et coq ?
        
        Why3 est ce qu'on appelle un générateur de conditions de vérification, c'est à dire un outil transformant un programme contenant des spécifications formelles (typiquement formulées sous la forme de pré- et post-conditions) en un ensemble de formules logiques (les dites conditions de vérification) dont la validité implique que le programme respecte sa spécification. Une fois générées, Why3 transmet ces conditions de vérification à divers outils pour essayer de démontrer leur validité automatiquement; celles pour lesquelles ce processus échoue sont traduites vers Coq pour permettre la preuve manuelle.
        
        (Par ailleurs, l'auteur principal de Why3 est aussi un des contributeurs historiques au cœur de Coq.)
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Nicolas Boulay (site web personnel) le 20 octobre 2017 à 14:55. Évalué à 3. Dernière modification le 20 octobre 2017 à 14:55.
        
        Les exemples de preuve sont très matheux. Cela ne ressemble pas à des preuves "industrielles" (à base de bout de spec, de bout d'exemple, de ne "plante jamais", a un temps d'exécution borné).
        
        "La première sécurité est la liberté"
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Blackknight (site web personnel, Mastodon) le 20 octobre 2017 à 15:27. Évalué à 2.
        
        Quand tu parles des preuves ici, tu parles Coq, Why3 ou Spark ?
        
        Pour le dernier, je peux te donner cet exemple que j'avais déjà mentionné il y a longtemps dans un journal et qui montre que ce n'est pas toujours si matheux.
        Le github n'a pas bougé depuis un an maintenant mais ça reste du Spark2014 donc c'est toujours valide.
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Nicolas Boulay (site web personnel) le 20 octobre 2017 à 15:33. Évalué à 3. Dernière modification le 20 octobre 2017 à 15:38.
        
        Je parlais du site web de why3. ( http://toccata.lri.fr/gallery/why3.en.html )
        
        Concernant le code du drone, on dirait qu'il a seulement fait attention au overflow de calcul. Il faut que je relise moins en diagonal, je n'ai pas vu de propriété spécifiquement vérifier (genre l’arrêt d'urgence fonctionne dans tous les cas).
        
        http://blog.adacore.com/how-to-prevent-drone-crashes-using-spark regardes le 2ième commentaires qui signale tout un tas de problème dans les specs du truc.
        
        "La première sécurité est la liberté"
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Blackknight (site web personnel, Mastodon) le 20 octobre 2017 à 16:10. Évalué à 2.
        
        Concernant le code du drone, on dirait qu'il a seulement fait attention au overflow de calcul. Il faut que je relise moins en diagonal, je n'ai pas vu de propriété spécifiquement vérifier (genre l’arrêt d'urgence fonctionne dans tous les cas).
        
        Du souvenir que j'en ai, c'est exact. Ceci dit, je n'ai pas lu l'intégralité du code mis à jour depuis.
        Après, l'arrêt d'urgence fonctionne dans tous les cas reste assez vague comme contrat. On peut juste dire qu'il ne fera pas d'exception à l'exécution.
        
        http://blog.adacore.com/how-to-prevent-drone-crashes-using-spark regardes le 2ième commentaires qui signale tout un tas de problème dans les specs du truc.
        
        Certes mais ce sont des remarques sur ce que le stagiaire a implémenté pas une critique de la techno en elle-même.
        Il ne faut pas se voiler la face quand même, il est peut être compliqué d'écrire les contrats de façon à ce qu'ils puissent être prouvés
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Nicolas Boulay (site web personnel) le 20 octobre 2017 à 16:38. Évalué à 3.
        
        Après, l'arrêt d'urgence fonctionne dans tous les cas reste assez vague comme contrat. On peut juste dire qu'il ne fera pas d'exception à l'exécution.
        
        Tu crois que cela ressemble à quoi des vrai spec ? :) Je faisais un référence un peu trop subtile à un défaut d'un cruise control de toyota qui s'est fait démonté par un expert aéronautique pour un procès : il ne se désactivait pas si la pédale de frein était enfoncé…
        
        En gros, cela voudrait dire que quelques soit les autres entrés, l'arrivé de l’arrêt d'urgence doit arrêter les moteurs.
        
        Il ne faut pas se voiler la face quand même, il est peut être compliqué d'écrire les contrats de façon à ce qu'ils puissent être prouvés
        
        Je sais bien, c'est d'autant plus difficile que le langage de la preuve est éloigné du langage métier, ou du langage de dev.
        
        "La première sécurité est la liberté"
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Blackknight (site web personnel, Mastodon) le 21 octobre 2017 à 00:25. Évalué à 3.
        
        Tu crois que cela ressemble à quoi des vrai spec ?
        
        Ché pas, j'en ai jamais vu :)
        
        Je faisais un référence un peu trop subtile à un défaut d'un cruise control de toyota qui s'est fait démonté par un expert aéronautique pour un procès : il ne se désactivait pas si la pédale de frein était enfoncé…
        
        Houla, on parle de gens qui ont utilisé un OS spécialisé dans une version non certifiée en violant une tétra-chiée de règles du MISRA-C :D
        En plus, le partitionnement de l'applicatif était foireux et j'en passe et des meilleures.
        
        Au passage, si la NASA a bien fait une première étude, l'expert, Michael Barr, n'est pas issu de l'aéronautique.
        
        Allez, pour le plaisir, le rapport
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par gasche le 20 octobre 2017 à 17:25. Évalué à 4.
        
        Il y a plusieurs composants dans le projet Why3:
        - un langage fonctionnel impur, WhyML, pensé pour écrire des programmes certifiés en grande partie par des prouveurs automatiques
        - tout un outillage (interface de programmation et interfaces graphiques) pour envoyer des conditions de preuve exprimées dans un langage intermédiaire (en particulier celles générées par la vérification d'un programme WhyML) vers tout un tas de prouveurs automatiques différents, les faire tourner en parallèle, ramener les résultats à l'utilisateur, etc.
        
        À ma connaissance il n'y a pas de "projet industriel" écrit en WhyML, le langage d'entrée principal de Why3—donc oui les exemples sont ce que les gens qui travaillent dessus vont faire par intérêt ou pour tester les limites de l'outil. Par contre, la deuxième partie a été réutilisée par les gens de SPARK/Ada pour vérifier statiquement une partie des contrats d'un programme Ada (et donc ne pas avoir besoin de retester ces contrats dynamiquement), et il paraît que ça marche plutôt bien.
        
        C'est pour ça que Blackknight t'a parlé de Why3 quand tu parlais de "vérifier des contrats compile-time" : la plateforme Why3 est utilisée par une implémentation SPARK/Ada comme une plateforme de communication/collaboration entre un programme annoté avec des spécifications ou contrats et plein de solveurs automatiques pour les vérifier.
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Nicolas Boulay (site web personnel) le 20 octobre 2017 à 18:51. Évalué à 3.
        
        Dans un vieux journal, je parlais d'un langage que j'ai tenté décrire suivant la mode des langages systèmes, un truc qui ressemble a du xml mais avec une notion de nommage pour faire des graphs acycliques. Le truc est mal définit mais bon. Je me demandais si il n'était pas plus sage d'utiliser un truc costaux comme coq ou pourquoi pas why3 pour vérifier le fichier au lieu de le faire à la main. L'idée est d'avoir un langage structurel très user-friendly, dont la vérification est sous traité. L'idée est qu'un langage structurel est plus facile à vérifier.
        
        "La première sécurité est la liberté"
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par kantien le 20 octobre 2017 à 14:30. Évalué à 4. Dernière modification le 20 octobre 2017 à 14:34.
        
        Le problème est que tu n'attrapes pas grand chose comme erreur avec un système de typage.
        
        Et les licornes roses ont de jolies ailes ! :-D
        
        Tu te rends compte de ce que tu viens d'écrire ? D'une la quantité d'erreurs attrapées à la compilation dépend de l'expressivité du système de types, et de deux on peut pousser le système jusqu'à permettre de se dispenser totalement de tests unitaires. Exemple :
        
        Theorem transform_c_programm_preservation : forall p tp beh transf_c_program p = Ok tp -> program_behaves (Asm.semantics tp) beh -> exists beh', programm_behaves (C.semantics p) beh' /\ behavior_improves beh' beh
        
        Traduction en français : pour tout programme C p, tout programme assembleur tp et tout comportement observable beh, si la fonction transf_c_prgram appliquée à p renvoie le programme tp et que beh est un comportement observable de tp en accord avec la sémantique ASM, alors il existe un comportement observable beh' de p conforme à la sémantique du C et tel que beh améliore beh'.
        
        Autrement dit : la fonction transform_c_program est un compilateur optimisé du C vers l'assembleur préservant la sémantique du code source et certifié conforme ! Pas besoin de faire de tests unitaires : quand dans l'énoncé on quantifie sur tous les programmes et tous les comportements, on parle bien de l'infinité des programmes et des comportements possibles (on ne peut pas faire des tests unitaires sur une infinité de cas). :-)
        
        Tu noteras au passage la notation transform_c_programm_preservation : blabla où blabla est tout à la fois le type et l'énoncé du théorème. ;-)
        
        Plus de détails et de compléments dans la vidéo In search of software perfection - 2016 Milner Award lecture by Dr Xavier Leroy..
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Nicolas Boulay (site web personnel) le 20 octobre 2017 à 14:51. Évalué à 2.
        
        Plein de choses :
        - ton exemple n'a rien à voir avec un truc réel. Je parlais de typage statique, le genre de truc que l'on trouve dans ocaml, qui ne permet pas ce que tu écris.
        - ton exemple n'a jamais été passé dans un prouveur automatique, la démo est manuelle (frama-c ?)
        - il faut que l'expressivité soit compréhensible par le commun des mortels, why3 a l'air sympa comme coq, mais il faut être un matheux pour s'en servir. frama-c est un sous ensemble du C, et n'est même pas optimisant !
        - c'est très rare d'avoir une spécification aussi simple, un compilo qui optimise, on compare le comportement de sa génération de code sans optimisation, et on colle un fuzzer devant. Imagines le bordel de convertir 500 HLR dans ce genre de langage.
        - pour avoir bosser avec un prouveur, l'idéal est de pouvoir écrire un truc dans le même langage et lui demander si la sortie est toujours vrai. Dans le cas contraire, il fournit un contre-exemple. C'est juste énorme. En général, il répond qu'il ne sait pas faire.
        
        "La première sécurité est la liberté"
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par kantien le 20 octobre 2017 à 16:15. Évalué à 3.
        
        ton exemple n'a rien à voir avec un truc réel.
        
        Tu te fous de moi !!! C'est du Coq et c'est extrait du code du compilateur CompCert C. Cet extrait est le théorème fondamental qui garantie la certification du compilateur. C'est pour des industriels qu'il a été développé (aéronautique entre autre).
        
        Pour le reste des échanges, j'arrête là : je pisse dans un violon, tu ne connais pas grand chose aux sujets abordés mais tu parles quand même, ça me saoule.
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Nicolas Boulay (site web personnel) le 20 octobre 2017 à 16:49. Évalué à 3.
        
        compcert a été prouvé avec seulement ce bout de code ? Sans rien de manuel ?
        
        Pour info, j'ai bossé 10 ans dans l'aéronautique, et l'usage des compilos C certifié c'était plutôt : "il faudrait prendre le temps de voir ce que cela donne". De plus la preuve formelle n'est pas encore reconnu dans les certifications aéronautique, en tout cas dans la do178b, je crois que cela bouge un peu dans la DO178C. Et encore, j'imagine que le prouveur lui-même devrait être certifié… Donc, on est pas prêt de voir un avion volé avec un tel code sans certification "papier" à coté. L'outil de ma boite utilisait l'outil de prover, mais c'était peu/aps utilisé car la norme n'en voulait pas.
        
        Pour le reste des échanges, j'arrête là : je pisse dans un violon, tu ne connais pas grand chose aux sujets abordés mais tu parles quand même, ça me saoule.
        
        Je crois que je peux te répondre la même chose, mais pas pour le même domaine.
        
        "La première sécurité est la liberté"
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par kantien le 21 octobre 2017 à 00:39. Évalué à 4. Dernière modification le 21 octobre 2017 à 00:41.
        
        compcert a été prouvé avec seulement ce bout de code ? Sans rien de manuel ?
        
        Bien sur que non, c'est un travail de titan le code complet ! C'était pour illustrer ma proposition « la quantité d'erreurs attrapées à la compilation dépend de l'expressivité du système de types », en montrant un système de types tel que son expressivité dispense d'avoir à recourir à des tests unitaires. Ce théorème, qui n'est qu'une infime partie du code du compilateur, est celui que Xavier Leroy utilise dans sa vidéo comme illustration : c'est normal, c'est lui qui exprime que son compilateur est optimisant est n'apporte aucune modification de comportement à la compilation (si il y a un problème dans le code compilé, il se trouve déjà dans le code C).
        
        Pour info, j'ai bossé 10 ans dans l'aéronautique, et l'usage des compilos C certifié c'était plutôt : "il faudrait prendre le temps de voir ce que cela donne".
        
        Je le sais bien, c'est pour cela que j'ai parlé de cette industrie. Au sujet du projet CompCert C, Gérard Berry (lui, tu le connais il a cofondé l'entrepise qui fut (est ?) ton employeur et est le père du langage Esterel) l'a décrit dans le bulletin de la société informatique de France ainsi :
        
        CompCert, l’autre grande contribution de Xavier Leroy et de son équipe, est une aventure encore unique sur le plan mondial. Il s’est agi de réaliser un compilateur du langage C qui soit non plus certifié seulement pour la qualité des méthodes de développement et de test comme dans la norme DO-178C, mais bel et bien prouvé mathématiquement correct et donc vraiment garanti sans bugs.
        
        Pour info le compilateur est un produit (il n'est pas libre, seulement pour un usage non-commercial) de l'entreprise AbstInt :
        
        Certification and qualification
        
        Current safety standards such as ISO 26262, DO-178B/C, IEC-61508, EN-50125 and others require identifying potential functional and non-functional hazards and demonstrating that the software does not violate the relevant safety goals.
        
        Abstract-interpretation based tools such as aiT, StackAnalyzer, and Astrée provide formal verification with 100% complete and reliable results. They are therefore perfectly suited to be used for certification.
        
        The qualification process is greatly simplified by our Qualification Support Kits. Additionally, Qualification Software Life Cycle Data Reports provide details about our development processes.
        
        qui a pour client Airbus et pour partenaire Esterel Technologies. ;-) Pour Airbus, ils utilisent leurs analyseurs statiques de code (aiT analyse le comportement temporel, StackAnalyzer l'absence de stack overflow et Astrée l'absence de runtime error) :
        
        For many years Airbus France has been using aiT, StackAnalyzer and Astrée in the development of safety-critical avionics software for several airplane types, including the A380, the world’s largest passenger aircraft. The analyzers are used as part of certification strategy to demonstrate compliance to DO-178B, up to Level A.
        
        et Compert C s'incrit dans la chaîne des outils : si le code C est propre et garanti c'est bien, mais si le compilateur introduit un bug c'est un peu couillon, tu ne crois pas ?
        
        Je crois que je peux te répondre la même chose, mais pas pour le même domaine.
        
        T'es sûr ? Tu faisais (ou fais) quoi comme travail chez Esterel ? Tu y appris quoi chez eux pour avoir écrit cela ?
        
        Les exemples de preuve sont très matheux. Cela ne ressemble pas à des preuves "industrielles" (à base de bout de spec, de bout d'exemple, de ne "plante jamais", a un temps d'exécution borné).
        
        T'as pas compris depuis le temps que ce tu qualifies de "industrielles", ce sont aussi des preuves de matheux ? ;-)
        
        Tu devrais tout de même jeter un œil à la vidéo de Xavier Leroy dont j'ai donné le lien au-dessus, il y parle pendant une vingtaine de minutes du milieu de l'avionique et de ses exigences de certification.
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Nicolas Boulay (site web personnel) le 23 octobre 2017 à 12:22. Évalué à 1.
        
        (si il y a un problème dans le code compilé, il se trouve déjà dans le code C).
        
        Le bug peut être également dans le model. J'imagine que pour vérifier le comportement du C par rapport aux instructions assembleur, il faut modéliser ses instructions, ce qui n'est pas forcément simple.
        
        si le code C est propre et garanti c'est bien, mais si le compilateur introduit un bug c'est un peu couillon, tu ne crois pas ?
        
        J'adore ta condescendance, tu n'a aucune idée de comment le problème est géré actuellement dans de vrai projet, mais tu la ramènes quand même.
        
        T'es sûr ? Tu faisais (ou fais) quoi comme travail chez Esterel ? Tu y appris quoi chez eux pour avoir écrit cela ?
        
        J'ai entre autre appris, que les spécialistes métiers ne sont pas des informaticiens et encore moins des matheux. Et que pour décrire leur système, ils ne veulent surtout pas avoir à faire à ce genre de concept. Ils veulent pouvoir décrire des problème spécifique, les exemples de why3 dont parlait mon commentaire, n'ont aucun rapport avec des problèmes industriels.
        
        T'as pas compris depuis le temps que ce tu qualifies de "industrielles", ce sont aussi des preuves de matheux ? ;-)
        
        Tu n'as compris que la forme était le plus important pour travailler avec un tel outil, pour la compréhension même de ce qu'ils font d'un point de vue métier. C'est le sujet du journal.
        
        Tu devrais tout de même jeter un œil à la vidéo de Xavier Leroy dont j'ai donné le lien au-dessus, il y parle pendant une vingtaine de minutes du milieu de l'avionique et de ses exigences de certification.
        
        C'est sûr, ce n'est pas comme si je n'avais pas déjà certifié 2 ou 3 logiciels.
        
        "La première sécurité est la liberté"
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par kantien le 23 octobre 2017 à 16:13. Évalué à 5.
        
        Je crois bien que le ton de nos échanges est monté par ma faute, j'en suis désolé. J'étais mal luné l'autre jour, j'aurais du tourner mes doigts dix fois avant d'écrire, j'en suis désolé. :-/
        
        Le bug peut être également dans le model.
        
        Tout à fait, mais cette problématique est hors de portée de la logique et des approches formelles.
        
        Cette partie de la logique de notre connaissance peut donc être nommée analytique, et elle est la pierre de touche, du moins négative, de la vérité, puisqu'il faut d'abord contrôler et estimer d'après ces règles toute connaissance selon sa forme, avant de l'examiner selon le contenu pour établir si, à l'égard de l'objet, elle contient une vérité positive. Mais, comme la simple forme connaissance, aussi d'accord qu'elle puisse être avec les lois logiques, ne suffit (nullement) pour établir la vérité matérielle (objective) de la connaissance, personne ne peut se hasarder de juger des objets avec la simple logique, et à en affirmer quelque chose, sans en avoir entrepris auparavant une étude approfondie en dehors de la logique, pour ensuite essayer simplement de les utiliser et de les lier en un tout cohérent selon les lois logiques, mieux encore, des les examiner simplement d'après elle. Cependant, il y a quelques choses de séduisant dans la possession d'un art aussi spécieux, celui de donner à toute nos connaissances la forme de l'entendement, quelque vide et pauvre qu'on puisse être à l'égard de leur contenu, que l'on use de cette logique générale, qui est simplement un canon pour l'évaluation, comme d'un organon pour produire réellement, du moins en en donnant l'illusion, des affirmations objectives, ce qui est en fait abuser de cette logique.
        
        Kant, Critique de la Raison Pure.
        
        La partie graissée correspond à ce que tu dis : si l'erreur est dans le modèle (le contenu, la matière), la logique qui ne s'occupe que de la forme ne peut rien y faire. Pour grossir le trait, la logique n'a rien à reprocher au raisonnement suivant :
        
        les hommes sont immortels
        
        or je suis un homme
        
        donc je suis un immortel
        
        celui qui se croirait immortel, en se justifiant du fait que la logique ne trouve rien à redire à ce syllogisme, ferait rire n'importe qui face à lui. :-D
        
        Pour faire une analogie avec le domaine juridique : la logique s'occupe des vices de forme dans la procédure. En l'absence de vice de forme, il faut tout de même un procès pour débattre de l'issue du cas : on y examine la question de droit (la majeure du raisonnement : les hommes sont immortels) et la question de fait (la mineure du raisonnement : je suis un homme). Ici, la majeure est en tort : l'accusé est innocenté, déclaré non coupable, ou plutôt non immortel. La question de fait en revanche ne fait ici pas de doute; en cas de non lieu c'est celle-ci qui n'a pu être justifiée.
        
        J'imagine que pour vérifier le comportement du C par rapport aux instructions assembleur, il faut modéliser ses instructions, ce qui n'est pas forcément simple.
        
        Tout à fait : c'est bien pour cela que je parlais d'un travail de titan ! Il faut formaliser les instructions assembleurs (de trois architectures qui plus est : PowerPc, ARM et x86), formaliser la sémantique d'un sous-ensemble assez large du C, puis prouver que toutes les transformations-traductions du code préservent les sémantiques. Mais Xavier Leroy et son équipe on pu réaliser cet exploit (car s'en est un, une première au monde pour un compilateur) parce qu'ils avaient déjà un forte expérience dans l'écriture de compilateur et de sémantique des langages de programmation : ils en avaient entrepris auparavant une étude approfondie en dehors de la logique. ;-)
        
        J'adore ta condescendance, tu n'a aucune idée de comment le problème est géré actuellement dans de vrai projet, mais tu la ramènes quand même.
        
        Nulle condescendance dans mon message, je mets cette réaction sur le dos du ton que prenaient nos échanges. Je ne suis pas sans savoir comment cette question est gérée en l'absence d'un tel outil, mais je tiens à signaler que la garantie que CompCert apporte sera à jamais inaccessible à ces méthodes. Raison pour laquelle Gérard Berry, qui n'ignore pas non plus ces méthodes, a écrit :
        
        Il s’est agi de réaliser un compilateur du langage C qui soit non plus certifié seulement pour la qualité des méthodes de développement et de test comme dans la norme DO-178C, mais bel et bien prouvé mathématiquement correct et donc vraiment garanti sans bugs.
        
        Le graissage est de moi pour bien souligner que les méthodes auxquelles tu fais allusion, si elle sont acceptées en pratique, ne pourront jamais apporter ce niveau de garanti (j'espère que tu m'épargneras un débat épistémologique sur la distinction entre la connaissance rationnelle et la connaissance expérimentale afin de justifier cette position).
        
        Je tiens à préciser à nouveau que ce compilateur fait partie de la chaîne d'outils que AbsInt vend à ses clients dont Airbus. :
        
        Check your C code for runtime errors with Astrée.
        
        Compile the code using CompCert
        
        Check your stack usage with StackAnalyzer
        
        Analyze the execution time with aiT
        
        Tu n'as compris que la forme était le plus important pour travailler avec un tel outil, pour la compréhension même de ce qu'ils font d'un point de vue métier.
        
        Bien sûr que j'ai le compris : un tel outil doit savoir cacher ses entrailles pour exposer à l'utilisateur ses concepts métiers pour qu'il se focalise sur ce qu'il connaît. Il n'empêche que sous le capot, c'est de la traduction mathématique et de la preuve mathématique, quand bien même l'utilisateur n'en a pas conscience. Un bon outil est celui qui sait se faire discret sur son fonctionnement : celui qui l'utilise, celui qui le construit et celui qui le répare sont rarement les mêmes personnes, n'ont pas les même savoir, ni les mêmes compétences.
        
        D'ailleurs pour illustrer la chose : je ne connaissais pas Go, si ce n'est de nom. Résultat je suis allé jeter un coup d'œil, et bien je trouve leurs choix tout sauf bêtes contrairement à ce que certains ont pu dire. Il n'y a certes pas de généricité (sauf sur quelques types comme les tuples ou les tableaux) mais leur système de type interface est très ingénieux et semble compenser allègrement à l'usage l'absence de généricité. D'un point de vue formel, au premier abord (je n'ai pas creusé plus que cela) ça s'apparente grandement à des fonctions avec arguments implicites sur du lambda-calcul simplement typé avec enregistrements (un langage avec des fonctions comme citoyen de première classe pour lequel un argument de certaines fonctions est inférer par le compilateur)¹. Le polymorphisme au lieu d'être paramétrique (comme C++, Java, Haskell…) et ad-hoc mais vérifier à la compilation. Choix qui offre aux développeurs un large panel de technique de programmation sans l'assomer avec des abstractions difficiles à comprendre, donc à maîtriser et donc à utiliser (comme le sont les modules ou les GADT pour toi).
        
        Haskell a cela avec ses type classes, mais OCaml manque d'un tel dispositif ce qui rend un code qui fait un usage intensif de modules très vite incompréhensible pour celui qui n'en est pas l'auteur. ↩
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Dinosaure (site web personnel) le 23 octobre 2017 à 16:53. Évalué à 1.
        
        Juste concernant Go, il me semble que l'approche (en tout cas des critiques que j'ai pu lire ici et là) n'est pas type-safe dans le sens où interface{} serait en réalité le type top comme la classe Object en Java - ce qui permet de facilement bypasser le système de type de Go.
        
        Alors, j'ai pas trop cherché à appliquer ça chez moi (si c'est encore d'actualité d'ailleurs) cependant, c'est plutôt une approche qu'on devrait éliminer quand on souhaite faire du bon code - cela revient au void * en C.
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Nicolas Boulay (site web personnel) le 23 octobre 2017 à 17:54. Évalué à 3.
        
        Je pense que pour vraiment se passer de interface{}, il faudrait de l'inférence de type à la place, ce qui n'est pas gagné.
        
        "La première sécurité est la liberté"
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par anaseto le 23 octobre 2017 à 20:10. Évalué à 2. Dernière modification le 23 octobre 2017 à 20:15.
        
        C'est pas vraiment le void * de C. En soi, utiliser interface{} est type-safe : ce qui n'est pas type-safe (au sens crash à la Python, pas au sens tu as carte blanche pour faire n'importe quoi comme en C), c'est l'assertion de type qui accompagne souvent les utilisations de interface{} côté utilisateur lors de l'utilisation d'un conteneur générique.
        
        Notons que, dans ces cas là, au prix d'un peu de verbosité, il est facile d'isoler ces assertions en faisant un wrapper des fonctions de la librairie qui n'utilise pas interface{}, ce qui en pratique mitige quand même pas mal les risques d'erreur.
        
        D'autant plus qu'à la base, ça représente déjà quand même pas grand chose comme proportion du code : je viens de faire un grep sur un de mes projets et les assertions de type ou switch sur des types représentent 0.1% du code (une ligne sur mille), c'est peut-être pas représentatif d'autres projets, mais peut-être même en pire, parce que j'ai pas fait particulièrement d'efforts pour réduire leur nombre : je me rends compte qu'en utilisant la méthode du wrapper je pourrais diviser leur nombre par à peu près deux.
        
        Bref, le méchant interface{} est à relativiser grandement : je pense qu'un projet quelconque Haskell ou OCaml a bien plus de 0.1% de code utilisant des exceptions (ou autre code sensible) à vérifier avec tout autant d'attention.
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par gasche le 24 octobre 2017 à 13:43. Évalué à 3.
        
        L'argument sur le nombre d'occurrences de type-switches n'est pas très convaincant : il suffit que quelques bibliothèques de base l'adoptent en interne, et tout le code qui s'en sert a perdu l'information de typage entre ce qui entre dans ces bibliothèques et ce qui en sort. Ce qui va probablement se passer, à court ou moyen terme, puisque c'est une propriété de la généricité d'être plus utile dans les bibliothèques de base (ou alors on s'en passe et le code devient plus lourd, plus redondant).
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Nicolas Boulay (site web personnel) le 24 octobre 2017 à 13:55. Évalué à 4.
        
        Oui, c'est la merde pour ça. Je code avec gokit, et je souffre.
        
        ex: https://github.com/go-kit/kit/blob/master/examples/shipping/routing/proxying.go
        
        Il y a 36 wrappers à écrire pour masquer les interface{}.
        
        "La première sécurité est la liberté"
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par anaseto le 24 octobre 2017 à 14:42. Évalué à 3.
        
        L'argument sur le nombre d'occurrences de type-switches n'est pas très convaincant
        
        Non, c'est juste pour relativiser un peu, et ça dit quand même qu'en pratique le nombre de fois où on perd l'information de types est peut-être pas énorme, qu'on aille pas croire qu'en Go on a les mêmes garanties statiques qu'en Python :)
        
        il suffit que quelques bibliothèques de base l'adoptent en interne, et tout le code qui s'en sert a perdu l'information de typage entre ce qui entre dans ces bibliothèques et ce qui en sort.
        
        Statiquement, oui, mais à supposer qu'il n'y a pas de bugs dans les bibliothèques de base, cloisonner la chose avec des fonctions safe, par exemple pour utiliser la structure générique de tas :
        
        func (pq *PriorityQueue) SafePush(item *Item) { heap.Push(pq, item) } func (pq *PriorityQueue) SafePop() *Item { return heap.Pop(pq).(*Item) }
        
        limite quand même pas mal les dégâts si on va s'en servir souvent, au prix d'une légère verbosité avant première utilisation.
        
        Ce qui va probablement se passer, à court ou moyen terme, puisque c'est une propriété de la généricité d'être plus utile dans les bibliothèques de base (ou alors on s'en passe et le code devient plus lourd, plus redondant).
        
        La philosophie du langage, c'est quand même d'encourager l'utilisation des tableaux dynamiques et tables de hachage avec généricité ad hoc, en s'inspirant de ce que font souvent les langages dynamiques. On fait quand même beaucoup avec, mais c'est pas adapté à tous les programmes. Si une bonne partie du programme est dédiée à utiliser diverses structures génériques moins courantes, Go n'est sans doute pas le bon choix. Normalement, on voit quand même venir le mur à temps :) Après, que des gens soient fâchés d'utiliser Go alors que ce n'est pas adapté parce que le boss dit que, ça, ça peut devenir triste, ça arrive sans doute déjà, mais c'est une autre histoire, et c'est pas nouveau.
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par gasche le 24 octobre 2017 à 16:17. Évalué à 4.
        
        Sur le thème du "ah oui mais utiliser des outils pas adaptés c'est pas bon, on le savait déjà", personellement je trouve qu'il y a quand même une différence de fond entre la généricité, qui me semble être une caractéristique inhérente à la programmation, et le fait de bien couvrir ou pas tel ou tel domaine applicatif par exemple. C'est une chose de dire "t'aurais pu le savoir que faire des logiciels de trading haute-fréquence en PHP c'est une mauvaise idée" : le domaine applicatif vient avec tout un tas de contraintes (volumes de données, temps de latence, etc.) dont on peut raisonnablement dire : "tel langage risque de coincer" ou, dans l'autre sens, "il y a une chance d'avoir ce domaine dans le logiciel que je veux construire et faire évoluer" (on peut se retrouver à avoir besoin de choses qu'on n'avait pas prévu au départ, mais on a quand même une vague idée d'ensemble).
        
        À l'inverse, "avoir besoin d'une structure de donnée générique", c'est un besoin qui me semble pouvoir apparaître dans tous, mais alors vraiment tous les domaines applicatifs. Ce n'est même pas un besoin qui diminue quand on a une application de petite taille (contrairement au "j'ai besoin de refactorer mon code et je ne sais plus si ça marche" qui est critiqué pour certains langages dynamique), puisqu'il peut apparaître quand on choisit d'utiliser une bibliothèque tierce pour construire notre petit programme.
        
        Bien sûr, une des raisons d'être de la recherche en systèmes de typage vient du fait que, quel que soit le système, il y a des formes de généricité plus avancées encore qu'on risque d'empêcher. (Si tu as les génériques, il faut se mettre à réfléchir à la variance et on préfère éviter les wildcards; ou alors au polymorphisme de sorte supérieure, etc.) Donc tous les langages typés sont, dans une certaine mesure, confrontés à ce problème. Mais je pense que "structure de données génériques" est quand même un besoin de généricité qui va apparaître particulièrement tôt et souvent.
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par anaseto le 24 octobre 2017 à 17:23. Évalué à 2.
        
        Je sais pas, c'est quelque chose sur quoi ce serait intéressant d'avoir des stats : suivant le type d'application, quel pourcentage de code (ou autre façon plus pertinente de mesurer l'impact) cela représente, soit par redondance (technique on réinvente la roue/copie-colle), soit à la Python (technique assertion de type), ou génération (à la lex/yacc), sachant qu'on dispose quand même d'un minimum de généricité ad hoc et d'interfaces.
        
        Avant de programmer en Go, j'aurais dit, beaucoup (où sont mon fold, map, filter ?). Maintenant, je dirais pas vraiment significatif quand on voit le programme dans son ensemble, mais je me risquerais pas à généraliser mes cas d'usages particuliers, surtout que je dois avoir écrit à peine une quinzaine de milliers de lignes de code dans ce langage, pas beaucoup, donc mon évaluation est tout autant subjective, probablement :)
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par kantien le 25 octobre 2017 à 09:30. Évalué à 2. Dernière modification le 25 octobre 2017 à 09:32.
        
        Juste concernant Go, il me semble que l'approche (en tout cas des critiques que j'ai pu lire ici et là) n'est pas type-safe dans le sens où interface{} serait en réalité le type top comme la classe Object en Java - ce qui permet de facilement bypasser le système de type de Go.
        
        C'est type-safe le interface{}, c'est un type existentiel. Par contre tu perds la garantie du typage statique et tu dois faire des assertions de type ou du switch sur type : il faut faire du typage dynamique. C'est comme en Python, en somme, sauf qu'en dehors de interface{} on a bien la garantie d'un typage statique (sans quantification universelle sur les types, c'est-à-dire, sans généricité mais c'est déjà pas trop mal). En gros, je le vois comme ça (je me trompe peut être) :
        
        type intf = E : 'a -> intf let i = E 1
        
        mais comme Go garde des informations de typages au runtime, on peut retrouver à l'éxecution la valeur contenue dedans avec son type : pour Go, i est de type int et vaut 1.
        
        var i interface{} i = 1 fmt.Printf("i est de type %T et vaut %v", i, i) // affiche : i est de type int et vaut 1
        
        Ce qui n'est pas type-safe, c'est une valeur de tout type (avec quantification universelle sur les types). On parle de l'aspect unsound du système de type de Java (qui a des génériques) ou de la valeur undefined de Haskell ?
        
        type contradiction = {faux : 'a. 'a} let i = {faux = Obj.magic 1};; val i : contradiction = {faux = <poly>}
        
        Là, on contourne clairement le système de types, mais on annonce la couleur en utilisant le module Obj. ;-) Le type de faux, c'est le principe ex falso quodlibet.
        
        Par contre j'ai un peu trop surestimé le système des interfaces : j'ai cru que c'était du type classes à la Haskell mais sans types paramétriques. En fait non, c'est clairement moins bien fait, tu ne peux pas avoir d'interface pour de telles méthodes :
        
        type Vertex struct { X, Y float64 } func (v *Vertex) Add(w *Vertex) Vertex { return Vertex{v.X + w.X, v.Y + w.Y} } func Add(v Vertex, w Vertex) Vertex { return v.Add(&w) } func main() { v := Vertex{3, 4} w := Vertex{5, 9} fmt.Println(Add(v,w)) } // affiche {8 13}
        
        On ne peut pas définir le type interface de ceux qui implémentent la méthode Add : c'est nul et ça pourrait limiter le besoin de recourir à interface{}. Déjà qu'il n'ont pas de génériques (types paramétriques), ils auraient pu faire un effort de ce côté là.
        
        En OCaml :
        
        type 't add = { add : 't -> 't -> 't; } type vertex = {x : float; y : float} let add_vert = {add = fun v w -> {x = v.x +. w.x; y = v.y +. w.y}};; val add_vert : vertex add = {add = <fun>} let add_int = {add = (+)};; val add_int : int add = {add = <fun>} let add {add} x y = add x y;; val add : 'a add -> 'a -> 'a -> 'a = <fun> add (add_vert) {x =3. ; y = 4.} {x = 5. ; y = 9.};; - : vertex = {x = 8.; y = 13.} add (add_int) 3 4;; - : int = 7
        
        Le mécanisme des arguments implicites (s'il était implémenté) permettrait d'inférer automatiquement le 'a add à utiliser en fonction du type 'a des autres paramètres passés à add par unification, là où pour l'instant on doit le passer explicitement (c'est ce que font les types classes de Haskell mais en plus général, les types pouvant être paramétriques comme avec les monades). Go fait cela mais de manière très restreinte : la variable de type 't ne doit pas apparaître dans le type des champs de l'enregistrement. /o\
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par kantien le 25 octobre 2017 à 09:51. Évalué à 2.
        
        Petit ajout que j'ai oublier de préciser avec le type contradictoire.
        
        type contradiction = { faux : 'a. 'a; } let i = {faux = Obj.magic 1};; val i : contradiction = {faux = <poly>} (* là c'est bon *) 1 + i.faux;; - : int = 2 (* là ça segfault !! *) 1.5 +. i.faux;;
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Thomas Douillard le 24 octobre 2017 à 13:16. Évalué à 2.
        
        La logique peut aussi vérifier la cohérence interne des connaissances des experts sur leur sujet. Mais effectivement elle va pas créer ex nihilo le modèle métier ou une théorie scientifique. Ça mettrai un paquet d’universitaires et d’informaticiens au chomage :) Mais du point de vue de la cohérence, ça peut lever des lièvres.
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Nicolas Boulay (site web personnel) le 24 octobre 2017 à 13:33. Évalué à 3.
        
        Le "modèle métier" se confronte toujours à une simulation. D'ailleurs, j'imagine qu'un jour les IA s'amuseront directement avec ce genre de simulateur.
        
        "La première sécurité est la liberté"
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Thomas Douillard le 24 octobre 2017 à 16:17. Évalué à 4.
        
        Moué, ça se voit la que tu racontes n’imp.
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Nicolas Boulay (site web personnel) le 24 octobre 2017 à 16:37. Évalué à 3.
        
        J'ai un peu trop divergé je suis d'accord.
        
        La logique peut aussi vérifier la cohérence interne des connaissances des experts sur leur sujet.
        
        Pour ça, il faut un "modèle du monde", ce qui n'existe jamais. C'est le boulot de dingue qui consiste à modéliser toutes les instructions assembleur dans compcert. Donc, non, tu n'as rien de facile sous la main pour confronter ce qu'écrit une personne du métier. Ce qui est typiquement fait, c'est d'utiliser des simulateurs maisons ou pas. Une équipe du métier conçoit un nouveau logiciel de pilote automatique, il va simuler des scénarios pour le valider. Il n'y a pas de règles statiques pour valider qu'il fait n'importe quoi dans certain cas. Dans le cas de ingénierie des modèles, on peut toujours écrire des règles qui permettent de vérifier certaine propriété, c'est forcément limité.
        
        L'autre info c'est de voir le renforcement de alphagoZero en jouant contre lui-même en simulant des parties. Il devrait en théorie être possible de faire une IA qui apprend en utilisant un simulateur. C'est très théorique, je suis d'accord, mais cela serait la porte d'entré de l'IA dans l'ingénierie.
        
        "La première sécurité est la liberté"
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Thomas Douillard le 24 octobre 2017 à 17:14. Évalué à 3.
        
        Ben non justement, vérifier la cohérence interne veut dire que tu vérifie sans faire référence au monde extérieur que tes spécifications se tiennent elles mêmes et ne sont pas contradictoire en soi. Puis que ton programme est bien cohérent avec les spécifications.
        
        Imagine que différents secteurs de l’entreprise aient différentes représentation d’un même produit. Elles n’ont pas la même vision, le service design, le service compta et le service marketing n’ont pas besoin des mèmes informations. Le SI peut par contre vérifier qu’il y a une certaine cohérence entre ces représentation.
        
        En terme de cohérence, un ami m’a par exemple parlé d’un client promoteur en indiquant que le client voulait pas vraiment être sur que la surface disponible dans un immeuble était égale à la somme des surface des appartements. Dans le cas d’un client honnête, si il recherche à maintenir cette propriété, il est possible de vérifier que le programme garantit qu’un employé ne va pas aller tricher avec les données en bidouillant n’importe comment.
        
        Le « modèle métier » c’est plutôt le modèle qui va te dire qu’un avion a en général deux ailes chez Airbus, ou que le débit et le crédit d’un compte bancaire doivent s’équilibrer chez un comptable.
        
        Et c’est indépendant de la correction du compilateur, vu que c’est la cohérence «interne». La correction du compilateur garantit que ces propriétés seront préservées par la compilation.
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Nicolas Boulay (site web personnel) le 24 octobre 2017 à 17:35. Évalué à 3.
        
        Dans les faits, la cohérence interne que tu peux vérifier est assez faible. Comme les gens détestent écrire les choses 2 fois, tu te retrouves à faire des calculs avec des données que tu as déjà, plutôt que vérifier que 2 valeurs sont cohérentes.
        
        Pour l'exemple que tu donnes, cela tombe exactement dans ingénierie des modèles et le genre de petites règles que tu peux écrire. C'est très utile, tu peux augmenter très largement la productivité des utilisateurs. Mais tu ne vérifies pas de cohérence en soi, tu écris la règle elle-même. On est très loin d'une "vérification formelle".
        
        "La première sécurité est la liberté"
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Thomas Douillard le 24 octobre 2017 à 18:10. Évalué à 3.
        
        Ici, dans la recherche en langage de programmation, ils cherchent à encoder pas mal de choses dans les types. Ils ne seraient pas fâchés que par exemple on puisse coder ces règles métier dans les types, je pense. C’est un peu différent dans l’approche mais la méthode B permet d’en spécifier formellement dans l’invariant. Le truc pour ne pas avoir l’impression d’écrire plusieurs fois la même chose, c’est que la spec soit déclarative et de plus haut niveau que le code. Genre que la sortie d’une fonction qui a la propriété de trier c’est que chaque élément est inférieur au suivant. Ça te laisse complètement le choix de la manière de trier et ça va t’engueuler si t’as commenté l’appel au tri par erreur.
        
        Si tu écris du code qui respectent pas ces règles encodées, l’objectif c’est que ça ne compile pas. Si tu écris deux règles qui sont incompatible l’une avec l’autre, logiquement, l’objectif est que ça te dise « t’es bien mignon mais c’est impossible de maintenir la propriété que la somme des surface est la somme de l’immeuble si tu modifie pas la taille de l’immeuble quand tu modifie la taille d’un appart » et que ça compile pas, itou. Ou alors que le département vente et le département fabrication utilisent pas la même notion de surface et que donc, les règles sont incohérentes et qu’il faut préciser le modèle.
        
        Mais garde à l’esprit que c’est de la recherche en programmation qu’on parle ici. Il s’agit pas forcément d’avoir des choses utilisables dans la seconde.
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Nicolas Boulay (site web personnel) le 25 octobre 2017 à 11:01. Évalué à 3.
        
        Ils ne seraient pas fâchés que, par exemple, on puisse coder ces règles métier dans les types, je pense.
        
        ça dépend de la complexité conceptuelle.
        
        C’est un peu différent dans l’approche mais la méthode B permet d’en spécifier formellement dans l’invariant.
        
        Je ne sais pas ou en est la méthode B en est mais j'ai entendu parlé dans mes études (y a plus de 15 ans…), et le seul fait d'arme était le code de la ligne 14, avec les preuves écrites à la main. Si on peut vérifier automatiquement la cohérence des invariants, c'est top.
        
        Le truc pour ne pas avoir l’impression d’écrire plusieurs fois la même chose, c’est que la spec soit déclarative et de plus haut niveau que le code.
        
        Oui, la mode est au modèle. Genre SysML qui sert à générer du code ou autre configuration. Écrire un gros méta-modèle cohérent est par contre, vite très compliqué. Les invariants des modèles UML sont codés avec de l'OCL, qui vérifie les propriétés du modèles, mais rien ne permet de tester la cohérence des règles entre elles.
        
        Après avoir bosser quelques années la-dedans, je pense que le centre n'est pas le modèle, mais les transformations entre modèles. Quand tu as un modèle et que tu génères du code, un rapport, une config, ou que tu gères un diff, tu transformes toujours un modèle en un autre. Le Graal est la transformation bidirectionnelle partielle. Cela semble absurde, mais cela arrive tout le temps. En gros, il s'agit du même modèle sous-jacent, mais présenté sous des formes différentes qui suivent un standard précis (AADL, FACE, AUTOSAR,…), avec des outils différents pour travailler dessus. Des gens ont essayés de "mixer" ces modèles, ils ont eu des problèmes…
        
        Ça te laisse complètement le choix de la manière de trier et ça va t’engueuler si t’as commenté l’appel au tri par erreur.
        
        Je crois que les contrats de Smarteffel fonctionne ainsi. Cela reste de la vérification runtime, mais cela a de la valeur (= cela aide vraiment le codeur). Peut être qu'un code exécuté à la compilation pourrait garantir un certain nombre de propriété, mais les méta-compilateurs m'ont l'air bien compliqué à appréhender.
        
        L’exécution à la compilation est une sorte de "propagation de constante" qui fonctionne aussi avec les containers, cela pourrait peut-faire le job. Existe-t-il un langage qui permet de faire ça ? Les templates de C++ ne sont pas une bonne réponse.
        
        Ou alors que le département vente et le département fabrication utilisent pas la même notion de surface et que donc, les règles sont incohérentes et qu’il faut préciser le modèle.
        
        Je suis récemment tombé sur la méthode DDD (https://en.wikipedia.org/wiki/Domain-driven_design), son idée principale est que se mettre d'accord entre service ne passe pas à l'échelle, et est totalement illusoire. L'idée est de créer un "Bounded context" dont l'intérieur est laissé à l’appréciation de chaque équipe, seul les interfaces doivent être spécifiées en commun. Cela rejoint les préoccupations de découpage du code des micro-services, si tu en as entendu parler.
        
        Mais garde à l’esprit que c’est de la recherche en programmation qu’on parle ici. Il s’agit pas forcément d’avoir des choses utilisables dans la seconde.
        
        Bien sur. Disons que j'ai souvent l'impression que la recherche s'intéresse beaucoup à des domaines qui n'intéressent pas les codeurs. Je me rappelle d'un texte d'un codeurs linux qui lisait des papiers de recherche sur un problème précis d'OS qui était majoritairement monocpu, alors que cela n'existe presque plus, et pour des résultats non reproductibles. Je vois la recherche énorme autour du GADT que peu de personnes comprennent, et de l'autre yacc semble abandonné alors que l'on ne peut pas l'utiliser, si il faut générer de vrai messages d'erreur précis et complet. Ocaml semble avoir compris la valeur d'avoir des messages d'erreurs lisible, mais par contre, il n'a toujours pas de moyen simple d'utiliser du multi-core ou les instructions SIMD.
        
        Je n'ai pas vu non plus de recherche sur un langage pour la génération de code performant, c'est pourtant plus écologique d'avoir un code plus rapide. J'ai vu de la recherche sur la compilation du code C (la lib de transformation de boucle utilisé dans gcc), mais pas sur un langage qui permet au compilateur de mieux faire son boulot (unboxing facile, allocation mémoire minime, gestion des instructions assembleurs spécifiques facilités,…).
        
        La recherche semble aussi focaliser sur la recherche du langage ultime. Mais comment fait-on la migration des centaines de millions de lignes de code existantes ? Comment assurer une transition progressive ? Par exemple comment changer "online" le schéma d'une base de données sans perdre de donnée et pouvoir retourner en arrière si besoin ? Le cas général est terriblement complexe. Comment découper un gros code monolithe pour changer la technologie sous-jacente ? C'est un travail d'ingénieur, mais un outil automatique serait un travail de recherche (plus ou moins comme coccinelle). La manipulation du code vu comme une énorme data structurée ne semble pas à la mode.
        
        "La première sécurité est la liberté"
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par gasche le 26 octobre 2017 à 09:01. Évalué à 7.
        
        Je me rappelle d'un texte d'un codeurs linux qui lisait des papiers de recherche sur un problème précis d'OS qui était majoritairement monocpu, alors que cela n'existe presque plus, et pour des résultats non reproductibles.
        
        Moi je vois aussi que les développeurs du kernel sont très lents à intégrer des idées venant du monde de la recherche, qu'il faut un peu tout leur apporter déjà cuit. Je ne vais pas parler de la recherche en OS que je connais mal, mais sur les tests, il y a eu plein de progrès sur le test aléatoire (concoling testing, etc.), les devs kernels n'ont jamais fait d'effort pour adopter ça dans le noyau (par exemple : en demandant à la Linux Foundation de financer une collaboration avec des universitaires du sujet pour financer une thèse d'application au noyau), et attend que des ingénieurs recodent leurs solutions from scratch (les fuzzers qui commencent timidement à être utilisés dans le noyau). C'est encore pire pour la vérification de programmes / l'analyse statique, où le kernel Linux n'a rien en place, alors que le kernel Windows utilise des annotations riches qui sont vérifiées statiquement depuis des années—pour ce genre de projets il faut que les développeurs soient prêt à spécifier les annotations qui précisent la possession de la mémoire, les informations de taille de pointeurs, etc., on ne peut pas vérifier le code sans en changer une seule ligne.
        
        Je vois la recherche énorme autour du GADT que peu de personnes comprennent.
        
        Bien expliqué et bien implémenté, les GADTs ne sont pas très compliqués, et ils simplifient quand même un certain nombre de choses difficiles à faire sans (Menhir, par exemple, repose sur des GADTs, mais est implémenté avec des Obj.magic en interne car il a été développé avant que ça n'arrive dans le langage; la plupart des bibliothèques avec des types fantômes sont dans cette situation). Il y a des bouts importants de l'écosystème OCaml qui devraient être soit moins sûrs soit moins efficaces sans les GADTs.
        
        Ocaml […] n'a toujours pas de moyen simple d'utiliser du multi-core ou les instructions SIMD.
        
        En même temps (1) il y a peu de moyens "simples" d'utiliser le multi-core et (2) il y a de la recherche là-dessus depuis des années (dont maintenant de la recherche spécifiquement pour OCaml). C'est un peu pareil pour les instructions SIMD, si tu connais une façon simple de les ajouter au langage sans casser les garanties de sûreté du langage, raconte-nous.
        
        Je n'ai pas vu non plus de recherche sur un langage pour la génération de code performant.
        
        Pourtant il y en a plein, c'est peut-être juste que tu n'as pas regardé au bon endroit. LLVM me semble être un exemple, ou alors les travaux sur des DSLs qui se compilent bien vers des GPU par exemple. Si tu veux des références plus précises, peux-tu en dire plus sur ce que tu cherches ? (Quel genre de code ?)
        
        J'ai vu de la recherche sur la compilation du code C (la lib de transformation de boucle utilisé dans gcc), mais pas sur un langage qui permet au compilateur de mieux faire son boulot (unboxing facile, allocation mémoire minime, gestion des instructions assembleurs spécifiques facilités,…).
        
        Il y a pourtant eu pas mal de recherche sur des langages pour la programmation scientifique (X10, Fortress…) dont les aspects que tu mentionnes (à part l'assembleur je pense) étaient des aspects importants.
        
        La recherche semble aussi focaliser sur la recherche du langage ultime. Mais comment fait-on la migration des centaines de millions de lignes de code existantes ? Comment assurer une transition progressive ?
        
        Il y a des deux dans la communauté scientifique, des gens qui étudient la conception de meilleurs langages/outils (à utiliser dès le départ pour de futurs projets), et des gens qui cherchent à faciliter l'usage des langages existants malgré leurs défauts. Tu vas trouver le genre de choses que tu mentionnes chez les gens qui sont partisants de la seconde approche.
        
        Par exemple, Michael Hicks et ses collaborateurs à l'université du Maryland ont travaillé depuis 2001 sur le problème de "Dynamic Software Update" pour le C (et les langages proches de C) et le Java, donc la question de comment migrer d'une version à l'autre d'une application pendant qu'elle tourne (avec des problématiques proches de ta question sur les migrations de schéma de bases de données, qui j'imagine a aussi été très étudiée mais je ne connais pas la recherche en bases de données).
        
        (Maintenant il y aussi de la recherche sur la migration automatique de code en utilisant du machine learning, par exemple la recherche de Tien Nguyen à l'université du Texas.)
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Nicolas Boulay (site web personnel) le 30 octobre 2017 à 14:56. Évalué à 4.
        
        Je ne sais pas pourquoi j'avais raté ce message.
        
        Je crois que tu te trompes sur les dev kernel. En sécurité, la plus part des bugs sont trouvé avec des fuzzers. Concernant l'analyse statique, il existe https://en.wikipedia.org/wiki/Sparse qui permet de vérifier des propriétés statiques (gestion de mutex, d'espace mémoire, etc…).
        
        (1) il y a peu de moyens "simples" d'utiliser le multi-core
        
        Les goroutines sont déjà un bon exemple. Tout ce qui est bas sur le passage de message simple ou les "grosses" boucles d'openMP.
        
        C'est un peu pareil pour les instructions SIMD, si tu connais une façon simple de les ajouter au langage sans casser les garanties de sûreté du langage, raconte-nous.
        
        Je ne comprends pas trop la question. gcc fait de la vectorisation automatique depuis un bail. Il a aussi proposé simplement des tableaux de 4 flottants ou 8 entiers avec les opérations qui correspondent directement sous forme de fonctions transformés ensuite en assembleur. Qu'est-ce qu'il y a de problématiques de donner accès à des fonctions qui correspondent aux instructions assembleurs ?
        
        De plus, ocaml pourrait faire des map et fold sur des array de nombres, et proposer des versions vectorisés des opérations en question.
        
        LLVM me semble être un exemple, ou alors les travaux sur des DSLs qui se compilent bien vers des GPU par exemple. Si tu veux des références plus précises, peux-tu en dire plus sur ce que tu cherches ? (Quel genre de code ?)
        
        LLVM ? Dans quel domaine ? Je l'ai toujours vu comme un compilateur modulaire, mais qui n'arrive toujours au niveau de GCC en terme de perf. Pour les GPU, c'est openCL ou CUDA qui ressemble à du C pourris. Je n'ai pas vu de DSL. Un moment, j'avais vu la liborc qui proposait un pseudo assembleur qui avait un type de base "tableau" pour générer l'assembleur qui allait bien pour chaque architecture (x86,…).
        
        Il y a pourtant eu pas mal de recherche sur des langages pour la programmation scientifique (X10, Fortress…) dont les aspects que tu mentionnes (à part l'assembleur je pense) étaient des aspects importants.
        
        Forteress a l'air abandonné, je vais regarder X10 qui à l'air d'être un truc HPC pour du multicpu surtout.
        
        Michael Hicks et ses collaborateurs à l'université du Maryland ont travaillé depuis 2001 sur le problème de "Dynamic Software Update"
        
        Vivement qu'un outil soit créé alors.
        
        "La première sécurité est la liberté"
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par gasche le 31 octobre 2017 à 19:15. Évalué à 9.
        
        En sécurité, la plus part des bugs sont trouvé avec des fuzzers. Concernant l'analyse statique, il existe https://en.wikipedia.org/wiki/Sparse qui permet de vérifier des propriétés statiques (gestion de mutex, d'espace mémoire, etc…).
        
        Ces outils sont développés par les développeurs noyaux, qui n'ont pas en général de bagage en recherche dans le domaine concerné (test aléatoire, analyse statique). Au bout d'un moment ils pensent à un outil et ils en développent un from scratch pour leurs besoins. C'est une approche classique d'ingénieur et louable, mais les outils en question restent en général loin derrière l'état de l'art, les problèmes sur lesquels travaillent les chercheurs qui bossent dans le domaine. La recherche en analyse statique c'est Astrée par exemple, un outil qui prouve l'absence de comportement indéfini (segfault compris) dans l'ensemble du code de contrôle de certains Airbus. On est très, très loin devant Sparse en terme de puissance.
        
        Les développeurs du noyau Windows ont aussi des outils très fins, avec une vraie collaboration avec la communauté de recherche sur l'analyse statique de fonctions noyau et des kernels, qui demande des annotations utilisées en pratique par les développeurs; voir SAL 2.0 Annotations for Windows Drivers par exemple, ou l'énorme travail sur le "whitebox testing" des composants Windows et de .NET ( par exemple, https://www.microsoft.com/en-us/research/publication/pex-white-box-test-generation-for-net/ ).
        
        Ce que j'aimerais voir, si les développeurs Linux étaient plus ouverts au fait d'intégrer des résultats de recherche, c'est des outils qui sont développés pour le kernel par une collaboration d'universitaires et de développeurs noyaux actifs (il y a des chercheurs qui sont aussi développeurs noyaux). C'est le cas par exemple des travaux sur la formalisation du modèle mémoire de Linux et en particulier de RCU, qui est fait par un mélange d'universitaires et de développeurs—et il y a quelques développeurs qui se laissent parfois convaincre d'écrire des patches Coccinelle. Mais c'est très rare, ce n'est pas dans la culture de la communauté qui développe le noyau; c'est dommage.
        
        Bien sûr, les prototypes issus de la recherche ne sont pas utilisables en l'état sur un logiciel aussi gros et compliqué que le noyau. C'est pour ça qu'il faut une collaboration entre les deux communautés, pour que les universitaires aient des retours sur les besoins du noyau, soient forcés de rendre leurs outils plus généraux et plus faciles à utiliser sur de vrais projets, et aient aussi l'assurance qu'il y a des gens prêt à les adopter derrière, qu'un effort de passage à l'échelle ne sera pas fourni à perte. Encore une fois, pour ça il faut une culture volontaire du côté des développeurs, et elle manque pour le noyau Linux (alors qu'elle est présente pour Windows, en partie parce que Microsoft n'a pas laissé le choix à ses développeurs). On peut dire que beaucoup de développeurs ont déjà plein de boulot et n'ont pas le temps de jouer à tester des prototypes d'outils pour le noyau, mais encore une fois, c'est une question de priorité (des personnes, et des organisations : la Linux Foundation pourrait financer ce genre de travaux si elle en avait envie).
        
        Je n'ai pas vu de DSL.
        
        Un exemple concret, dans la communauté que je connais mieux (et qui n'est pas celle qui travaille le plus sur la génération de code efficace, c'est plutôt un à-côté pour nous), serait Generating performance portable code using rewrite rules: from high-level functional expressions to high-performance OpenCL code par Michel Steuwer, Christian Fensch, Sam Lindley, et Christophe Dubach, 2015. Ils définissent un petit langage très simple pour composer des expressions qui décrivent des calculs sur GPU, et une façon de le compiler qui donne des programmes qui vont plus vite que des versions écrites à la main par des experts. Par exemple le code pour décrire une multiplication matrice/vecteur (GEMV en BLAS) dans ce langage est
        
        scal = λa. map (∗a) asum = reduce (+) 0 ◦ map abs dot = λxs ys. (reduce (+) 0 ◦ map (∗)) (zip xs ys) gemv = λmat xs ys α β. map (+) (zip (map (scal α ◦ dot xs) mat) (scal β ys))
        
        et le résultat de la compilation va un peu plus vite que les bibliothèques fournies par les vendeurs de GPU (CUBLAS sur un GPU Nvidia, clBLAS sur un GPU AMD, et la MKL pour un CPU Intel), et est entre 2 et 5 fois plus rapide qu'une implémentation OpenCL portable selon la machine sur laquelle on la fait tourner.
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Nicolas Boulay (site web personnel) le 01 novembre 2017 à 10:10. Évalué à 5.
        
        Concernant Astrée, j'imagine que c'est le genre d'outil qui peut généré un paquet de faux positif. Par exemple, si il détecte trop "simplement" la division. Sparse ne génère pas de faux positif si je me rappelle bien. Si il ne fonctionne bien qu'avec un code généré par SCADE, il y a une gros soucis (sachant que SCADE génère un C restreint ayant déjà beaucoup de bonnes propriétés).
        
        Coverity propose une analyse de code open source. ( https://www.synopsys.com/software-integrity/resources/analyst-reports/open-source-software-scan-report.html ) Cela a été à la mode pendant un moment, puis les devs en ont eu marre des faux positifs dont la corrections pouvaient entrainée des problèmes subtiles (genre générateur de nombre aléatoire de Debian). Je ne connais pas la différence avec Astrée, mais Sparse a été développé ensuite.
        
        Encore une fois, pour ça il faut une culture volontaire du côté des développeurs, et elle manque pour le noyau Linux (alors qu'elle est présente pour Windows, en partie parce que Microsoft n'a pas laissé le choix à ses développeurs).
        
        Le milieu Open Source ne fonctionne pas comme ça. Celui qui apporte une nouvelle techno doit démontrer sa supériorité pour convaincre. Dire "venez avec moi, cela va être génial", cela fait 20 ans, que les développeurs Kernel l'entendent tous les jours. Et au dernière nouvelles les drivers Windows ne fonctionnent pas mieux que les drivers Linux.
        
        En gros, c'est à la communauté de la recherche de prouver que leur approche est meilleur, si vous considérez que les dev sont bêtes parce qu'ils ne vous écoutent pas, c'est mal barré.
        
        Par exemple le code pour décrire une multiplication matrice/vecteur (GEMV en BLAS) dans ce langage est
        
        L'idée est sympa. J'imagine que les usagers de ce genre de DSL sont docteur en mathématique pour le calcul linéaire. Je ne vois pas qui d'autres pourraient s'en servir vu le formalisme mathématique retenu.
        
        "La première sécurité est la liberté"
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par gasche le 01 novembre 2017 à 11:27. Évalué à 6.
        
        Tu as raison sur le fait que les faux positifs sont un problème sur ces outils, et c'est pour cela qu'il faut une vraie collaboration entre les chercheurs qui travaillent sur ces outils et les utilisateurs intéressés, pour comprendre ce qui marche et ne marche pas, et faire des développements souvent délicats (nécessitant de la nouvelle recherche) pour améliorer les problèmes révélés par l'expérimentation sur le logiciel—ici le kernel.
        
        Les gens de Facebook ont racheté une startup de recherche qui travaillait sur des outils d'analyse automatique de sûreté mémoire, c'est devenu Infer et c'est utilisé en production sur les codebases de Facebook. Si on peut le faire pour le logiciel (client) de Facebook et le kernel Windows, il n'y a pas de raison qu'on ne puisse pas y arriver pour le kernel Linux, mais encore une fois, ça demande une volonté et une culture favorable dans le projet.
        
        Et au dernière nouvelles les drivers Windows ne fonctionnent pas mieux que les drivers Linux.
        
        Je pense que tu mets la tête dans le sable quand tu dis ça. Je n'ai pas trouvé de données sur le taux de bugs dans les drivers Windows, mais c'est insensé de penser que déployer de l'analyse statique sérieuse sur les drivers et le code du kernel ne donne pas, à long terme, un avantage clair sur la qualité logicielle.
        
        Le milieu Open Source ne fonctionne pas comme ça.
        
        Décide qui ? Moi aussi je fais partie du milieu Open Source, et je dis ce qu'on ne fait pas bien et qu'on devrait faire mieux : on devrait mettre en place une culture d'interaction réelle avec le milieu universitaire. Il y a des projets qui ont l'intelligence de le faire (Mozilla par exemple, d'abord avec leur travail sur l'analyse statique de la codebase C++ de Firefox, et ensuite avec le développement de Rust). Je ne vois pas pourquoi ce serait incompatible avec "l'Open Source" de travailler avec des universitaires alors que Microsoft et Apple le font largement. Au contraire, l'idée d'ouverture à la base du développement libre est très proche et très compatible avec l'idée d'ouverture inhérente à la recherche universitaire publique; tous les projets libres n'ont pas les moyens financier de favoriser ces contacts, mais le noyau Linux est un projet qui les aurait (à travers la Linux Foundation par exemple) si l'envie existait.
        
        Celui qui apporte une nouvelle techno doit démontrer sa supériorité pour convaincre.
        
        Non mais la façon dont tu présentes les choses c'est que la recherche devrait arriver avec des outils tout cuits qui sont déjà passés à l'échelle pour pouvoir s'appliquer au noyau Linux ou à des projets conséquents. Devrait implémenter des compilateurs qui génèrent du meilleur code que Gcc. Et après seulement on discute. C'est idiot, ce n'est pas réaliste pour des universitaires de développer un produit fini (ce n'est pas leur rôle et leur métier) sans savoir s'il y a une volonté pour l'utiliser derrière. Cette mentalité fait partie de la culture aujourd'hui qui est défavorable à ces collaborations.
        
        En gros, c'est à la communauté de la recherche de prouver que leur approche est meilleur, si vous considérez que les dev sont bêtes parce qu'ils ne vous écoutent pas, c'est mal barré.
        
        Moi je dis qu'il doit y avoir un effort, du travail et une volonté des deux côtés—s'il n'y a pas une vraie envie de travailler ensemble, "c'est mal barré" comme tu dis. Ça fait 20 ans que c'est mal barré et ça n'a pas l'air de s'améliorer (parmi les développeurs LLVM actifs il y en a un, Nuno Lopes, qui est prêt à pousser les efforts de recherche sur LLVM, grosse victoire !). Je peux dire que "c'est bête" avec confiance, en effet. C'est bête de ne pas vouloir entendre qu'il faut de vrais efforts des deux côtés.
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Nicolas Boulay (site web personnel) le 02 novembre 2017 à 12:07. Évalué à 3.
        
        mais encore une fois, ça demande une volonté et une culture favorable dans le projet.
        
        Oui, mais il y a déjà de gros précédent. cf https://linuxfr.org/news/985-bugs-dans-le-noyau-linux par exemple.
        
        déployer de l'analyse statique sérieuse sur les drivers et le code du kernel ne donne pas, à long terme, un avantage clair sur la qualité logicielle.
        
        Cela dépend ce que tu appelles "long terme", car tu peux passer un temps infini sur les faux positifs.
        
        Je ne vois pas pourquoi ce serait incompatible avec "l'Open Source" de travailler avec des universitaire
        
        Je n'ai pas dis ça. J'ai dis qu'il fallait démontrer la supériorité d'une solution avant que celle-ci soit mis en œuvre.
        
        C'est idiot, ce n'est pas réaliste pour des universitaires de développer un produit fini (ce n'est pas leur rôle et leur métier) sans savoir s'il y a une volonté pour l'utiliser derrière.
        
        C'est vrai pour n'importe quel développement. Et c'est exactement pour cette raisons que la plus part des outils libres sont directement utile à leurs auteurs, il est très rare d'avoir de bon outils libre, uniquement utile à d'autres.
        
        Dans le cas du noyau, cela serait bosser dessus, dans le but de faire un outil utile pour vous, comme exemple de passage à l'échelle.
        
        C'est bête de ne pas vouloir entendre qu'il faut de vrais efforts des deux côtés.
        
        Il faut voir le gain de leur coté, qui n'est pas évident à moyen terme. Il faudrait peut être organiser une conférence sur les ponts entre recherche et l'open source, pour que les gens se rencontrent, pour montrer les téchno de recherche, montrer les interactions qui marchent.
        
        "La première sécurité est la liberté"
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par gasche le 02 novembre 2017 à 12:35. Évalué à 4.
        
        Oui, mais il y a déjà de gros précédent. cf https://linuxfr.org/news/985-bugs-dans-le-noyau-linux par exemple.
        
        Non mais attendre qu'une société (créée à la base par des chercheurs mais développée comme un effort industriel) donne des rapports de bugs tout cuits à analyser, faire quelques changements et puis râler contre les faux positifs, ce n'est pas ce que j'appelle un précédent. C'est de l'assistanat, pas une collaboration.
        
        Pour information, les gens qui ont travaillé sur les outils d'analyse statique de drivers sur Windows reportent des taux de fausses alarmes très bas. Au moment où l'outil a été vraiment déployé (donc après une longue période de tests progressifs et de collaboration entre les chercheurs et l'équipe produit), 96% des alarmes étaient jugées utiles. Les gens de Facebook disent aussi que les fausses alarmes ne sont pas un problème pour Infer.
        
        J'ai dis qu'il fallait démontrer la supériorité d'une solution avant que celle-ci soit mis en œuvre.
        
        Ce dont je parle ici (mais c'est loin d'être la seule sorte de recherche qui pourraitêtre utile au noyau) c'est d'éliminer, par des outils d'analyse, des classes entières de bugs possibles du code du noyau (use-after-free, accès à de la mémoire non initialisée, usage incorrect des verrous…). Tu écris comme si l'utilité de ce résultat final restait à démontrer, ce qui me semble complètement fou—évidemment c'est utile, et évidemment un noyau qui a su mettre ces outils en place va se retrouver loin devant un noyau qui ne l'a pas fait sur le long terme, en terme de robustesse et de qualité.
        
        Long terme: je pense que si les gens s'y mettaient sérieusement aujourd'hui il faudrait de l'ordre de 10-15 ans pour ça porte ses fruits. Le projet SLAM a officiellement commencé à Microsoft en 2001, mais les chercheurs bossaient sans doute déjà sur ça avant. Bill Gates en a parlé dans une keynote en Avril 2002, donc à ce moment il y avait déjà un soutien de l'entreprise à un très haut niveau.
        
        C'est idiot, ce n'est pas réaliste pour des universitaires de développer un produit fini (ce n'est pas leur rôle et leur métier) sans savoir s'il y a une volonté pour l'utiliser derrière.
        
        C'est vrai pour n'importe quel développement. Et c'est exactement pour cette raisons que la plus part des outils libres sont directement utile à leurs auteurs, il est très rare d'avoir de bon outils libre, uniquement utile à d'autres.
        
        Dans le cas du noyau, cela serait bosser dessus, dans le but de faire un outil utile pour vous, comme exemple de passage à l'échelle.
        
        "utile pour vous" ne veut rien dire. Encore une fois, le principe de la recherche n'est pas qu'on développe des programmes C pour dominer le monde, et qu'on va se faire des outils d'analyse statique pour nos propres besoin. C'est de comprendre les problèmes difficiles à résoudre qui affectent tout le monde, et d'essayer de les étudier dans un cadre simplifié, qui permet de se concentrer sur les problèmes de fond.
        
        Il y a une grande distance et des années d'effort entre "un outil utile pour un programme C qui expose les principaux problèmes scientifiques" (ce que les chercheurs font dans le cadre de le travail) et "un outil qui peut marcher sur le noyau". Le boulot pour passer de l'un à l'autre comprend en partie de la recherche, mais aussi beaucoup d'implémentation et de travail chiant (par exemple s'intégrer au build system du kernel). Personne dans la communauté de recherche ne peut s'investir dans ce travail sans visibilité si ça va être utile à terme parce qu'il y a une envie de s'en servir dans le projet—ce serait sacrifier des années de sa vie et mettre sa carrière en pause pour un travail au final presque inutile. Cet effort de passage à l'échelle a été fait pour Microsoft, pour Airbus, pour Facebook, parce que ces boîtes ont une politique volontariste et ont montré une volonté de prendre ces outils au sérieux.
        
        Encore une fois, s'il n'y a pas de volonté de la part de la communauté Linux, c'est très dommage et ça veut dire que le noyau passe à côté d'opportunités de l'améliorer. Tu essaies d'argumenter que ce comportement idiot est, d'une façon ou d'une autre, inhérent au développement de logiciel libre, mais ce n'est pas vrai du tout. On peut développer un logiciel libre et avoir une vision à long terme, ouverte à la collaboration avec les autres. Une culture de communauté peut évoluer quand elle est mauvaise sur certains points.
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Nicolas Boulay (site web personnel) le 02 novembre 2017 à 13:57. Évalué à 3.
        
        Non mais attendre qu'une société (créée à la base par des chercheurs mais développée comme un effort industriel) donne des rapports de bugs tout cuits à analyser, faire quelques changements et puis râler contre les faux positifs, ce n'est pas ce que j'appelle un précédent.
        
        Et pourtant, cela a été déclaré comme une perte de temps par certain dev.
        
        des classes entières de bugs possibles du code du noyau (use-after-free, accès à de la mémoire non initialisée, usage incorrect des verrous…). Tu écris comme si l'utilité de ce résultat final restait à démontrer, ce qui me semble complètement fou
        
        Pour ton exemple, valgrind supporte (en dynamique) la détection des 2 premiers type de bug, et Sparse la dernière. Ce qui reste à démontrer est que l'usage de ces techniques demandent moins d'énergie pour corriger les bugs que les techniques actuelles (phase de mise au point inclus)
        
        Encore une fois, le principe de la recherche n'est pas qu'on développe des programmes C pour dominer le monde, et qu'on va se faire des outils d'analyse statique pour nos propres besoin. C'est de comprendre les problèmes difficiles à résoudre qui affectent tout le monde, et d'essayer de les étudier dans un cadre simplifié, qui permet de se concentrer sur les problèmes de fond.
        
        Tous les outils BSD proviennent bien de l'université Berkeley à l'origine ? Les outils GNU dont GCC ont été codé part RMS qui bossait pour le MIT. Idem pour Spice, le simulateur de circuit analogique. Donald Knuth de tex (latex) bossait pour Stanford. Apache provient de patch de NCSA httpd de l'Université de l'Illinois, idem pour Mosaic, le 1er navigateur internet. BIND (dns) a été conçu a Berkeley.
        
        Tous ces logiciels sont repris par des entités plus ou moins commerciales, mais on été directement utile sous leur 1er forme.
        
        "La première sécurité est la liberté"
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Renault (site web personnel) le 02 novembre 2017 à 13:38. Évalué à 6.
        
        il n'y a pas de raison qu'on ne puisse pas y arriver pour le kernel Linux, mais encore une fois, ça demande une volonté et une culture favorable dans le projet.
        
        Juste petite précision, la Fondation Linux et la recherche travaillent ensemble. D'ailleurs, un de ses membre imminents (Greg Kroah-Hartman) est allé bossé pendant un an à l'Inria de Paris : https://www.inria.fr/centre/paris/actualites/greg-kroah-hartman-rejoint-l-equipe-whisper
        
        Sans compter l'usage de Coccinelle qui n'est pas si anecdotique que cela.
        
        Ce n'est peut être pas assez, mais preuve que les univers communiquent quand même.
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par gasche le 03 novembre 2017 à 11:03. Évalué à 3.
        
        Juste petite précision, la Fondation Linux et la recherche travaillent ensemble.
        
        Tu as des informations plus précises là-dessus ? Combien de stages, combien de thèses ont été financées par la Fondation Linux, sur quels sujets ? À quelles conférences est-ce que des membres de la fondation sont venus parler de leurs problématiques et entrer en contact avec des gens ? Y a-t-il des choses qui ont été écrites publiquement (blogs, mailing-list) sur un désir de la Linux Foundation d'interagir avec les milieux de recherche, et sur la stratégie qu'ils ont décidé de mettre en place pour faciliter cela ? Y a-t-il sur le site web de la fondation une ou des pages dédiées à la recherche, qui indique par exemple comment les contacter pour monter un projet de collaboration ?
        
        (Je demande semi-naïvement : je ne suis pas de prêt ce que fait la fondation, donc je pourrais être positivement surpris, mais à ma connaissance la réponse à toutes ces questions est "zéro", "aucune" et/ou "non".)
        
        C'est très bien que GKH soit venu un an à Paris et ait discuté de Coccinelle (et il y a même de temps en temps quelques développeurs Linux qui s'en servent). Tu dis que l'usage n'est "pas anecdotique", mais pour moi c'est une goutte d'eau. Et ça a demandé de la part des gens qui travaillent sur Coccinelle des efforts considérables. Une telle collaboration ne devrait pas être exceptionnelle mais un exemple parmi d'autres.
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par claudex le 04 novembre 2017 à 12:09. Évalué à 4.
        
        Juste pour précision, la Linux Foundation, c'est 6 Fellows qui bossent sur les sujets techniques et pas tous sur Linux (il y a énormément de projets soutenus par la fondation). Je ne suis pas sûr que ce soit le meilleur endroit pour une collaboration avec la recherche (rien que par manque de main d'œuvre). Ça me semble plus pertinent d'aller voir des boîtes qui ont des budgets pour ça comme Red Hat, Microsoft ou Google.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par gasche le 04 novembre 2017 à 12:19. Évalué à 4.
        
        N'importe quoi. La Linux Foundation est un regroupement d'entreprises qui mettent un paquet d'argent en commun pour faire des choses autour du libre. Tu as choisi de montrer les 6 personnes qu'elle embauche à plein temps pour programmer, mais il y a un "Technical advisory board" de 10 personnes, une "Leadership team" de 24 personnes, des centaines d'entreprises qui sont membres (ils disent "plus de 800"), et en 2015 (dernière année pour les infos publiques sur les taxes) ils ont brassé 40 millions de dollar (avec presque 4 millions en bénéfices nets cette année-là).
        
        Autrement dit : ce serait tout à fait la bonne entité pour diriger un effort d'encouragement à la collaboration avec les milieux universitaires autour du noyau Linux.
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par claudex le 04 novembre 2017 à 12:43. Évalué à 4.
        
        Tu as choisi de montrer les 6 personnes qu'elle embauche à plein temps pour programmer
        
        Oui, ils représente la partie technique que la fondation peut mettre en œuvre. Autant dire qu'ils ne peuvent pas bosser avec la recherche comme le décrit. Il faut que ça viennent des autres développeurs.
        
        "Technical advisory board" de 10 personnes
        
        Qui sont juste des développeurs noyaux avec une voix dans la fondation. Ils peuvent donner un avis, mais ils ne vont pas dire "il faut plus de recherche", il faut leur montrer un projet.
        
        une "Leadership team" de 24 personnes
        
        Je ne vois pas bien ce qu'ils peuvent influencer dans le cas qui nous occupe.
        
        des centaines d'entreprises qui sont membres
        
        Et ce sont eux qui décident de la politique de la fondation, c'est pour ça que je dis qu'il vaut mieux aller d'abord dans ces boîtes où tu as des gens qui pourront dédié du temps à ça et se coordonner avec d'autres boîtes via la Linux Foundation.
        
        Bref, la fondation peut fournir du budget, mais il faut des gens avant pour organiser tout ça, et les entreprises membres ont justement des équipes pour ça.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par gasche le 04 novembre 2017 à 15:31. Évalué à 2.
        
        Je ne comprends pas ce que ton commentaire essaie d'apporter à cette conversation.
        
        Ce que j'ai proposé c'est que les gens de la Linux Foundation essaient d'encourager les collaborations entre les développeurs Linux et le milieu académique en (1) faisant de la communication à ce sujet et en (2) finançant des travaux de recherche appliquée au noyau. Ça ne suffit pas à changer la chose du tout au tout (il faut un changement de culture d'ensemble dans la communauté du noyau, je pense, mais ça c'est progressif sur le long terme), mais ça ne peut que renforcer des dynamiques. Ce sont des actions bien délimitées, qui sont largement à portée de ses missions, de ses financements et de son personnel (parce que non, ce n'est pas Linus dans son garage qui a fait le site web flambant de la fondation, et qui maintient le gâteau administratif des versements de sous, etc; il y a du personnel de support).
        
        Clairement une partie importante des entreprises qui soutiennent la fondation le font pour avoir l'impression de contribuer à l'écosystème Linux. Si la fondation leur propose une stratégie nouvelle (parmi d'autres) pour améliorer la qualité du noyau, elles seront certainement contentes de financer ça, mais c'est un endroit beaucoup plus neutre et beaucoup plus centralisé pour lancer ce genre d'effort qu'une entreprise en particulier. Par ailleurs, dans les entreprises de la Fondation, il n'y en a pas beaucoup qui ont des équipes de R&D de qualité sur les sujets dont je discutais (les outils d'analyse de programme); Microsoft en a, Facebook en a, IBM en a, mais ce n'est pas courant—il n'y a pas d'entreprise qui soit clairement mieux placée que la fondation pour lancer quelque chose là-dessus.
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par claudex le 04 novembre 2017 à 15:46. Évalué à 3.
        
        Je ne comprends pas ce que ton commentaire essaie d'apporter à cette conversation.
        
        Tu as l’air de dire qu’il suffit de financement pour que ça marche¹. Ce que je dis, c’est qu’il faut aussi des développeurs noyau qui aient du temps pour faire ça. Or, la fondation n’a pas les ressources en personnel pour ça. Il faut donc passer par les entreprises qui ont les développeurs noyau dans leurs employés pour que ça fonctionne et que le travail puisse être intégré.
        
        Il ne suffit pas non plus que la fondation lance un groupe de travail, il faut que les membres y participent. Je les imagine mal lancer un projet avec aucun membre qui suit. Il faut donc que ces derniers montrent un intérêt préalable pour que ce soit lancé.
        
        faisant de la communication à ce sujet
        
        Je ne comprends pas ce que tu veux qu'ils disent, sachant qu'ils ne pourront pas eux-même accueillir ses travaux de recherche mais que ça doit passer par d'autres.
        
        il n'y a pas d'entreprise qui soit clairement mieux placée que la fondation pour lancer quelque chose là-dessus.
        
        Tu veux dire que la fondation, qui n’a aucune équipe de R&D est mieux placé que ceux qui en ont une ?
        
        et je doute que les membres voient d’un bon œil que la fondation paye un membre pour qu’il délègue du temps à ça. ↩
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par gasche le 04 novembre 2017 à 17:50. Évalué à 2.
        
        Ce que je dis, c’est qu’il faut aussi des développeurs noyau qui aient du temps pour faire ça. Or, la fondation n’a pas les ressources en personnel pour ça.
        
        Mais non, il suffit que la fondation dise : "s'il y a des chercheurs et des développeurs qui veulent travailler ensemble sur un projet bien défini, nous on apporte des sous pour financer ça en partie". Après les gens se trouvent de la façon qu'ils veulent (ils s'envoient des emails pour se proposer le projet, utilise leurs contacts pour savoir qui serait intéressé par tel ou tel truc, etc.).
        
        Il faut donc que [les développeurs Linux] montrent un intérêt préalable pour que ce soit lancé.
        
        Bah ça c'est facile à tester, il suffit de poser la questions aux gens et d'envoyer des mails sur les mailing-list : "On envisage de faire ça, qu'en pensez-vous ? Contactez-nous si vous seriez prêt à aider un peu dans les domaines qui vous concernent.".
        
        La communication aussi c'est facile. C'est à moi de faire ce boulot ou quoi ? "Nous on est trop innovants de la mort et donc on monte un programme de financement des sujets de recherche en qualité logicielle (test et analyse de programme) autour de Linux. Les développeurs X et Y, et le chef du laboratoire de recherche Z du MIT, confirment que c'est une super idée."
        
        L'important c'est juste de dire : "on se rend compte que c'est un sujet intéressant/important et on est prêt à faire preuve de bonne volonté pour faciliter les choses". (Et si possible : on donne un peu des sous pour ça.) Si aujourd'hui je suis un chercheur et je me demande si je peux collaborer avec des gens, c'est beaucoup plus facile d'aller entrer en contact avec des gens qui ont fait signe qu'ils étaient intéressé qu'à des gens qui s'en foutent. Et les gens de Linux, aujourd'hui, ils s'en foutent.
        
        Tu veux dire que la fondation, qui n’a aucune équipe de R&D est mieux placé que ceux qui en ont une ?
        
        Il n'y a pas besoin d'équipe de R&D pour dire : "on veut plus de collaboration et si des gens nous contactent pour en faire, on va les aiguiller vers des interlocuteurs au sein du projet et on peut les financer un peu".
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par claudex le 04 novembre 2017 à 18:33. Évalué à 4.
        
        Mais non, il suffit que la fondation dise : "s'il y a des chercheurs et des développeurs qui veulent travailler ensemble sur un projet bien défini, nous on apporte des sous pour financer ça en partie".
        
        Du coup, en fait, c'est comme pour n'importe quel projet de la Linux Foundation. Tu présente ton idée et tu vois si c'est accepté, il n'y a pas besoin de faire un cas particulier de la recherche.
        
        Et les gens de Linux, aujourd'hui, ils s'en foutent.
        
        Et donc la fondation ne peut pas les forcer à s'y intéresser. Il faut voir avec leur employeur pour ça.
        
        Si aujourd'hui je suis un chercheur et je me demande si je peux collaborer avec des gens, c'est beaucoup plus facile d'aller entrer en contact avec des gens qui ont fait signe qu'ils étaient intéressé qu'à des gens qui s'en foutent. Et les gens de Linux, aujourd'hui, ils s'en foutent.
        
        Mais tu ne peux pas dresser une liste des gens intéressé pour un projet universitaire. C'est beaucoup trop vague. Il faut que tu présente ton projet aux personnes concerné pour qu'ils sachent s'ils sont intéressés ou pas.
        
        Il n'y a pas besoin d'équipe de R&D pour dire : "on veut plus de collaboration et si des gens nous contactent pour en faire, on va les aiguiller vers des interlocuteurs au sein du projet et on peut les financer un peu".
        
        Sauf que tu ne peux pas dire ça et puis aiguiller vers des gens qui vont dire « on ne le fait pas ». C'est contre productif. D'abord, tu contacte les gens concernés (la liste des mainteneurs et des mailings lists associée est publique) et une fois que tu as trouvé un accord mutuel, tu vas pouvoir bosser. Mais la fondation, ne va pas pouvoir t'aider avant ça.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Renault (site web personnel) le 04 novembre 2017 à 16:11. Évalué à 4.
        
        Je trouve que tu as une vision totalement étriquée de la situation. En te lisant sur cette enfilade, on a l'impression (je ne dis pas que c'est forcément le cas) que :
        
        La Linux Fondation a des sous mais n'en fait rien ;
        
        Le milieu de la recherche fait des efforts mais que la communauté du noyau n'en fait pas ;
        
        La Linux Fondation devrait s'impliquer dessus de manière plus forte, comme Mozilla, etc.
        
        C'est étriqué selon moi pour plusieurs raisons. Déjà comparer Linux et Mozilla, c'est difficile. Mozilla est une grosse structure, de plusieurs centaines de développeurs. C'est très centralisé, Mozilla a un grand contrôle de ses produits et donc de l'orientation des projets qu'il développe.
        
        La Linux Fondation (et la communauté Linux en général) n'est pas centralisée. C'est plus une fédération. La Linux Fondation n'est qu'un outil pour que des entreprises puissent monter des projets en commun autour du noyau. La Linux Fondation a très peu de contrôle sur le noyau lui même (l'essentiel des contributions viennent des entreprises membres de la fondation, pas de la fondation elle même). D'ailleurs elle peine déjà à développé son programme d'intégration des femmes et des personnes souvent discriminées, donc le milieu de la recherche ce n'est pas gagné.
        
        Du coup rien ne peut se faire sans une impulsion des membres de la fondation. Par exemple Tizen est un projet de la Linux Fondation. Mais le code provient essentiellement de Samsung aujourd'hui, voire d'Intel à une époque. C'est toujours comme ça. On est loin de Mozilla qui peut recruter (ou mobiliser) du jour au lendemain une armée de développeurs pour lancer Firefox OS.
        
        Et tu minimisais l'importance de Greg à l'Inria, pourtant il me semble que c'est un signal fort que la fondation envoie pendant un an (probablement à ses frais) l'un des mainteneurs les plus importants à bosser dans le milieu de la recherche.
        
        La communauté en générale a toujours été comme ça chacun apporte ce qu'il veut au noyau, il n'y a pas de commandants qui impose une voie à suivre. Seules les entreprises contributrices ont ce pouvoir en fait.
        
        Et bien sûr, le code accepté ne l'est que si ça répond aux exigences de qualité d'une part et si ça apporte quelque chose considéré comme utile d'autres part. Ce n'est pas parce que c'est taggué "recherche universitaire" que c'est accepté. D'ailleurs on a la preuve que cela ne fonctionne pas toujours, on se souviendra de Tanembaum qui a craché sur les noyaux non-micronoyaux et pourtant aucun noyau largement déployé aujourd'hui n'en est un 20 ans après. Ça fait très argument d'autorité du coup, il faut que les chercheurs montrent que leurs travaux sont utiles, les résultats intéressants et comment employer cela. On a la preuve qu'en persévérant un peu, ça finit par être accepté. Cela a été pareil pour la culture du tests du noyau, longtemps négligé mais aujourd'hui ça se développe fortement.
        
        Mais c'est comme tout, le libre ce n'est pas la présence de petits esclaves pour implémenter ton idée géniale. Soit les chercheurs font le boulots eux mêmes (ce que font certains), soit ils parviennent à convaincre, ou quelqu'un qui se posait la question est motivé pour aider. Typiquement, si pour avoir un noyau plus stable il faut mobiliser 10 personnes pendant 3 ans pour faire des tâches ingrates, cela peut devenir compliqué à faire sans que instance dirigeantes forte. Cela ne se fera pas spontanément par des bénévoles, et une entreprise seule ne va probablement pas le faire sans qu'elle n'en voit un bénéfice intéressant pour elle même par rapport à l'effort consenti.
        
        Note par ailleurs que sans chercher très longtemps je suis tombé sur des recherches autour du noyau Linux mais bien sûr fait par une entreprise ou université elle même. D’ailleurs l'Université de Louvain-la-Neuve planche sur le mulltipath TCP avec Linux comme implémentation de référence. Tu as aussi des universités (essentiellement américaines et chinoises) qui sont membres de la Linux Fondation (donc à même de proposer des projets de recherche), etc.
        
        Donc bon, qu'en conclure ? Je ne crois pas que la Linux Fondation, de part la nature de la communauté du noyau, soit à même de faire ce que Mozilla ou Microsoft font de leur côté. Je ne crois pas non plus que l'argument d'autorité "provient de la recherche" soit valable pour que le noyau s'intéresse spontanément et accepte sans difficulté les travaux des chercheurs. Et on a des signaux loin d'être négligeables selon moi que le monde de la recherche emploie Linux avec ou sans concertation des mainteneurs du projet.
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par gasche le 04 novembre 2017 à 17:41. Évalué à 3. Dernière modification le 04 novembre 2017 à 17:43.
        
        Ce que je dis :
        
        La communauté Linux est en retard en terme d'intégration des techniques de recherche sur la qualité logicielle (test et analyse de programme).
        
        Elle a un problème de culture et de dynamique interne qui rend les collaborations difficiles.
        
        Une façon de faciliter les échanges avec le milieu universitaire (très à court de sous en ce moment) est de donner de l'argent et, ça tombe bien, il se trouve que le projet Linux en a (plein d'entreprises qui soutiennent le projet en ont), et justement il existe une structure qui centralise de l'argent pour des projets, la Linux Foundation, qui pourrait facilement se lancer là-dedans.
        
        Je ne dis pas que c'est "juste la faute du noyau"; les universitaires aussi ont des efforts à faire pour avoir plus de collaboration, et je fais aussi ce que je peux pour le dire aux gens quand je discute au sein de cette communauté. Mais ici je parle des problèmes qui existent dans la communauté du noyau et de façon d'avancer vers des solutions.
        
        Pour préciser, les financements se passeraient par exemple comme ça : pour avoir des sous, il faut qu'une équipe envoie une proposition de projet à la Linux Foundation, qui décrit un projet de recherche appliquée au noyau. L'équipe qui a monté comprend des académiques et des développeurs du noyau, et surtout des gens qui vont surtout regarder/superviser et des gens qui vont vraiment faire le boulot (en général un ou plusieurs étudiants). La fondation paie des gens pour relire les propositions et dire si ça leur a l'air plausible (si c'est une idée intéressante, utile pour le noyau, réaliste scientifiquement, qui peut donner lieu à des suites intéressantes), et si oui la fondation donne un peu d'argent—$5000 dollars pour un en-plus qui motive mais qui ne suffit pas à financer, ou alors six mois de salaire pour un étudiant ou alors, pour une thèse complète, une année ou deux (mettons $50000).
        
        Une fois que c'est en place, la Linux Foundation dit aux devs Linux "si vous connaissez des chercheurs dont le travail vous intéresse, parlez-leur de cet appel à projet", et contacte les chercheurs qui ont déjà bossé sur Linux pour leur en parler. Ensuite c'est aux chercheurs qui sont intéressés par ces financement d'entrer en contact avec des gens, de monter un projet, et de candidater. S'il peut y avoir des pointeurs pour des contacts (sur le site web, "si vous voulez savoir qui est intéressé par le sujet X, vous pouvez demander à Y qui est un bon d'entrée dans la communauté noyau"), c'est mieux.
        
        Tout cela est au final assez simple, ça demande juste un peu de travail (pour coordonner le tout il faut des gens non-techniques, qui peuvent être payées pour ce boulot comme la Linux Fondation embauche ou sous-traite déjà du travail) et surtout de la bonne volonté.
        
        Je trouve que tu as une vision totalement étriquée de la situation.
        
        Moi j'ai surtout l'impression d'être en face d'un barrage de mauvaise foi. Je parle quand même de chose que je connais relativement bien (je participe comme contributeur à des projets libres, donc bon "il y a des exigences de qualité" et "on n'est pas des petits esclaves", c'est évident pour moi), et on m'oppose des arguments vraiment loin de la réalité : "non mais la Linux Foundation c'est juste 6 personnes qui n'ont pas le temps".
        
        Personne ne serait forcé à faire une chose ou une autre, mais le fait de mettre une structure en place pour encourager ces collaborations (et de l'argent pour les faciliter) peut avoir beaucoup d'impact.
        
        Et tu minimisais l'importance de Greg à l'Inria, pourtant il me semble que c'est un signal fort que la fondation envoie pendant un an (probablement à ses frais) l'un des mainteneurs les plus importants à bosser dans le milieu de la recherche.
        
        Je suis passé dans les bureaux de cette équipe de recherche au moment où Greg y était. C'est sympa, il a fait un séminaire pour parler aux étudiants pour parler du développement Linux, et je suis sûr qu'il a bien discuté avec Julia Lawall de ce qui lui l'intéresserait dans son travail à elle, et donné des idées de choses à faire. C'était aussi une bonne occasion de faire de la communication des deux côté (Linux : "vous voyez, on est en contact avec la recherche"; INRIA : "vous voyez, on est bien vus par le monde des gens qui font des vrais trucs"). Mais après GKH a surtout passé une année sympa à Paris à bosser sur ses trucs qu'il fait d'habitude dans un bureau différent, et eu plus d'opportunités pour discuter. Ça a un impact, mais comme je l'ai dit, c'est une goutte d'eau.
        
        Note par ailleurs que sans chercher très longtemps je suis tombé sur des recherches autour du noyau Linux mais bien sûr fait par une entreprise ou université elle même. D’ailleurs l'Université de Louvain-la-Neuve planche sur le mulltipath TCP avec Linux comme implémentation de référence. Tu as aussi des universités (essentiellement américaines et chinoises) qui sont membres de la Linux Fondation (donc à même de proposer des projets de recherche), etc.
        
        Encore une fois, c'est de la recherche en systèmes; il y a des chercheurs qui contribuent à Linux dans ce domaine et c'est très bien. Moi je parle de recherche en qualité logicielle (test et analyse de code), et là c'est beaucoup moins clair—à part Coccinelle.
        
        Je ne crois pas que la Linux Fondation, de part la nature de la communauté du noyau, soit à même de faire ce que Mozilla ou Microsoft font de leur côté.
        
        Ben si, pourquoi pas ? Il suffit de bonne volonté (ça manque) et d'un peu d'argent (il y en a). Pour Mozilla, ce n'est pas très compliqué de dire à l'un de ses employés "si tu veux, on te paie pour aller pendant une semaine à la conférence machin qui t'intéresse, et quand tu discutes avec des gens là-bas, dis-leur bien qu'on est intéressé par le fait de financer des collaborations". Ce ne serait pas très compliqué pour la communauté Linux de faire la même chose.
        
        Et bien sûr, le code accepté ne l'est que si ça répond aux exigences de qualité d'une part et si ça apporte quelque chose considéré comme utile d'autres part. Ce n'est pas parce que c'est taggué "recherche universitaire" que c'est accepté.
        
        De toute façon, ce dont je parle ce n'est pas de faire rentrer des bases de code dans le noyau, c'est plutôt d'évaluer des outils de test ou d'analyse statique sur le kernel, de les adapter pour passer à l'échelle, et si possible de faire des changements dans le code qui facilitent leur application.
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Renault (site web personnel) le 04 novembre 2017 à 18:33. Évalué à 4.
        
        justement il existe une structure qui centralise de l'argent pour des projets, la Linux Foundation, qui pourrait facilement se lancer là-dedans.
        
        C'est là je pense que tu te trompes.
        Plein d'argent, c'est quand même à relativiser. Pour une structure qui a autant de projets en son sein, d'utilisateurs et autant de partenaires industrielles, c'est je trouve un très petit budget. La petite PME dans laquelle je bossais en brassait sans doute plus par année.
        
        L'autre problème, comme cela a été souligné, c'est que la Linux Fondation emploie peu de personnes techniques (des développeurs ou mainteneurs). Donc il faudrait quelqu'un se dévoue pour mobiliser des employés pour aider les chercheurs. La Linux Fondation ne peut pas le faire, elle n'a pas l'effectif pour.
        
        C'est le soucis du fait que la communauté Linux, dans son ensemble, est très décentralisée. L'avantage est que cela facilite l'intégration de travail extérieur (on peut par exemple parler de certaines entreprises qui ont du code libre mais qui ont un très grand contrôle sur le code). L'inconvénient est en effet que cela rend des décisions plus difficiles à mettre en œuvre car personne n'a la légitimité d'imposer des décisions.
        
        Tout cela est au final assez simple, ça demande juste un peu de travail (pour coordonner le tout il faut des gens non-techniques, qui peuvent être payées pour ce boulot comme la Linux Fondation embauche ou sous-traite déjà du travail) et surtout de la bonne volonté.
        
        Mouais, cela demande quand même d'évaluer la recherche, sa pertinence, les ressources nécessaires, de comprendre aussi les rouages suivant le pays en question (je pense qu'un dossier de recherche en Chine ce n'est pas les mêmes règles qu'aux USA, qu'en France, etc.). Personnellement, je ne trouve pas cela simple, je dirais même qu'il faudrait des employés compétents sur la question ce qui nécessite de les trouver, les embaucher, etc.
        
        En soit oui, rien d'impossible, mais le manque de centralisation de cette communauté rend cela difficile si aucun partenaire industriel ne force la main ou prend cela en charge en grande partie.
        
        Ça a un impact, mais comme je l'ai dit, c'est une goutte d'eau.
        
        Pour une fondation avec moins de 50 personnes, envoyer l'un de ses membres les plus influents pendant 1 an, ce n'est pas si négligeable que cela.
        C'est amusant car tu te plains (à juste titre) du manque de budget public dans la recherche ce qui pose notamment des soucis pour que chacun puisse voir les conf de son milieu et à côté tu dis qu'envoyer un an à l'étranger un employé cela ne sert à rien et n'est pas une décision importante. Car l'opération, je doute qu'elle a été gratuite.
        
        Encore une fois, c'est de la recherche en systèmes; il y a des chercheurs qui contribuent à Linux dans ce domaine et c'est très bien. Moi je parle de recherche en qualité logicielle (test et analyse de code), et là c'est beaucoup moins clair—à part Coccinelle.
        
        C'est déjà bien que la recherche soit impliquée dans le cœur du métier du noyau, non ? C'est la preuve que malgré tout, le noyau peut récolter et assimiler les résultats de certaines recherches. La qualité du noyau (je dirais même la qualité logicielle au sens large), honnêtement, c'est assez récent comme problématique (moins de 5-10 ans), les choses se mettent en place et les progrès sont malgré tout importants.
        
        Je pense que ceci explique en partie pourquoi Linux a du retard sur d'autres entreprises par rapport à cette problématique.
        
        Pour Mozilla, ce n'est pas très compliqué de dire à l'un de ses employés "si tu veux, on te paie pour aller pendant une semaine à la conférence machin qui t'intéresse, et quand tu discutes avec des gens là-bas, dis-leur bien qu'on est intéressé par le fait de financer des collaborations". Ce ne serait pas très compliqué pour la communauté Linux de faire la même chose.
        
        C'est très différent et je suis étonné que tu ne voies pas le soucis.
        Dans un cas c'est un employé, dans l'autre, ce sont des membres d'une communauté. Tu ne gères pas cela de la même façon. Si demain Mozilla veut financer une recherche sur Rust, elle peut forcer des employés à bosser dessus. La Linux Fondation peut juste inciter quelqu'un de le faire, mais ne peut pas forcer cette personne. Et c'est plus facile aussi de finance des gens affiliés à toi. Donc faut que cette personne soit un employé ou membre.
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par gasche le 04 novembre 2017 à 19:02. Évalué à 3.
        
        Tu penses à de faux problèmes.
        
        Donc il faudrait quelqu'un se dévoue pour mobiliser des employés [techniques] pour aider les chercheurs.
        
        Non, pas spécialement besoin d'aide là-dessus, encore une fois il suffit de les gens demander des contacts, etc. Il y a besoin d'aide administrative (pour les transferts d'argent il faut de la paperasse), la fondation a du personnel administratif pour ces choses-là.
        
        En soit oui, rien d'impossible, mais le manque de centralisation de cette communauté rend cela difficile si aucun partenaire industriel ne force la main ou prend cela en charge en grande partie.
        
        La communauté universitaire est aussi très décentralisée et pourtant on arrive à monter des projets.
        
        C'est plus difficile qu'au sein de Microsoft où un manager peut dire "maintenant vous faites ça, point barre", mais ce n'est pas si difficile en soit. Je pense que l'approche par financement de projet que je propose marcherait bien.
        
        Mouais, cela demande quand même d'évaluer la recherche, sa pertinence, les ressources nécessaires, de comprendre aussi les rouages suivant le pays en question
        
        Pour évaluer les propositions, il suffit de demander leur avis à des gens qui connaissent le sujet. Tu envoies un mail "salut, pouvez-vous lire cette proposition de 6 pages et donner votre avis sur la faisabilité du truc, ou sinon me conseiller deux personnes qui s'y connaissent mieux que vous ?" à trois personnes, et les gens se montrent plein de bonne volonté en pratique. (Encore une fois, le milieu universitaire, décentralisé, fonctionne très bien comme cela.)
        
        Pour une fondation avec moins de 50 personnes, envoyer l'un de ses membres les plus influents pendant 1 an, ce n'est pas si négligeable que cela.
        
        Non mais ce n'est pas comme ça que ça c'est passé, c'est GKH qui a décidé de passer un an à Paris et qui a prévenu les gens qui l'emploient qu'il allait faire ça, et il a dit ok. Et il est payé pareil, où qu'il habite.
        
        La Linux Fondation peut juste inciter quelqu'un de le faire, mais ne peut pas forcer cette personne.
        
        Je rend des services tous les mois à des gens d'une autre université, d'un autre pays que moi, sans transfert d'argent ou qu'on fasse partie de la même institution. Personne n'est forcé, on me demande gentiment et j'accepte quand ça m'intéresse. Ça peut se passer comme cela là-aussi.
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par kantien le 05 novembre 2017 à 11:20. Évalué à 4.
        
        La qualité du noyau (je dirais même la qualité logicielle au sens large), honnêtement, c'est assez récent comme problématique (moins de 5-10 ans), les choses se mettent en place et les progrès sont malgré tout importants.
        
        Je suis étonné du caractère si récent de la prise en compte d'une telle problématique. J'ai terminé mes études il y a une quinzaine d'années et ce genre de questions étaient au cœur de la formation. Personnellement, l'utilité pour l'informatique était une chose qui, à l'époque, me semblait un cas d'application amusant mais sans plus; je regardais la chose d'un air amusé, les fondements des mathématiques m'important plus que ceux de l'informatique. Ce n'est que très récemment que je me suis repenché sur le lien avec le développement logiciel. À l'époque, les deux seuls langages que l'ont m'a enseigné était OCaml et Coq : avec le premier je m'étais amusé à faire un système de calcul formel sur l'arithmétique transfinie de Cantor, et avec le second j'avais formalisé quelques résultats élémentaires d'arithmétiques. Autant dire des questions de peut d'intérêt pour du développement logiciel.
        
        Ceci étant dit, il est connu de longue date que la qualité logicielle relève de la preuve mathématique. Les approches dignes des sciences expérimentales à coup de tests unitaires ou de fuzzer, c'est gentil : ça peut détecter la présence de bugs, mais cela n'en prouvera jamais l'absence. À un moment, quand on affirme, il faut pouvoir prouver, quitte à le faire à la main :
        
        Vous affirmez ? j'en suis fort aise.
        Et bien ! prouvez maintenant.
        
        pourrait être la devise des kantiens.
        
        Quand je lis, par exemple, dans ce fil, que Nicolas Boulay demande qu'il faut démontrer la supériorité d'une solution avant de la mettre en œuvre et que gasche doit lui répondre :
        
        Ce dont je parle ici (mais c'est loin d'être la seule sorte de recherche qui pourraitêtre utile au noyau) c'est d'éliminer, par des outils d'analyse, des classes entières de bugs possibles du code du noyau (use-after-free, accès à de la mémoire non initialisée, usage incorrect des verrous…). Tu écris comme si l'utilité de ce résultat final restait à démontrer, ce qui me semble complètement fou—évidemment c'est utile, et évidemment un noyau qui a su mettre ces outils en place va se retrouver loin devant un noyau qui ne l'a pas fait sur le long terme, en terme de robustesse et de qualité.
        
        je tombe des nues. :-O Mais enfin, c'est une évidence pour qui est un minimum rigoureux intellectuellement ! On pourrait y rajouter en écho ce passage de l'évangile selon Saint Luc (chapitre 6, versets 47-49) :
        
        47 Quiconque vient à moi, écoute mes paroles et les met en pratique, je vais vous montrer à qui il ressemble.
        
        48 Il ressemble à celui qui construit une maison. Il a creusé très profond et il a posé les fondations sur le roc. Quand est venue l’inondation, le torrent s’est précipité sur cette maison, mais il n’a pas pu l’ébranler parce qu’elle était bien construite.
        
        49 Mais celui qui a écouté et n’a pas mis en pratique ressemble à celui qui a construit sa maison à même le sol, sans fondations. Le torrent s’est précipité sur elle, et aussitôt elle s’est effondrée ; la destruction de cette maison a été complète. »
        
        ou encore cet extrait de la préface des Prolégomènes à toute métaphysique future qui pourra se présenter comme science de Kant :
        
        D'autre part il n'est pas tellement inouï qu'après avoir longtemps pratiqué une science, si on pense avec étonnement au progrès qui y a été accompli, on finisse par se poser la question de savoir si et comment de façon générale une telle science est possible. Car la raison humaine est assez désireuse de construire pour qu'il lui soit déjà maintes fois arrivé de bâtir la tour pour, puis de la démolir pour voir de quelle nature pouvait bien être son fondement. Il n'est jamais trop tard pour devenir sage et raisonnable; mais lorsque l'enquête est tardive, elle est plus difficile à mettre en train.
        
        Lorsque gasche affirme que c'est un investissement sur le long terme :
        
        Long terme: je pense que si les gens s'y mettaient sérieusement aujourd'hui il faudrait de l'ordre de 10-15 ans pour ça porte ses fruits.
        
        cela va également de soi. Mais plus le projet tarde à s'y mettre, plus la base de code (déjà très volumineuse) augmentera et plus il sera difficile, voire surhumain, de mettre en pratique ce genre d'approche de contrôle qualité. Il vient donc naturellement à l'esprit cette question : la communauté en charge du développement du noyau est-elle sensible à ces questions ou s'en moque-t-elle fondamentalement ?
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Nicolas Boulay (site web personnel) le 06 novembre 2017 à 11:47. Évalué à 3.
        
        la communauté en charge du développement du noyau est-elle sensible à ces questions ou s'en moque-t-elle fondamentalement ?
        
        Non, elle ne s'en moque pas. Elle n'est simplement pas persuadé du tout que les chercheurs peuvent l'aider sur la question.
        
        "La première sécurité est la liberté"
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Renault (site web personnel) le 06 novembre 2017 à 12:46. Évalué à 6.
        
        J'ai terminé mes études il y a une quinzaine d'années et ce genre de questions étaient au cœur de la formation.
        
        Je ne sais pas quelle formation tu as eu, mais la question de la qualité dans le développement logiciel c'est loin d'être généralisé même aujourd'hui, que ce soit en entreprise ou dans les formations.
        
        Globalement la qualité se résume souvent à un cahier de tests, avec des tests unitaires ou fuzzing sans oublier la revue de code et l'intégration continue. Quand tu as ça, déjà, tu es content.
        
        À l'époque, les deux seuls langages que l'ont m'a enseigné était OCaml et Coq
        
        Juste pour préciser, très peu d'ingénieurs en France et Belgique (et je pense que c'est plus ou moins pareil partout pour des ingés niveau master) voient dans le cadre scolaire les langages fonctionnels de manière sérieuse. Alors Coq et OCaml tu comprendras que ta formation est assez décalée de ce que rencontre la plupart des développeurs.
        
        Ceci étant dit, il est connu de longue date que la qualité logicielle relève de la preuve mathématique. Les approches dignes des sciences expérimentales à coup de tests unitaires ou de fuzzer, c'est gentil : ça peut détecter la présence de bugs, mais cela n'en prouvera jamais l'absence. À un moment, quand on affirme, il faut pouvoir prouver, quitte à le faire à la main :
        
        Je pense que personne ne va te contredire sur ce point, d'ailleurs Knuth a une citation sur le sujet. Mais il me semble naïf de croire que cette méthode soit viable et générique, en tout cas aujourd'hui.
        
        Je veux dire, en général cette artillerie est réservée vraiment à des domaines de haute criticité où le rapport bénéfice / coût est évident. Typiquement en aéronautique cela sera exigé / recommandé pour les DAL A ou B, mais pas au delà. Et les coûts d'un tel travail est tel que c'est rarement appliqué en dehors de ces contextes là. Qui d'ailleurs reposent sur du matériel et du logiciel simple, élémentaire pour faciliter ce travail. Voire le rendre possible, car si je ne me trompe pas, tu ne peux pas prouver formellement que n'importe quel programme fonctionnera tel qu'attendu.
        
        D'autant que si ton programme a un lien fort avec ton matériel (cas du noyau ou d'un logiciel embarqué), il faut aussi formaliser le matériel et cette liaison. Est-ce que des processeurs ou GPU modernes bénéficient d'un tel travail ? J'en doute.
        
        je tombe des nues. :-O Mais enfin, c'est une évidence pour qui est un minimum rigoureux intellectuellement !
        
        Déjà, je dirais que pour être rigoureux intellectuellement, il faut démontrer que la solution proposée apporte quelque chose. Même si cela paraît évident. Car comme je l'ai dit, ce n'est pas parce que ton travail provient de la recherche universitaire que cela est forcément bénéfique. On ne va pas lister le nombre de prédictions théoriques de la recherche fondamentale (dont sur les noyaux de système d'exploitation) qui n'ont jamais su percer dans l'industrie faute d'adéquation en réalité.
        
        Et encore, c'est en supposant que le travail soit gratuit, ce qui ne l'est bien évidemment pas vrai. Car c'est bien de venir avec une théorie, une idée, il faut quelqu'un pour le mettre en œuvre, le maintenir et que cela ne gêne pas les autres développeurs. Typiquement si tu viens avec un système d'annotation du code, qui pourrait apporter un gain pour l'analyse du noyau. Il faut que quelqu'un annote tout le code existant, documente cette section et que les autres développeurs exploitent cela. C'est un travail titanesque et potentiellement ingrate. Même si le gain sur le long terme est démontré, il faut encore que quelqu'un ou une entité investisse dedans et ce n'est rien d'évident. Surtout que pendant la période de transition tu risques d'avoir des pertes de productivité importantes aussi.
        
        Bref, tout dépend, mais il faut tenir compte de ces éléments aussi dans l'aspect "démonstration". La réalité a ses propres contraintes qui peuvent rendre difficile la transposition recherche théorique / logiciels industriels.
        
        Il vient donc naturellement à l'esprit cette question : la communauté en charge du développement du noyau est-elle sensible à ces questions ou s'en moque-t-elle fondamentalement ?
        
        La communauté ne s'en moque pas, la question de la qualité du noyau est de plus en plus centrale dans les discussions. Cela passe par l'intégration continue, le fuzzing, les tests unitaires, etc. qui se généralisent.
        
        Mais la communauté du noyau n'a pas d'exigence particulière non plus. Selon la communauté avec qui tu parles, la sécurité doit être le critère 1, ici ça parle plutôt de l'analyse et de la conformité du code, pour d'autres ce sera la performance, etc. La communauté du noyau le cherche pas l'excellence dans tous les domaines à la fois (ce n'est pas réaliste) mais un compromis.
        
        De la même façon qu'aujourd'hui tu n'as aucun micro-noyau pur utilisé massivement pour une large gamme d'utilisation. Car si la théorie est belle, les contraintes sont telles que le compromis impose soit de faire du monolithique modulaire (Linux, BSD) ou du micro-noyau enrichi (Windows, macOS, iOS). Pourtant Microsoft et Apple ne sont pas des brelles (ils ont des équipes de R&D à la hauteur), ils peuvent largement payer ou contraindre des employés de bosser sur la question. Et pourtant le résultat est contraire à la prédiction de la recherche du secteur depuis 25 ans.
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Nicolas Boulay (site web personnel) le 06 novembre 2017 à 13:23. Évalué à 3.
        
        Globalement la qualité se résume souvent à un cahier de tests, avec des tests unitaires ou fuzzing sans oublier la revue de code et l'intégration continue. Quand tu as ça, déjà, tu es content.
        
        Tu voudrais quoi de plus ? C'est déjà pas mal. Dans l'aéronautique, ils n'ont pas de fuzzer, mais ont des revues de testes.
        
        Typiquement en aéronautique cela sera exigé / recommandé pour les DAL A ou B, mais pas au delà.
        
        Tu fais références à quoi ?
        
        D'autant que si ton programme a un lien fort avec ton matériel (cas du noyau ou d'un logiciel embarqué), il faut aussi formaliser le matériel et cette liaison. Est-ce que des processeurs ou GPU modernes bénéficient d'un tel travail ? J'en doute.
        
        Il n'y a pas d'étude formelle, mais il y a une norme à respecter https://fr.wikipedia.org/wiki/DO-254
        
        "La première sécurité est la liberté"
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Renault (site web personnel) le 06 novembre 2017 à 13:32. Évalué à 4.
        
        Tu fais références à quoi ?
        
        La démonstration formelle que l'application X (genre le contrôleur des moteurs de l'avion ne crachera pas). Je sais que Coq (ou des outils similaires) ont été utilisé dans ce genre de contexte. Mais que cela reste réservé à ce niveau de criticité et pour des logiciels assez petits.
        
        Il n'y a pas d'étude formelle, mais il y a une norme à respecter https://fr.wikipedia.org/wiki/DO-254
        
        Bien sûr, je connais, j'ai bossé dans le milieu (DAL C au plus haut). Mais tu n'as pas besoin d'aller si loin que ce que kantien annonce à savoir démontrer par les maths que ton système va marcher à tous les coups.
        
        D'ailleurs pour les DAL >= C, il devient difficile d'employer des CPU multi-cœurs ou avec un GPU moderne tellement que c'est contraignant vis à vis des normes. Donc imaginer démontrer avec Coq que Linux tourne bien sur le dernier Intel couplé avec un GPU nVidia, on en est très très loin.
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Nicolas Boulay (site web personnel) le 06 novembre 2017 à 15:42. Évalué à 3.
        
        Pour info, j'ai fais uniquement du DAL A (code qui vole, générateur de donné, outils de validation). Les démonstrations formelles ne sont pas accepté, en DO178b, et commence à l'être en DO178c. Le problème principale est que l'outil de validation lui-même doit être écris en DAL A pour être accepté.
        
        SCADE est souvent utilisé dans les fadec, mais il n'y a aucune "preuve". Le langage est formel dans le sens ou il ne comporte pas d’ambigüité. Et le compilo est certifié.
        
        D'ailleurs pour les DAL >= C, il devient difficile d'employer des CPU multi-cœurs ou avec un GPU moderne tellement que c'est contraignant vis à vis des normes.
        
        Cela commence tout doucement. La première version de vxworks multicpu, tournait avec 2 instances d'OS, comme si il y avait 2 ordinateurs. C'est très compliqué de calculer le temps d’exécution avec ce genre de machine (ex: il y a une perte de perf de 20% sur les 2 cpu à cause de l'usage du bus mémoire). Si tu prends des marges de fou, avoir 2 cpu n'a plus trop d’intérêt.
        
        Mais la mode IMA, c'est de tout "virtualiser" plus ou moins statiquement. Leur rêve est d'avoir des racks standards et de mettre les applications sur les ordinateurs fonctionnelles.
        
        Concernant les GPU, je n'ai pas encore vu de code certifié. En graphique, il utilise de l'openGL SC, genre d'opengl 1.0, je crois que la dernières version a simplement pris l'api opengl ES vu comme plus propre. Il n'y a pas de shader la-dedans (il faudrait qualifier le compilateur…).
        
        A part ça, je suis persuadé qu'il doit être possible de pouvoir créer un langage qui respecte toutes les contraintes de la DO178b, de le bootstraper et ensuite de pouvoir écrire plus facilement des applications qualifié. Mais cela va au-delà du code pure, car il faut gérer la documentation (les revues de code humaine, les descriptions api, le rapport d'architecture), les versions, les tests (et leur couverture), la traçabilitée.
        
        "La première sécurité est la liberté"
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Renault (site web personnel) le 06 novembre 2017 à 15:54. Évalué à 3.
        
        Les démonstrations formelles ne sont pas accepté, en DO178b, et commence à l'être en DO178c. Le problème principale est que l'outil de validation lui-même doit être écris en DAL A pour être accepté.
        
        Je suis au courant de cela, je disais juste que des équipes se servent de cela durant les étapes de développement pour gagner du temps dans la période avant la certification et éviter de devoir y passer plusieurs fois (car c'est cher).
        
        Je sais bien que ces résultats ne sont pas exploités par les agences de certification ou de contrôle.
        
        Cela commence tout doucement.
        
        Oui, c'est bien ce que je dis, la migration est lente. Si je me souviens bien, un CPU dans la norme DO est considéré comme valide sans plus de preuves que cela s'il est monocoeur et ne réorganise pas l'ordre des instructions… Ce qui est de plus en plus rare aujourd'hui.
        
        Concernant les GPU, je n'ai pas encore vu de code certifié.
        
        Le problème du GPU c'est aussi qu'ils partent sur des hypothèses de GPU simples et donc assez peu puissants. Typiquement on a tâté les limites de la DO avec du Tegra K1 en DAL C, avec donc un CPU et un GPU qui ont une grande mémoire partagée, qui sont très modernes (donc réorganisation des instructions par exemple) et très parallélisés.
        
        Ce cas de figure n'est pas vraiment documenté dans les standards aéro, et ils ont globalement 20 ans de retard sur ce qui est considéré comme standard. Ce qui est un soucis pour introduire bien sûr des calculs plus puissants pour le contrôle de l'appareil.
        
        A part ça, je suis persuadé qu'il doit être possible de pouvoir créer un langage qui respecte toutes les contraintes de la DO178b, de le bootstraper et ensuite de pouvoir écrire plus facilement des applications qualifié.
        
        Je n'en suis pas sûr, quand je m'y étais un peu intéressé il semblait impossible de pouvoir (mathématiquement) faire le langage parfait qui puisse exprimer n'importe quel programme de manière assez simple et en garantir la preuve de son bon fonctionnement.
        
        Car bon, si pour réaliser un noyau de la taille de Linux ou Windows, prouvé fonctionnel, il faut des années de travail, avec une maintenance difficile et des fonctionnalités en moins, ça risque d'être difficile à imposer.
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Nicolas Boulay (site web personnel) le 06 novembre 2017 à 19:15. Évalué à 3.
        
        Oui, c'est bien ce que je dis, la migration est lente. Si je me souviens bien, un CPU dans la norme DO est considéré comme valide sans plus de preuves que cela s'il est monocoeur et ne réorganise pas l'ordre des instructions… Ce qui est de plus en plus rare aujourd'hui.
        
        Il n'y a rien de tel dans la norme. Elle est justement très peu technique et parle surtout de processus de fabrication. Le cpu typique est le powerPC 601 qui fait un peu d'out of order, il me semble.
        
        Ce cas de figure n'est pas vraiment documenté dans les standards aéro, et ils ont globalement 20 ans de retard sur ce qui est considéré comme standard. Ce qui est un soucis pour introduire bien sûr des calculs plus puissants pour le contrôle de l'appareil.
        
        Projet assez génial on dirait :) Pour moi votre difficulté serait de faire valider tout le runtime qui est vendu avec ce genre de machin. Cela peut être extrêmement complexe. Le pire est le compilateur. Comment prouver que ce qui est compiler est correct, si vous n'avez pas la description de l'assembleur qui va avec ?
        
        Pour les compilo C, on est censé prouver que le compilo génère le bon code objet. Cela a dû se faire par relecture et traçabilité entre code ASM et code C, mais maintenant, cela doit pouvoir se faire avec des exemples de code C à compiler, puis ensuite, on dit que tout code sera issue de ces blocs de base. Mais avec les trucs proprio NVIDIA, je ne vois pas comment faire ça. Vous avez regardez les "array de cpu" comme ceux de Kalray ?
        
        Je n'en suis pas sûr, quand je m'y étais un peu intéressé il semblait impossible de pouvoir (mathématiquement) faire le langage parfait qui puisse exprimer n'importe quel programme de manière assez simple et en garantir la preuve de son bon fonctionnement.
        
        Mais non, je parle de formaliser la DO178, elle-même, pour inclure dans un langage toutes les étapes décrites dans la norme. Le compilateur ne ferait que vérifier la cohérence de l'ensemble des informations (type traçabilité spec<->code<->test<->couverture de test, vérification de la couverture, etc…).
        
        Cela revient à faire un langage qui impose une spec, le teste, la traçabilité et des revues.
        
        "La première sécurité est la liberté"
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Anthony Jaguenaud le 07 novembre 2017 à 09:01. Évalué à 4.
        
        Concernant les GPU, je n'ai pas encore vu de code certifié.
        
        J’ai participé au driver graphique pour l’A350, la puce graphique est certifiée DAL-A, développé en interne. Au niveau puissance on est loin des normes actuelles sur PC… Mais on est capable de garantir que si un dessin d’une application met trop de temps, l’application critique aura le temps d’être dessiné, ça fait du T&L.
        
        Pour les aspects multi-cœur, le problème vient surtout de comment garantir qu’un cœur ne prend pas toute la bande passante RAM, PCI pour lui en retardant les autres.
        
        Pour ceux qui ne connaissent pas ce genre de domaine, l’objectif n’est pas d’être performant, mais de garantir qu’on est certain d’avoir le temps de faire les traitements dans le temps imparti. Si notre BUS mémoire n’est pas disponible, on perd la garanti.
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par auve le 07 novembre 2017 à 19:00. Évalué à 3.
        
        SCADE est souvent utilisé dans les fadec, mais il n'y a aucune "preuve". Le langage est formel dans le sens ou il ne > comporte pas d’ambigüité. Et le compilo est certifié.
        
        Tout ce que tu dis est vrai (et pour cause !), je préciserais simplement que "ne pas comporter d'ambigüité" veut dire qu'on peut donner au langage une sémantique formelle claire. Ça va aussi avec un certain nombre d'articles de recherche présentant le langage et diverses techniques de compilation de façon très propre. Un compilateur prouvé correct en Coq pour une version très antérieure de SCADE, Lustre, a d'ailleurs été récemment présenté à la conférence PLDI.
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par kantien le 08 novembre 2017 à 12:27. Évalué à 2. Dernière modification le 08 novembre 2017 à 12:31.
        
        Je ne sais pas quelle formation tu as eu, mais la question de la qualité dans le développement logiciel c'est loin d'être généralisé même aujourd'hui, que ce soit en entreprise ou dans les formations.
        
        C'était une formation en logique mathématique et sur les fondements de l'informatique. Personnellement, à l'époque, la partie fondements de l'informatique ne m'intéressait pas spécialement. Je voulais surtout approfondir mes connaissances en logique et voir ce qu'avaient donné les attaques contre la philosophie kantienne des mathématiques (j'ai lu la Critique de la Raison Pure à la fin de ma spé, et je suis kantien depuis cette époque). Pour ceux intéressés par l'informatique, d'après la brochure sur les débouchés, il semblerait qu'ils finissent par faire une thèse et de la recherche (dans les organismes publiques ou en R&D chez des industriels genre EDF).
        
        J'ai bien conscience qu'une telle formation est à part par rapport aux formations courantes des ingénieurs informaticiens.
        
        Déjà, je dirais que pour être rigoureux intellectuellement, il faut démontrer que la solution proposée apporte quelque chose. Même si cela paraît évident. Car comme je l'ai dit, ce n'est pas parce que ton travail provient de la recherche universitaire que cela est forcément bénéfique. On ne va pas lister le nombre de prédictions théoriques de la recherche fondamentale (dont sur les noyaux de système d'exploitation) qui n'ont jamais su percer dans l'industrie faute d'adéquation en réalité.
        
        Démontrer comment, par l'exemple ? Mais, de mon point de vue, un fait ne prouve pas grand chose : je m'intéresse surtout aux méthodes et à leur limite. Je suis un obsédé de la certitude : qu'est-ce que la certitude ? de quoi peut-on être certain ? quelles méthodes peuvent espérer atteindre à la certitude, lesquelles ne le peuvent pas ? font partie des questions qui m'obsèdent. Et de ce point de vue, l'induction et la méthode expérimentale reviennent à cela :
        
        l'expérience ne donne jamais à ses jugements une universalité vraie et rigoureuse, mais seulement supposée ou comparative, si bien que cette universalité doit proprement signifier : Pour autant que nous l'ayons perçu jusqu'ici, il ne se trouve pas d'exception à telle ou telle règle.
        
        Kant, introduction de la Critique de la Raison Pure.
        
        ou pour citer Einstein résumant la philosophie sceptique de Hume : « l'empirique, dans la connaissance, n'est jamais certain (Hume) ». Il ne fut néanmoins pas convaincu par la réponse kantienne aux objections de Hume : « Kant propose alors une pensée. Sous la forme présentée elle est indéfendable mais elle marque un progrès nette pour résoudre le dilemme de Hume ». Pour ma part, je la trouve on ne plus défendable, et la méthode qu'il employa est analogue à celle utilisée par tous les systèmes de types des langages de programmations. Pour pousser le distinguo à l'extrême : je n'ai aucune certitude que le soleil se couchera se soir, mais je n'ai aucun doute quant à ce qu'exprime le théorème de Pythagore.
        
        Pour revenir aux outils d'analyses et de sécurisation de code, il ne s'agit pas nécessairement de spécifier dans les moindres détails chaque bout de code et d'apporter la preuve du respect de la spécification, mais il est peut être envisageable d'ajouter certaines annotations en commentaires (à la manière de frama-c) pour avoir un système de type à l'expressivité plus riche que celui du C. Le système de type de C, de fait, exprime des spécifications sur le code mais, comme c'est peu ou prou la logique propositionnelle du premier ordre, on ne peut pas y exprimer grand chose : ce que fait le code et comment l'utiliser est beaucoup trop sous-spécifié avec un tel système de type.
        
        Prenons un exemple. Je ne connaissais Coccinelle que de nom, je suis allé voir un peu leur site, et sur la page consacrée aux évolutions collatérales ils donnent deux exemple : ajout d'un argument à une fonction et changement dans le protocole d'initialisation des pilotes. Il semblerait que les pilotes aient mis un certain temps à s'adapter correctement à ce changement d'interface dans le cœur du noyau. Ces changements il faut bien les documenter quelque part ? Pourquoi pas dans une langue proche par sa syntaxe et son vocabulaire de l'anglais, mais à la grammaire plus régulière, et l'écrire en commentaire du code modifié ? On pourrait alors avoir une logiciel d'aide à l'audit qui détecterait automatiquement les mauvais usages des nouveaux codes.
        
        Entre un audit totalement manuel et un audit partiellement automatisé, dans le monde de l'informatique ça doit pouvoir convaincre (pourquoi faire à la main ce qu'une machine peut faire pour moi ?). Je ne suis membre d'aucune des deux communautés (celle du noyau et celle de la recherche), mais je sais que la seconde est en état de fournir ce genre d'outil à la première. Néanmoins, pour cela, il faudrait une coopération et une synergie entre elles qui ne semblent pas exister aux dires de gasche. Je ne peux que trouver cela dommage.
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par kantien le 01 novembre 2017 à 11:29. Évalué à 4.
        
        J'imagine que les usagers de ce genre de DSL sont docteur en mathématique pour le calcul linéaire. Je ne vois pas qui d'autres pourraient s'en servir vu le formalisme mathématique retenu.
        
        Tu ne penses pas que tu exagères un peu là ? C'est du niveau premier cycle en mathématique (allez, fin de premier cycle pour être gentil).
        
        Exemple sur la définition du produit scalaire :
        
        dot = λxs ys. (reduce (+) 0 ◦ map (∗)) (zip xs ys)
        
        et sa traduction en python :
        
        from operator import mul dot = lambda xs,ys: sum(map(mul, xs, ys),0) >>> dot([1,2], [3,4]) 11
        
        la fonction zip existe aussi en python :
        
        >>> zip([1,2],[3,4]) [(1, 3), (2, 4)]
        
        la différence étant que les fonctions map n'ont pas la même interface entre les deux langages. La définition du produit scalaire entre vecteurs en python, je l'ai prise de la documentation python officielle. Sinon, voir aussi cette réponse sur stackoverflow :
        
        from operator import add, mul sum_r = lambda xs: reduce(add, xs, 0) dot = lambda *lists: sum_r(reduce(mul, data) for data in zip(*lists)) >>> dot([1,2], [3,4]) 11
        
        C'est du python on ne peut plus idiomatique.
        
        Et ne me parle pas de je ne sais quel grade doctoral : j'ai le même grade universitaire qu'un ingénieur, à savoir un bac+5.
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Nicolas Boulay (site web personnel) le 02 novembre 2017 à 13:19. Évalué à 2.
        
        Et ne me parle pas de je ne sais quel grade doctoral : j'ai le même grade universitaire qu'un ingénieur, à savoir un bac+5.
        
        Je suis ingénieur, et je n'avais pas entendu parler de Lambda avant de faire un dea d'info. C'est peut être un choix de mon école, mais je n'ai pas cette impression-là.
        
        Autant le code python me parle (je ne connais pas du tout ce langage), autant le DSL ne me parle pas.
        
        "La première sécurité est la liberté"
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par kantien le 02 novembre 2017 à 15:04. Évalué à 3. Dernière modification le 02 novembre 2017 à 15:07.
        
        Je suis ingénieur, et je n'avais pas entendu parler de Lambda avant de faire un dea d'info.
        
        Moi aussi, je n'avais jamais entendu parler de lambda-calcul avant mon DEA. Ce que je voulais dire, dans le fond, c'est que le niveau d'abstraction requis pour le comprendre relève du premier cycle en mathématique (une fois que l'on a expliqué ce que signifie le lambda, ce qui prend deux minutes). Tu trouves (si je me fie à ce que j'ai déjà lu) que elm est un bon langage pour faire du développement web : ce type de code doit être assez standard en elm. Elm a la même syntaxe que Haskell où le lambda est remplacé par l'anti-slash \, c'est tout. Après c'est du map-reduce, on ne peut plus classique en programmation fonctionnel, ce qui n'exige pas un niveau de compréhension d'un niveau doctoral.
        
        En OCaml, on l'écrirait ainsi :
        
        (* reduce c'est tout simplement fold_left *) let reduce = List.fold_left (* opérateur de composition infixe *) let (<.>) f g = fun x -> f (g x) let map = List.map let zip = List.combine let mul (a,b) = a * b let sum = reduce (+) 0 (* le lambda c'est le mot-clé fun *) let dot = fun xs ys -> (sum <.> map mul) (zip xs ys) dot [1; 2] [3; 4];; - : int = 11
        
        L'avantage pour des chercheurs de passer par du lambda-calcul, sans ajouter trop de sucre syntaxique, est d'avoir rapidement un prototype opérationnel comme preuve de concept.
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par kantien le 04 novembre 2017 à 09:54. Évalué à 5.
        
        Autant le code python me parle (je ne connais pas du tout ce langage), autant le DSL ne me parle pas.
        
        Là, il y à un truc que je ne comprends pas du tout. Je n'avais pas prêté attention au message de ta part auquel gasche t'a répondu en présentant ce DSL, mais tu y reprochais à OCaml de ne pas générer des instructions SIMD en écrivant :
        
        De plus, ocaml pourrait faire des map et fold sur des array de nombres, et proposer des versions vectorisés des opérations en question.
        
        Il te répond avec un langage qui fait cela pour du code sur GPU, et tu réponds que ça ne te parle pas ? C'est quoi le problème ? Qu'ils utilisent la lettre $\lambda$ pour définir des fonctions ? Qu'ils écrivent reduce et non fold ?
        
        Si j'écris cela :
        
        let (<.>) f g = fun x -> f (g x);; let dot = fun xs ys -> Array.(fold_left (+) 0 <.> map2 ( * ) xs) ys dot (Array.of_list [1; 2]) (Array.of_list [3; 4]);; - : int = 11
        
        alors tu comprends, mais tu voudrais que cela génère du code optimisé avec instructions SIMD ?
        
        Mais quand on écrit :
        
        dot = λxs ys. (reduce (+) 0 ◦ map (∗)) (zip xs ys)
        
        alors tu ne comprends plus ?
        
        On pourrait rendre le code python encore plus concis avec :
        
        dot = lambda xs,ys: sum([a * b for a,b in zip(xs, ys)])
        
        mais quand on sait ce qu'est un fold (ou reduce), un map et une composition de fonctions, l'équivalence des deux écritures est évidente.
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Nicolas Boulay (site web personnel) le 06 novembre 2017 à 11:53. Évalué à 4.
        
        Il te répond avec un langage qui fait cela pour du code sur GPU, et tu réponds que ça ne te parle pas ? C'est quoi le problème ? Qu'ils utilisent la lettre \lambda pour définir des fonctions ? Qu'ils écrivent reduce et non fold ?
        
        Attention ne de pas tout mélanger. Le journal est a propos de la qualité des langages, de leur "ergonomie". Un des principes de l'ergonomie est le principe de "moindre surprise". Trouver un langage utilisant des caractères qui ne sont même pas présent sur un clavier, c'est "surprenant".
        
        A force d'explication, personnellement, je comprends le lien entre lambda/map/fold/reduce, mais je pensais plus général, à l'acceptation du langage dans un cadre bien plus large.
        
        Je ne suis pas sûr que la concision soit le principal moyen pour arriver à la "clarté".
        
        "La première sécurité est la liberté"
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par gasche le 01 novembre 2017 à 11:34. Évalué à 8.
        
        L'idée est sympa. J'imagine que les usagers de ce genre de DSL sont docteur en mathématique pour le calcul linéaire. Je ne vois pas qui d'autres pourraient s'en servir vu le formalisme mathématique retenu.
        
        Encore une fois, ce n'est pas le métier des chercheurs que de développer une interface facile d'accès à leur travail. Il y a un petit prototype pour démontrer l'idée, qui fait mieux que l'existant question performance. Si quelqu'un veut prendre ça et en faire une bibliothèque grand public, je suis sûr que les auteurs de ce travail seraient volontaires pour donner des conseils et participer et aider, mais ce serait déraisonnable de leur part de s'y attaquer seuls—parce que ce n'est pas leur métier et que les gens qui les emploient leur demanderaient des compte sur l'usage de leur temps de travail.
        
        C'est un peu facile de ta part : tu commences par dire qu'il n'y a pas de recherche sur des langages efficaces (que le milieu de recherche n'a pas les priorités qui t'intéressent), et maintenant je te montres qu'il y en a et ta réponse c'est que c'est trop de la recherche ! Tu voudrais un truc tout cuit, mieux que l'existant, déjà prêt pour être utilisé par tout le monde, et puis un café aussi ?
        
        Il y a une incompréhension de fond sur la façon dont les universitaires travaillent, quel est leur but. Je trouve assez déplacé de me dire ensuite que (quand je parle en tant que chercheur) je suis ignorant et méprisant, alors que moi justement je fait l'effort de bien connaître et de comprendre ces deux milieux dont je suis membre, et de dire ensuite ce qui me semble poser problème.
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Nicolas Boulay (site web personnel) le 02 novembre 2017 à 13:34. Évalué à 5.
        
        Encore une fois, ce n'est pas le métier des chercheurs que de développer une interface facile d'accès à leur travail.
        
        Vous avez pourtant des chercheurs en ergonomie.
        
        Si quelqu'un veut prendre ça et en faire une bibliothèque grand public,
        
        Qui pourrait faire ça ? C'est ça qui me pose le plus de problème. Qui est assez doué pour comprendre le "langage de la recherche" et en même temps en faire un produit industriel.
        
        C'est un peu facile de ta part : tu commences par dire qu'il n'y a pas de recherche sur des langages efficaces (que le milieu de recherche n'a pas les priorités qui t'intéressent), et maintenant je te montres qu'il y en a et ta réponse c'est que c'est trop de la recherche !
        
        Non, pas trop de la recherche, mais trop frustrant de ne pas pouvoir facilement s'en servir simplement parce que le formalisme retenu est celui des maths et non celui de l'informatique. Un tel DSL serait énorme pour un projet comme The Gimp ou CIMG, mais je ne suis pas sûr qu'ils aient la compétence pour le mettre en œuvre.
        
        Tu voudrais un truc tout cuit, mieux que l'existant, déjà prêt pour être utilisé par tout le monde, et puis un café aussi ?
        
        Et sans sucre s'il te plait.
        
        Il y a une incompréhension de fond sur la façon dont les universitaires travaillent, quel est leur but.
        
        Oui et non. Je comprend ce que tu veux dire. Mais en même temps, une des mission de la recherche est de transmettre ce savoir acquis. Si la différence de savoir augmente entre les ingénieurs et les chercheurs, c'est bien qu'il manque un rouage de transmission. (Peut-être qu'il faudrait dans les écoles d'ingénieur, en plus des stage en entreprise, des stages en labo de recherche.)
        
        Je trouve très frustrant d'avoir autant de mal à lire les papiers de recherche en informatique, je ne me considère pas pourtant comme un mauvais ingénieur. Si les ingénieurs moyens sont incapables de comprendre vos publications, comment la transmission pourrait se faire ?
        
        "La première sécurité est la liberté"
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par gasche le 03 novembre 2017 à 10:56. Évalué à 4.
        
        Qui pourrait faire ça ? C'est ça qui me pose le plus de problème. Qui est assez doué pour comprendre le "langage de la recherche" et en même temps en faire un produit industriel.
        
        Déjà, il y a des gens dont c'est le métier, c'est appelé la R&D, Recherche et Développement. Les ingénieurs R&D sont (en théorie) là pour faire le transfert entre la recherche et l'industrie.
        
        Ensuite, il me semble qu'une autre réponse (en particulier dans le cadre du logiciel libre) c'est : "une équipe avec des compétences mixtes". Tu mets des chercheurs et des développeurs noyau ensemble, et tu les fais discuter, sur le long terme.
        
        Un des rôles de la recherche est de transmettre le savoir, certes, mais on ne peut pas forcer les gens à écouter si ça ne les intéresse pas, s'ils ne sont pas prêt à faire un effort pour comprendre et participer. Si la volonté est là, c'est très facile d'obtenir d'un chercheur qu'il parle d'une façon compréhensible à des ingénieurs, il suffit d'envoyer un mail pour lui poser des questions, et de signaler quand on ne comprend pas quelque chose. (Ou alors d'aller à ses cours et ses exposés, et de poser des questions ensuite.)
        
        Mais il faut que les gens se lançant dans une telle discussion soient conscients des rôles de chacun pour qu'elle soit productive. Si tu commences à discuter en espérant, au bout de quelques emails, pouvoir appliquer directement le résultat développé dans un cadre simplifié, purifié à ton gros projet de la vraie vie, tu vas sans doute être assez déçu. Il faut être prêt à entrer dans une boucle d'itération sur le moyen/long terme, avec des choses qui marchent partiellement au milieu.
        
        Il y a des gens qui le font, par exemple qui testent Compcert sur tous les paquets OpenBSD et qui font des rapports d'erreur quand quelque chose coince (exemple). Ce travail peut mettre quelques années à aboutir, et le résultat (qu'on peut compiler OpenBSD avec un compilateur vérifié) n'est qu'une brique de base qui pourrait servir à d'autres choses ensuite.
        
        Encore une fois, une bonne façon de faciliter encore ces échanges et de faire avancer les choses plus vite, c'est aussi de donner des sous (les chercheurs sont contraints en temps et en financement). Si la Linux Foundation avait sérieusement envie de faire avancer le sujet, elle pourrait facilement financer des thèses, dans des laboratoires de recherche, appliquées sur le noyau Linux. Les gens de Mozilla font ça, ils viennent à nos conférences (de recherche) et ils disent, clairement, "si vous avez des gens qui veulent travailler sur des sujets qui nous concernent, on peut les financer, les accueillir en stage chez nous pour leur faire découvrir nos problématiques, contactez nous". Et ça a un effet direct sur l'évolution de Rust par exemple.
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Nicolas Boulay (site web personnel) le 03 novembre 2017 à 14:08. Évalué à 3.
        
        Déjà, il y a des gens dont c'est le métier, c'est appelé la R&D, Recherche et Développement. Les ingénieurs R&D sont (en théorie) là pour faire le transfert entre la recherche et l'industrie.
        
        J'en suis un. Mais non, c'est pas simple du tout. Il n'y a pas de contact avec la recherche, ni le même vocabulaire (d'où ma proposition de stage de fin d'année en + du stage en entreprise) .
        
        Il faut être prêt à entrer dans une boucle d'itération sur le moyen/long terme, avec des choses qui marchent partiellement au milieu.
        
        En face, tu as des devs qui font une release avec 1000 commits "corrects" avec un niveau de qualité assez élevé toutes les 6 semaines sur un code de 20 Millions de lignes. Tu imagines la quantité de travail que cela représente en intégration.
        
        Je pense que si c'est difficile de convaincre Linus, cela doit être plus facile de le faire pour les responsables de sous système qui travaillent pour Google, Red Hat, Oracle, Sony ou Intel, voir pour un fondeur comme TI, ST, Qualcomm, ou Infineon.
        
        Mozilla est dans dans une pente descendante, elle perd des utilisateurs et à rater le mobile. Elle recherche de l'aide autour d'elle. Linux a l'inverse est présent absolument partout, sauf dans le desktop Windows et le monde Apple.
        
        "La première sécurité est la liberté"
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par gasche le 03 novembre 2017 à 15:15. Évalué à 5.
        
        Il n'y a pas de contact avec la recherche, ni le même vocabulaire.
        
        Si tu es dans un département R&D mais que tu ne peux pas entrer en contact avec la recherche, c'est que soit tu es mal formé (initialement, peut-être, mais aussi et surtout la formation continue qu'une boîte de R&D doit assurer en encourageant ses employés à suivre l'état de l'art, par exemple en allant aux conférences importantes du domaines), soit on se moque de toi et le titre "R&D" est juste là pour faire plus prestigieux et prendre des crédits impôts-recherche, mais est vidé en pratique de sa substance.
        
        C'est très courant, surtout dans les boîtes qui n'ont en fait pas de problème technique difficile à résoudre et n'ont donc pas vraiment besoin d'une branche R&D qui fait du vrai boulot. Ou alors des boîtes qui ne se rendent pas compte de l'intérêt qu'elles auraient à faire sérieusement de la R&D — parce que ça veut dire accepter des projets exploratoires, une incertitude sur le moyen terme, des besoins importants de réelle formation continue, etc., et que tout ça n'est pas facile à manager.
        
        (Il y a aussi des boîtes avec de la vraie R&D. Quand on discute avec les gens de la R&D d'EDF par exemple, on sent qu'ils sont très câlés sur leurs sujets.)
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Nicolas Boulay (site web personnel) le 03 novembre 2017 à 15:43. Évalué à 2.
        
        C'est très courant, surtout dans les boîtes qui n'ont en fait pas de problème technique difficile à résoudre et n'ont donc pas vraiment besoin d'une branche R&D qui fait du vrai boulot.
        
        La R&D, c'est surtout du 'D' et pas beaucoup de recherche.
        
        (Il y a aussi des boîtes avec de la vraie R&D. Quand on discute avec les gens de la R&D d'EDF par exemple, on sent qu'ils sont très câlés sur leurs sujets.)
        
        Et se sont souvent des docteurs, et des boites de la taille d'EDF, il n'y a pas 50.
        
        Je ne crois pas avoir vu de boites faisant de la recherche sans docteur dans le domaine.
        
        "La première sécurité est la liberté"
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par gasche le 03 novembre 2017 à 19:03. Évalué à 5.
        
        Il n'y a pas besoin de "faire de la recherche" pour être légitime dans ce domaine—la R&D, l'idée n'est pas en général de produire de la recherche nouvelle (même si parfois ça arrive), mais quand même d'avoir le niveau scientifique pour pouvoir interagir avec la recherche du domaine (les travaux écrits et/ou le personnel de recherche). Mais oui, embaucher des docteurs peut aider pour ça — et c'est quelque chose que les entreprises françaises ne font peut-être pas assez par rapport aux américaines par exemple.
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Nicolas Boulay (site web personnel) le 02 novembre 2017 à 15:32. Évalué à 3. Dernière modification le 02 novembre 2017 à 15:36.
        
        Aurais-tu la page ou l'on peut avoir ce compilateur DSL, je n'arrive pas à le trouver ?
        
        c'est ça ? http://www.lift-project.org/
        
        "La première sécurité est la liberté"
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par gasche le 03 novembre 2017 à 12:42. Évalué à 2.
        
        Oui, vu les auteurs en commun c'est bien le même projet.
        
        Dans le genre, un autre DSL issu de la recherche et qui pourrait intéresser les gens de Gimp (par exemple) est Halide.
        
        Un tel DSL serait énorme pour un projet comme The Gimp ou CIMG, mais je ne suis pas sûr qu'ils aient la compétence pour le mettre en œuvre.
        
        C'est une bonne idée, tu devrais envoyer un mail aux gens de Gimp/CIMG pour leur demander s'ils ont étudié ces DSLs et envisagé de les utiliser. (Je crois que les gens de CIMG n'ont pas du tout réfléchi à comment migrer des calculs sur des GPUs, pour l'instant, mais ces langages pourraient déjà accélérer les implémentations CPU.)
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Nicolas Boulay (site web personnel) le 03 novembre 2017 à 14:15. Évalué à 3.
        
        Halide est un tout nouveau langage, c'est compliqué de demander à un gros projet comme Cimg de tout recoder son C++ dans un nouveau truc, sachant que l’auto-vectorisation fonctionne, et openMP aussi.
        
        "La première sécurité est la liberté"
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Nicolas Boulay (site web personnel) le 03 novembre 2017 à 14:21. Évalué à 3.
        
        Bon, on dirait que c'est une lib C++, cela simplifie beaucoup de chose pour s'intégrer.
        https://github.com/halide/Halide/wiki/Static-vs.-JIT-compilation
        
        "La première sécurité est la liberté"
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Nicolas Boulay (site web personnel) le 31 octobre 2017 à 09:29. Évalué à 4.
        
        Si tu veux des références plus précises, peux-tu en dire plus sur ce que tu cherches ? (Quel genre de code ?)
        
        Un langage de haut niveau qui va vite.
        
        En général, les langages "rapides" laissent tout le boulot au codeur (asm, c, c++, fortran). C++ avec les templates proposent un moyen de mettre la complexité en library avec le prix d'une grosse difficulté et des messages d'erreur abscons (et donc des bugs). Ce genre de langage trop bas niveau fournis un code rapide sur une machine, mais qui peut être plus lent sur un autre (intel vs amd ou vs ARM), multicore ou pas, SIMD ou pas.
        
        Les compilateurs C/C++ vont très loin dans les optimisations mais sont bridés par le langage lui-même : gestion mémoire basique et explicite (il faut une grande rigueur pour gérer des pools de mémoires et éviter la fragmentation), layout mémoire fixée dans les structures (optimisation par structures de tableaux au lieu de tableaux de structures impossible), code IEE754 immodifiable (sans changer le résultat final), pointeur trop générique qui nécessite un gros travail "d'analyse de vie" pour éviter l'aliasing. Le SIMD est de mieux en mieux géré, mais le multicore reste complexe sauf avec openMP. Par contre utiliser directement les GPU restent encore très expérimental : il suffit de voir la tronche du code opencl avec des string à envoyer au driver de la carte graphique !
        
        Rust permet une bien meilleur gestion mémoire, mais compile moins bien que gcc. "tensor flow" semble pouvoir décrire du code rapide pour plusieurs architectures très différentes, mais cela n'est pas un langage.
        
        On peut aussi parler des optimisations par propagation de constantes qui se limitent aux littéraux basiques, mais pas au 'string' (utile pour les regexp ou même un code SQL embarqué), et je ne parle pas de container constant (AST, lecture de fichier externe, genre configuration en XML, image embarquées ou même un DSL quelconque).
        
        "La première sécurité est la liberté"
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par kantien le 27 octobre 2017 à 09:40. Évalué à 2. Dernière modification le 27 octobre 2017 à 09:41.
        
        La logique peut aussi vérifier la cohérence interne des connaissances des experts sur leur sujet. […] Mais du point de vue de la cohérence, ça peut lever des lièvres.
        
        Oui car telle est son affaire, elle peut montrer l'incohérence d'une formalisation. Pour ce qui est de prouver la cohérence, par contre…
        
        Ça me rappelle ce passage humoristique dans la partie remerciements de la thèse de Perthmâd (qui, s'y j'en crois les notes de publication de la toute récente dernière version de Coq, a fait un gros travail de nettoyage et d'optimisation du langage des tactiques) :
        
        — Un thésard demanda à Hugo Herbelin : « Coq est-il cohérent ? »
        — Anomaly: Uncaught exception Mu.
        
        Par malheur, l’histoire omet de raconter si l’étudiant fut illuminé ou bien s’il l’était déjà à l’instant même où il songea à passer un doctorat d’informatique fondamentale 5 [1].
        
        [1]Par contre, l’histoire précise bien que le rapport de bug qui s’en suivit fut marqué WontFix par un certain kgoedel. Ce n’est pas dans le privé qu’on verrait ça.
        
        Dans une démarche également historique, le passage que j'ai cité de la Critique de la Raison Pure est extrait du paragraphe sur la question « Qu'est-ce que la vérité ? » qui commence ainsi :
        
        La vielle est célèbre question, par laquelle on se figurait pousser les logiciens dans leur retranchement et on cherchait à les amener, ou à devoir se laisser surprendre dans un pitoyable diallèle, ou bien à devoir avouer leur ignorance, et par la suite la vanité de tout leur art, est celle-ci : Qu'est-ce que la vérité ? La définition nominale de la vérité, qui en fait la conformité de la connaissance avec son objet, est ici accordée et supposée; mais on veut savoir quel est le critère universel et sûr de la vérité de toute connaissance.
        
        C'est déjà une grande et nécessaire preuve de sagesse et de pénétration que de savoir ce que l'on doit raisonnablement demander. En effet, si la question est absurde en soi et si elle appelle parfois, outre la confusion de celui qui la soulève, l'inconvénient de porter à des réponses absurdes l'auditeur qui n'est pas sur ses gardes, et de donner ainsi le ridicule spectacle de deux personnes, dont l'un trait le bouc (comme disaient les anciens), tandis que l'autre tend un tamis.
        
        Si la vérité consiste dans l'accord d'une connaissance avec son objet, cet objet doit être par là distinguer des autres; car une connaissance est fausse, si elle ne s'accorde pas avec lequel elle est rapportée, alors même qu'elle pourrait bien valoir pour d'autres objets. Or, un critère universel de la vérité serait celui qui vaudrait pour toutes les connaissances, sans distinction de leurs objets. Mais il est clair, puisqu'on y fait abstraction de tout contenu de la connaissance (du rapport à son objet), et que la vérité à trait justement à ce contenu, qu'il est tout à fait impossible et absurde de demander une marque de la vérité de ce contenu des connaissances, et qu'on ne peut donc proposer une caractéristique suffisante et en même temps universelle de la vérité. Comme nous avons déjà nommé plus haut le contenu de la connaissance sa matière, on devra dire : On ne peut demander aucune caractéristique universelle de la vérité quant à sa matière, parce que c'est en soi contradictoire.
        
        Kant, Critique de la Raison Pure.
        
        On trouve des considérations identiques dans le traité qu'il consacra à la logique. Premièrement, ce qu'il appelle la définition nominale de la vérité est celle que l'on utilise toujours de nos jours sous le nom de définition tarskienne de la vérité à la base de la sémantique tarskienne (utilisée en théorie des modèles). Ensuite, si l'on combine le théorème de Gödel auquel Perthmâd fait allusion (le théorème d'incomplétude) à une autre théorème fondamentale de Gödel (son théorème de complétude : une théorie est cohérente si et seulement si elle a un modèle), on aboutit à la conclusion du texte kantien cité ci-dessus. Une théorie (disons ZF, la théorie axiomatique des ensembles) qui fournirait un critère matérielle de sa vérité serait en mesure d'engendrer son propre contenu (fournirait un modèle d'elle-même), serait donc cohérente (en vertu du théorème de complétude) ce qui contredirait le théorème d'incomplétude.
        
        Le théorème d'incomplétude clos une période historique au cours de laquelle la thèse centrale de la Critique de la Raison Pure fut attaqué de toute part par des logiciens, et Gödel finit par donner raison à Kant. :-)
        
        On gagne déjà beaucoup à pouvoir faire tenir une foule de recherche sous la formule d'un seul problème. Par là, en effet, on ne facilite pas seulement pour soi-même son propre travail, en se le déterminant avec précision, mais on rend aussi plus facile à quiconque veut l'examiner de juger si nous avons ou non satisfait à notre dessein. Le problème propre de la raison pur est donc contenu dans la question suivante : Comment des jugements synthétiques a priori sont-ils possibles ? […]
        
        Dans la solution du problème précèdent est engagée en même temps la possibilité du pur usage de la raison pour fonder est développer toutes les sciences qui contiennent une connaissance théorique a priori des objets, c'est-à-dire la réponse à ces questions :
        
        Comment la mathématique pure est-elle possible ?
        
        Comment la physique pure est-elle possible ?
        
        Kant, ibid.
        
        À cette subdivision de la question, précède le texte suivant :
        
        Les jugements mathématiques sont tous synthétiques. Cette proposition semble avoir échappé jusqu'ici aux observations des analystes de la raison humaine, et même être exactement opposée à toutes leurs conjectures, bien qu'elle soit incontestablement certaine et très importantes dans ses conséquences. En effet, comme on trouvait que tous les raisonnements mathématiques procédaient tous d'après le principe de contradiction (ce qu'exige la nature de toute certitude apodictique) on se persuada que les principes étaient connu aussi étaient connus à partir du principe de contradiction : en quoi ces analystes; car une proposition synthétique peut bien être saisie d'après le principe de contradiction, mais seulement de telle sorte qu'une autre proposition synthétique soit supposée, d'où elle puisse être déduite, mais jamais en elle-même.
        
        Kant, ibid.
        
        Ce qu'a prouvé Gödel, c'est que la logique formelle (et donc le principe de contradiction) ne peut légitimer à elle seule le raisonnement par récurrence : le principe du raisonnement par récurrence est un pur jugement synthétique a priori.
        
        Il y a un membre de linuxfr qui a pour signature quelque chose du style : «BeOS le faisait déjà il y a vingt ans ». Pour ma part, d'une manière générale, je dirais : ce que font les théories des types contemporaines, Kant le faisait déjà il y a plus de 200 ans. Par exemple, la logique de Hoare utilisée par frama-c, c'est dans la Critique de la Raison Pure; ou bien la programmation par contrat, la gestion de propriété des espaces mémoires par Rust ou Mezzo, c'est dans la Doctrine du Droit (que l'on peut voir comme une théorie de typage du droit romain). :-)
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Thomas Douillard le 27 octobre 2017 à 12:15. Évalué à 2.
        
        Il y a quand même une légère différence dans les détails :) J’ai l’impression que tu décris une sorte de « principe de réflexion » de la pensée abstraite dans la logique formelle, comme dans l’univers constructible de Gôdel ( http://www.madore.org/~david/weblog/d.2013-03-19.2124.constructible.html ) ou les ensembles et leur structure décrit par un rang inférieur se reflètent dans les rangs supérieurs de différentes manières.
        
        Les principes abstraits en langage naturel de Kant se reflètent dans les méthodes formelles modernes. Mais enrichis :)
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par kantien le 27 octobre 2017 à 15:27. Évalué à 2. Dernière modification le 27 octobre 2017 à 15:28.
        
        Il y a quand même une légère différence dans les détails :)
        
        Pas spécialement, le principe que je décris est celui qu'a utilisé Gödel pour démontrer son fameux théorème d'incomplétude : une théorie assez riche (au pouvoir expressif suffisant) pour parler d'elle même a toujours des énoncés indécidables (qu'elle ne peut ni prouver ni réfuter) et parmi ceux-ci figurent toujours sa propre cohérence (sa non contradiction). Ce que je dis c'est que si une théorie est assez riche (comme l'est ZF) pour exprimer les principes de la théorie des modèles et donc parler de la relation entre la forme et le contenu (ce en quoi consiste la vérité) alors elle ne peut engendrer son propre contenu (elle ne peut construire un modèle d'elle même) et fournir un critère matériel et universelle de la vérité, sous peine d'être incohérente d'après le théorème d'incomplétude. Dans ce cas, comme elle peut prouver tout et n'importe, on ne peut nullement avoir confiance dans ce qu'elle prétend affirmer.
        
        Cette démarche consiste à réfléchir la métathéorie dans la théorie elle même, c'est le même genre d'argument qu'a utilisé Turing pour prouver l'impossibilité de résoudre le problème de l'arrêt pour sa machine universelle. D'un point de vue programmation, cela revient à dire qu'un langage ne peut se compiler lui-même sans une phase de bootstrap : il faut un coup de pouce extérieur au langage de programmation.
        
        J’ai l’impression que tu décris une sorte de « principe de réflexion » de la pensée abstraite dans la logique formelle, comme dans l’univers constructible de Gôdel ( http://www.madore.org/~david/weblog/d.2013-03-19.2124.constructible.html ) ou les ensembles et leur structure décrit par un rang inférieur se reflètent dans les rangs supérieurs de différentes manières.
        
        L'univers des constructibles de Gödel sert à prouver des théorèmes de consistance relative : si ZF est non contradictoire alors il en est de même de ZF augmentée de l'axiome du choix, ce dernier axiome n'introduit pas de contradiction dans la théorie. C'est du même ordre que les théorèmes de consistance relative que Poincaré a effectués au XIXème entre les géométries euclidienne et non euclidiennes. Le cercle de Poincaré, construit dans un espace euclidien, permet d'interpréter les axiomes de la géométrie hyperbolique. Autrement dit, si la géométrie euclidienne est cohérente alors il en est de même de l'hyperbolique.
        
        En revanche aux questions : l'arithmétique est-elle cohérente ? la géométrie est-elle cohérente ? ZF est-elle cohérente ? la logique et son principe de contradiction est incapable d'y répondre. La seule chose qu'elle peut faire c'est prouver la cohérence d'une théorie en admettant la cohérence d'une autre. Par exemple, on peut prouver la cohérence de l'arithmétique à partir de ZF, mais reste la question : ZF est elle cohérente ? On peut continuer en ajoutant des axiomes de grands cardinaux qui prouvent la consistance de ZF (ils fournissent un modèle de celle-ci), mais reviens alors la question : ses nouveaux axiomes sont-ils cohérents ? Et cette approche turtles all the way down la logique formelle ne peut en sortir, pour la simple raison que, laissée à elle même, elle n'engendre que des tautologies (l'art de M. de La Palice) et est incapable de répondre à la question : comment des jugements synthétiques a priori sont-ils possibles ?
        
        Les principes abstraits en langage naturel de Kant se reflètent dans les méthodes formelles modernes. Mais enrichis :)
        
        Ça se discute, ils ne sont nullement enrichis, ce sont les mêmes mais exprimés dans une langue différente. Un principe ne deviendrait ni plus vrai, ni plus clair, ni plus riche sous prétexte qu'il serait exprimés en français plutôt qu'en anglais (ou vice versa). La méthode kantienne est on ne peut plus formelle (il n'y a pas plus formaliste qu'un kantien), et les langues naturelles sont tout à fait adaptées pour exprimer de tels principes. Il n'est pas nécessaire de recourir à des symbolismes compréhensibles par une machine (ce qui n'est d'ailleurs adapté qu'à la formalisation de la pensée mathématique mais nullement à la pensée philosophique, comme les problèmes de philosophie du droit) pour formaliser sa pensée : je préfère de loin l'usage du français à Coq, par exemple. Les langues naturelles ont, en leur sein, un système à type dépendant mais une grammaire plus complexe que les grammaires régulières des langages de programmation (il suffit de voir la difficulté que rencontre l'auteur de grammalecte, ou tous ceux qui travaillent sur le traitement automatique des langues).
        
        Prenons, un principe de base de la logique de Hoare utilisée pour la formalisation des langages impératifs, celui de la composition des instructions :
        
        { P } S { Q } { Q } T { R } ---------------------------- { P } S ; T { R }
        
        une expression de la forme { P } S { Q } se lit : l'instruction S fait passer le système de l'état P à l'état Q. Une telle règle ce lit alors : si l'instruction S fait passer la machine de l'état P à l'état Q et que l'instruction T fait passer de l'état Q à l'état R, alors la série d'instructions S ; T fait passer de l'état P à l'état R.
        
        Il se trouve que c'est l'analogue dans le paradigme de la programmation fonctionnelle pure de la composition des fonctions :
        
        fun f g x -> g (f x);; - : ('a -> 'b) -> ('b -> 'c) -> 'a -> 'c = <fun>
        
        A --> B B --> C ------------------ A --> C
        
        Autrement dit, des deux prémisses si A alors B et si B alors C, on conclue à si A alors C. Cela résulte d'une double application de la règle dite du modus ponens :
        
        si A alors B, or A donc B (modus ponens utilisant la première prémisse et l'hypothèse A)
        
        si B alors C, or B donc C (modus ponens utilisant la seconde prémisse et la conclusion du syllogisme hypothétique précédent)
        
        ainsi en supposant A on conclue à C, c'est à dire que l'on a prouvé si A alors C. Ce genre de preuve, quelque peu pédante, est ce que nous oblige à écrire Coq (il offre quand même des techniques pour éviter de rentrer autant dans les détails).
        
        Ce que Kant a prouvé, par exemple, dans la Critique de la Raison Pure c'est que le concept de cause (qui sert à expliquer les changements d'états des choses réelles dans le monde physique) n'est pas un concept d'origine empirique, mais un concept que nous imposons nous même à la nature en vertu de la structure formelle de notre esprit et qu'il a pour type (là j'emploie une terminologie contemporaine) la forme logique des jugements hypothétiques (si A alors B).
        
        On pourrait exprimer le principe fondamentale de la dynamique de Newton ainsi dans un tel symbolisme : { p } F { p + F * dt}. Autrement dit, un corps dans l'état de mouvement p et soumis à une force F se retrouve dans l'état { p + F * dt } au bout d'un temps infiniment petit dt. L'on retrouverait ainsi les considérations entre les sémantiques petit pas (small step) ou grands pas (big step), auxquelles gasche faisait allusion dans ce commentaire, et la distinction entre les lois différentielles et les lois intégrales en physique théorique. La première étant une approche discrète (sémantique des langages de programmation), là où la seconde est continue (physique théorique).
        
        Et c'est ce lien formel entre le principe de causalité et la forme des jugements hypothétiques qui explique que l'on peut construire des machines qui « exécutent » les calculs automatiquement.
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Thomas Douillard le 27 octobre 2017 à 19:36. Évalué à 2.
        
        Ce que Kant a prouvé, par exemple, dans la Critique de la Raison Pure c'est que le concept de cause (qui sert à expliquer les changements d'états des choses réelles dans le monde physique) n'est pas un concept d'origine empirique, mais un concept que nous imposons nous même à la nature en vertu de la structure formelle de notre esprit
        
        Mouais, je t’aurai suivi si tu avis dis que c’est une structure que nous suivons dans la manière dont nous représentons la nature (à la rigueur on peut modéliser les réseaux de neurones qui permettent d’anticiper les mouvements d’un projectile) mais quant-à plier la nature à la manière dont nous la représentons j’ai plus de doutes ;) Après effectivement on peut arguer que le cerveau fait des calculs de probabilité conditionnelles - http://www.college-de-france.fr/site/stanislas-dehaene/course-2012-02-21-09h30.htm très intéressant au passage - de là a dire que l’invention du concept de causalité est subordonnée à ça, ou si nous étions condamnés à l’inventer … Si notre propre observation de notre connaissance intuitive du mouvement (façon métacognition) nous prédestinait à inventer la causalité et à décrire le monde de cette façon, c’est possible par contre. Du coup c’est plutôt par l’émergence de système de survie efficace capable d’anticiper qu’il nous est apparu …
        
        Enfin il faut faire attention à lier (si A alors B) avec un raisonnement causal, tu prends le risque de lier corrélation et causalité. « Si A alors B » en logique, c’est à chaque fois que A, on a B aussi. Pas « A cause B ». Tu parles sans doute des logiques constructives, spécifiquement, qui s’interprètent différemment ( https://en.wikipedia.org/wiki/Constructive_proof )
        
        Ce que je voulais dire par « enrichis » c’est que Kant n’a jamais défini un de ces système formels. Par conséquences les jugements qui y sont afférents lui étaient inaccessibles. Tu peux arguer qu’il est possible de faire la même chose en langage naturel, mais il faut le contraindre de manière à ne garder que les jugements valides dans le système de règle défini. Or il n’a jamais décrit ces contraintes (enfin je te laisse l’infirmer ;).
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par kantien le 28 octobre 2017 à 10:40. Évalué à 2.
        
        Sommaire
        
        Kant et les théories des types
        
        Kant et la physique théorique
        
        Kant et les théories des types
        
        Tu peux arguer qu’il est possible de faire la même chose en langage naturel, mais il faut le contraindre de manière à ne garder que les jugements valides dans le système de règle défini. Or il n’a jamais décrit ces contraintes (enfin je te laisse l’infirmer ;).
        
        Ce que tu me demandes (infirmer la chose) est impossible à effectuer dans un commentaire. Tout ce que je peux dire c'est que les liens entre la philosophie kantienne et les théories des types contemporaines sont une évidence pour qui les connaît : elles procèdent toutes de la même approche méthodologique.
        
        Le mieux que je puisse faire dans un commentaire, c'est pointé du doigt quelques références : Per Martin-Löf et Jean-Yves Girard.
        
        Le second est l'auteur, entre autre, du système F qui est un système de types génériques pour le lambda-calcul : c'est le système de type à la base de langages comme Haskell ou OCaml. Sur sa page personnelle (le lien est sur son au-dessus) tu trouveras une partie intitulée La syntaxe transcendantale :
        
        La syntaxe transcendantale est la justification technique des thèses du fantôme de la transparence. Le programme est exposé dans l'article La syntaxe transcendantale, manifeste (Février 2011).
        
        Le livre en question (le fantôme de la transparence) est celui dont j'ai parlé à gasche dans ce commentaire. Je ferais deux remarques là-dessus. Le qualificatif transcendantale est une référence on ne peut plus explicite à Kant, ce dernier ayant utilisé les expressions philosophie transcendantale ou philosophie critique pour qualifier son œuvre philosophique. Ensuite, à la fin de l'introduction du livre, on peut lire :
        
        Le principal bénéficiaire de cette visite non guidée aura été l'auteur, tout surpris d'y trouver matière à de futurs développements techniques. Et de découvrir la surprenante adéquation du kantisme — au sens large — à la logique contemporaine. Ce qui n'est pas très étonnant après tout : que veut dire « raison pure », sinon logique ?
        
        En ce qui concerne Martin-Löf, il est également l'auteur d'une théorie de types dépendants intuitionnistes. Il a participé au groupe de travail ayant écrit la théorie homotopique des types (HoTT) visant à fournir une alternative à ZF pour le fondement des mathématiques basée sur la théorie des types (ça se comprend, ZF c'est l'archétype du typage dynamique; il n'y a qu'un seul type statique : celui d'ensemble, tout le reste est dynamique, si je peux m'exprimer ainsi). Dans l'introduction du livre HoTT, on lit :
        
        Per Martin-Löf, among others, developed a “predicative” modification of Church’s type system, which is now usually called dependent, constructive, intuitionistic, or simply Martin-Löf type theory. This is the basis of the system that we consider here; it was originally intended as a rigorous framework for the formalization of constructive mathematics.
        
        Martin-Löf est aussi l'auteur d'un article : analytic and synthetic judgements in type theory sur la philosophie kantienne des mathématiques. De même l'omniprésence de Kant dans la première des trois conférences qu'il donna sur la logique en 1983 à Siena devrait te mettre sur la piste.
        
        Lorsque l'on s'occupe à notre époque de théorie des types, éluder toute référence kantienne pourrait s'apparenter, pour reprendre une expression utilisée ailleurs dans les commentaires, à une faute professionnelle.
        
        Kant et la physique théorique
        
        Après effectivement on peut arguer que le cerveau fait des calculs de probabilité conditionnelles - http://www.college-de-france.fr/site/stanislas-dehaene/course-2012-02-21-09h30.htm très intéressant au passage - de là a dire que l’invention du concept de causalité est subordonnée à ça, ou si nous étions condamnés à l’inventer …
        
        Je n'ai pas écouté la conférence mais seulement lu le texte qui l'accompagne. Je ferais deux remarques là-dessus :
        
        l'auteur occupe la chaire de psychologie cognitive expérimentale ;
        
        le terme « hypothèse » revient à de nombreuses reprises, comme il se doit pour une science expérimentale.
        
        Kant et les kantiens ne pratiquent pas de science expérimentale mais de la science pure ou rationnelle, c'est-à-dire des sciences dont les principes fondamentaux ne sont pas fondés sur l'expérience et l'observation, et dans les sciences expérimentale ne considèrent que la forme nécessaire que doivent prendre leurs théories pour être adéquate à la structure de notre esprit. Tu noteras que je parles d'esprit et non de cerveau : le cerveau est aussi peu le siège de la pensée que le cœur est celui des émotions, si ce n'est par amalgame matérialiste. Dans un tel champ du savoir, le recours aux hypothèses est mal venu :
        
        Pour ce qui concerne la certitude, voici la loi que je me suis imposée à moi-même : dans cette sorte de considération, l'opinion n'est en aucune façon permise, et tout ce qui ressemble seulement à une hypothèse est une marchandise prohibée, qui ne doit pas être mise en vente à bas prix, mais doit être saisie aussitôt que découverte. Car toute connaissance qui doit être établie a priori donne d'elle même à entendre qu'elle veut être tenue pour nécessaire; plus encore en ira-t-il d'une détermination de toutes les connaissances pures a priori, qui doit être la mesure et par la même l'exemple de toute certitude apodictique (philosophique).
        
        Kant, Critique de la Raison Pure.
        
        Avoir recours à des hypothèse dans ce genre d'enquête, ce serait comme vouloir fonder la mathématique sur des conjectures : ce n'est pas sérieux.
        
        Maintenant, comme exemples de personnes ici du monde de la physique ayant écouté l'appel de Kant, je citerai :
        
        freejef et son laboratoire de Lille, d'après l'introdution de sa dépêche sur le recalage et la corrélation d'images ;
        
        Thibault Damour membre de l'académie des Sciences et spécialiste de relativité générale, d'après son texte sur la question Le temps passe-t-il ? (voir page 9)
        
        des épistémologues et physiciens d'après la conclusion du livre Petit voyage dans le monde des quanta d'Étienne Klein :
        
        Certes les problèmes de fond posés par Bohr, Heinsenberg, Einstein, Schrödinger ou Pauli restent d'actualité, mais on dispose aujourd'hui pour les traiter de davantage de résultats et de davantage d'arguments. Plusieurs systèmes épistémologiques essaient d'intégrer ces nouvelles donnes : la thèse du réel voilé de Bernard d'Espagnat, le solipsisme convivial d'Hervé Zwirn, le réalisme physique de Michel Paty, et de façon plus diffuse le réalisme ouvert, l'opérationnalisme, le phénoménalisme, et enfin l'idéalisme, lui-même divisé en idéalisme radical et idéalisme modéré, les deux pouvant être plus ou moins kantiens…
        
        E. Klein, Petit voyage dans le monde des quanta.
        
        J'ajouterai simplement qu'une telle situation n'a rien d'étonnant quand on connaît certaines résultats de la physique quantique et le contenu de la philosophie kantienne. Je conclurai sur la réponse d'un kantien à un extrait du livre d'Étienne Klein :
        
        En premier lieu, s'il est vrai que le vecteur d'état contient tout ce que l'on peu savoir d'un système quantique, autrement dit si le formalisme est complet, il faut admettre qu'un phénomène ne peut être interprété comme fournissant des informations concernant des propriétés qu'auraient les objets eux-mêmes, indépendamment de la connaissance que nous en avons. Songeons à une pierre. C'est un objet qui existe « pleinement » au sens où nous n'hésitons pas à lui attribuer par la pensée des propriétés bien définies : une taille, une forme, une couleur qui sont ce qu'elles sont, même en l'absence d'observateur. Les objets quantiques, eux, ne semblent pas pouvoir être considérés de la sorte puisque leurs propriétés ne sont pas toujours déterminées antérieurement à la mesure qui en est faite.
        
        Ce qui choque un Kantien n'est pas ce qu'il dit des objets quantiques, mais ce qu'il dit de la pierre ! :-P
        
        Les objets que nous observons, en tant qu'objets de la connaissance expérimentale, n'ont aucune existence propre indépendante de nous. Si nous voyons partout de l'espace et du temps dans l'expérience, c'est parce qu'on les y met nous-même (voir l'article de Thibault Damour). Ainsi, lorsque l'on fait abstraction de tout rapport à l'expérience possible alors l'espace et le temps s'évanouissent, ce qui nous apparaît comme une pierre dans l'expérience devient un quelque chose d'inconnu, qui nous restera à jamais inconnaissable, une chose ineffable (dont on ne peut parler). L'avantage du kantisme sur toute autre approche épistémologique est qu'il ne fait aucune distinction ontologique entre la pierre et les objets quantiques : ce ne sont que de simples phénomènes qui n'ont pas d'existence propre en dehors de leur rapport à un observateur.
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Thomas Douillard le 28 octobre 2017 à 14:51. Évalué à 2.
        
        ce ne sont que de simples phénomènes qui n'ont pas d'existence propre en dehors de leur rapport à un observateur.
        
        Le truc qui me choque à chaque fois que je croise ce genre de philosophie : et quand il y a 2 observateurs ? Et que par hasard ils sont d’accord, ce qui n’est pas systématique, mais assez commun. On peut donc arguer qu’ils tirent les mêmes conclusions sur l’objet en question, ce qui tend à montrer que ces phénomènes ont une existence propre. On ne cherche pas autre chose que nous rassurer sur la pertinence de nos observations en sciences en tentant de rendre les résultats reproductibles.
        
        ZF c'est l'archétype du typage dynamique
        Je suis intéressé par une explication là dessus. ZF est bien fondée dans le sens ou toute compréhension est associée à un ensemble préexistant https://fr.wikipedia.org/wiki/Sch%C3%A9ma_d%27axiomes_de_compr%C3%A9hension « Étant donné un ensemble A et une propriété P exprimée dans le langage de la théorie des ensembles, il affirme l'existence de l'ensemble B des éléments de A vérifiant la propriété P. » ce que j’interprète (librement) comme une relation de sous typage. Étant donné que le « x ∈ A » ressemble quand même pas mal à une assertion de type et qu’elle est nécessaire dans une théorie des ensemble, j’ai du mal à comprendre en quel sens ça correspond à un langage dynamique.
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par kantien le 30 octobre 2017 à 12:17. Évalué à 2. Dernière modification le 30 octobre 2017 à 12:21.
        
        Le truc qui me choque à chaque fois que je croise ce genre de philosophie : et quand il y a 2 observateurs ? Et que par hasard ils sont d’accord, ce qui n’est pas systématique, mais assez commun. On peut donc arguer qu’ils tirent les mêmes conclusions sur l’objet en question, ce qui tend à montrer que ces phénomènes ont une existence propre.
        
        Tu prends là une condition suffisante (l'existence propre de l'objet expliquerait l'accord des observateurs), pour une condition nécessaire (leur accord ne peut s'expliquer que par une existence propre de l'objet, abstraction faite du rapport à l'observateur).
        
        Premièrement, l'accord entre observateurs sur les determinations spatio-temporelles des objets est tout sauf commun : voir les principes fondamentaux des relativité restreinte et générale. Deuxièmement, dans la connaissance expérimentale on ne pose jamais de questions sur ce que sont les choses en elles-même, mais seulement sur les résultats de nos observations; et parler d'observation sans observateur (c'est-à-dire en faisant abstraction du rapport entre l'observateur et l'objet observé) est une contradiction dans les termes.
        
        Je pourrais développer ce point en faisant une analyse comparée d'un texte d'Enstein (un article qu'il a écrit sur Bertand Russel) et de la plaidoirie de Kant pour se défendre d'être un idéaliste (au sens que ce terme à en philosophie), si tu souhaites plus de précisions. La plaidoirie de Kant est, dans le fond, une réponse à l'objection que tu m'opposes.
        
        Je suis intéressé par une explication là dessus. ZF est bien fondée dans le sens ou toute compréhension est associée à un ensemble préexistant « Étant donné un ensemble A et une propriété P exprimée dans le langage de la théorie des ensembles, il affirme l'existence de l'ensemble B des éléments de A vérifiant la propriété P. » ce que j’interprète (librement) comme une relation de sous typage. Étant donné que le « x ∈ A » ressemble quand même pas mal à une assertion de type et qu’elle est nécessaire dans une théorie des ensemble, j’ai du mal à comprendre en quel sens ça correspond à un langage dynamique.
        
        Ton interprétation (libre) ne tombe pas loin de la réalité : telle était l'intention primordiale de la théorie, mais c'est « mal » fait. L'idée étant de voir un ensemble comme un concept dont l'extension (la totalité de ses éléments) dénote les objets tombant sous le concept (d'où, par exemple, l'axiome d'extensionnalité affirmant que deux ensembles ayant les mêmes éléments sont égaux), et l'inclusion entre ensembles exprimant alors la subordination entre concepts, c'est-à-dire du sous-typage.
        
        Ma comparaison avec le typage dynamique (comparaison à laquelle j'ajoutais si je peux m'exprimer ainsi) vient du fait que lorsque l'on prend un énoncé universellement quantifié de la théorie, on quantifie sur tout l'univers des ensembles qui se comporte alors à la manière du interface{} du Go. ;-) Raison pour laquelle les auteurs de HoTT écrivent en introduction de leur ouvrage :
        
        In type theory, unlike set theory, objects are classified using a primitive notion of type, similar to the data-types used in programming languages. […]
        This rigidly predictable behavior of all objects (as opposed to set theory’s more liberal formation principles, allowing inhomogeneous sets) is one aspect of type theory that has led to its extensive use in verifying the correctness of computer programs.
        
        Ce que j'ai graissé est à mettre en lien avec les reproches adressées à Go d'utiliser le interface{} pour la généricité du code, ce qui ne permet pas de garantir statiquement l'homogénéité d'une liste : il faut écrire des fonctions de constructions qui font du typage dynamique à base de switch sur les types des paramètres.
        
        Ceci est à mettre en parallèle avec les énoncés que l'on ferait sur l'encodage des entiers naturels dans ZF, où on écrirait $\forall x (x \in \omega \Rightarrow ...)$ pour énoncer une propriété des entiers. Ici le quantificateur universel sur x parcourt la collection de tous les ensembles (intreface{}) puis l'énoncé est une proposition hypothétique dont l'antécédent $x \in \omega$ correspond à une vérification dynamique de type avant de continuer « l'exécution » vers le conséquent. Je vois alors l'énoncé comme une fonction qui prend en entrée un interface{} et qui fait du typage dynamique : une assertion de type ou un switch (comme tu veux), comme en Go. En Coq ou en HoTT, on écrirait tout simplement forall (x : Nat) ..., soit pour tout entier, .... La notion de type capture bien mieux que celle d'ensembles (au sens de ZF) la notion logique de concept.
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Thomas Douillard le 30 octobre 2017 à 13:52. Évalué à 2.
        
        Tu prends là une condition suffisante (l'existence propre de l'objet expliquerait l'accord des observateurs), pour une condition nécessaire (leur accord ne peut s'expliquer que par une existence propre de l'objet, abstraction faite du rapport à l'observateur)
        
        Il n’y a pas grand chose de ni nécessaire, ni suffisant dans l’accord entre observateurs pour montrer grand chose. L’observation est faillible par essence, et deux observateurs peuvent faillir de la même manière. On ne peux que constater que la méthode scientifique finit par générer quelque chose qui ressemble à un accord. Ce qui en soit est considéré comme une quasi religion pour Eintein ;) Et ce en tentant aux maximum de s’affranchir de nos biais et illusions en multipliant les méthodes d’observation. Cela dit si tu ne postules pas ça, il ne peux y avoir de sciences.
        
        parler d'observation sans observateur (c'est-à-dire en faisant abstraction du rapport entre l'observateur et l'objet observé) est une contradiction dans les termes.
        
        Je comprends pas trop en quoi tu postules que je veux me débarrasser de l’observateur. Il me semble assez naturel aussi de postuler que nos théories ne sont pas la réalité. A partir de là on peut déduire que l’homme, en tant qu’être doué de raison, tente juste de déceler l’ordre dans le monde en vue de le prévoir. Il réussit, ou il échoue ;)
        
        Premièrement, l'accord entre observateurs sur les determinations spatio-temporelles des objets est tout sauf commun : voir les principes fondamentaux des relativité restreinte et générale.
        L’accord entre observateurs existe aussi en relativité générale, je trouve ça assez moyen comme contre exemple. Il est simplement plus compliqué à établir, car il faut utiliser les équations de changements de référentiels prévus par la théorie. Il passe par ce proxy pour éviter ce qui pourrait sembler absurde à l’observateur humain naïf plongé prêt d’un trou noir ou en voyage spatial.
        
        dans la connaissance expérimentale on ne pose jamais de questions sur ce que sont les choses en elles-même, mais seulement sur les résultats de nos observations;
        
        Bien sur que si, il est impossible de concevoir une expérience scientifique un tant soit peu élaborée sans se poser des questions sur la nature de l’objet observé. Il est par exemple impossible de mesurer un quelconque spin d’une particule sans avoir postulé qu’il devait exister une telle quantité, ou qu’elle représentai quelque chose. Alors évidemment ça ne veut pas dire qu’on a une réponse absolue sur la nature de la chose qu,on veut observer, mais on a au moins l’idée (ou l_’espoir) que faire une telle expérience a un sens. Nos théorie ont pour vocation de nous renseigner sur la nature des choses. Ça implique nécessairement la question de la théorisation, qui est une étape loin d’être triviale à partir des observations. La relativité générale permet de restaurer l’accord
        
        Je vois alors l'énoncé comme une fonction qui prend en entrée un interface{} et qui fait du typage dynamique : une assertion de type ou un switch (comme tu veux), comme en Go.
        
        Je comprend bien l’idée, mais l’analogie trouve ses limites vu que la logique du premier ordre n’est pas constructive. Si x n’appartient pas à Oméga, ben, rien, ça ne pose pas de problème. Donc « exécution » n’a pas trop de sens. Par contraste, en python, si tu passes un objet d’un mauvais type à une fonction, ben « boom ». Python se comportera pas bien du tout … Alors que dans une implication logique, un ensemble qui ne vérifie pas la prémisse ne sera jamais susceptible de fournir un contre exemple de l’implication.
        
        La notion de type capture bien mieux que celle d'ensembles (au sens de ZF) la notion logique de concept.
        Je te suis pas. C’est une notion logique la notion de concept ?
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par kantien le 31 octobre 2017 à 00:37. Évalué à 2.
        
        Cela dit si tu ne postules pas ça, il ne peux y avoir de sciences.
        
        Les kantiens n'ont jamais nié une telle chose.
        
        Je comprends pas trop en quoi tu postules que je veux me débarrasser de l’observateur.
        
        Bah, quand on me dit que la pierre a une existence propre spatio-temporellement déterminée, j'interprète cela comme abstraction faite de tout rapport à un observateur possible, c'est-à-dire que l'on se débarrasse de l'observateur. Autrement dit, qu'il y est ou non des hommes, il existe un monde dans lequel des pierres évoluent dans l'espace et le temps et la physique est là pour découvrir les lois d'un tel monde. Ce que disent les kantiens, ce n'est rien d'autre que ce que disait Socrate : nous ne voyons que des ombres sur un mur, tels les esclaves de l'allégorie de la caverne. Qu'il y est quelque chose qui nous apparaisse comme une pierre spatio-temporellement déterminée, que cette chose soit bien réelle, nous l'accordons; nous disons juste qu'elle n'est telle que pour les êtres humains.
        
        Je te répondrai plus en détail demain, mais j'ai l'impression que tu te méprends (comme Einstein lui-même d'ailleurs) sur ce que veulent dire les kantiens quand ils affirment que la pierre (ou tout autre objet physique) ne sont pas des choses en soi existant « sans nous ».
        
        Donc « exécution » n’a pas trop de sens. Par contraste, en python, si tu passes un objet d’un mauvais type à une fonction, ben « boom ». Python se comportera pas bien du tout …
        
        Disons que sans écrire un énoncé à quantificateur universelle borné (la condition $x \in \omega$ ), on risque la contradiction ou l'énoncé vide de sens. ;-)
        
        C’est une notion logique la notion de concept ?
        
        Un peu mon neveux ! La logique s'occupe des règles pour former des concepts, des règles pour former des jugements à partir de ces concepts et des règles pour enchaîner ces jugements entre eux ou raisonnements. Le plan de la doctrine générale des éléments du traité sur la logique de Kant :
        
        Des concepts
        
        Des jugements
        
        Des raisonnements
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Thomas Douillard le 31 octobre 2017 à 14:08. Évalué à 2.
        
        Sinon t’embêtes pas trop sur le Kantisme, j’ai parcouru les articles sur « noumène et phénomène » de la wp en anglais, qui sont instructifs et mettent bien en lumière les difficultés d’interprétation. , j’en conclu que tout tourne autour du thème « la réalité est-elle concevable », « peut-on concevoir l’inconcevable » (peut-on nommer l’innommable). Ça me semble un peu une tentative de formalisation du problème de la recherche scientifique. (est-ce qu’on peut trouver ce qu’on cherche pas?) Est-ce qu’on peux spécifier la totalité de la réalité ?
        
        Du coup, on peut se demander si ce n’est pas voué à l’échec. Toute formulation de ce problème est voué à s’enfermer dans son propre cadre théorique. D’une part, effectivement il est trivial qu’on a accès qu’à l’univers observable en l’état des connaissances actuelles. D’autre part, cette formalisation elle même, si on prend la réciproque de ta propre affirmation que tout ce qui est entendable ou logique peut s’exprimer en langage naturel, peut s’exprimer dans une logique.
        
        Et là, on tombe sur des considérations Godelienne :) dans quelle mesure peut-on affirmer que l’axiomatique induite par cette formalisation est cohérente, ou indépassable ? Si elle est cohérente, elle est incomplète, et donc dépassable ? Ça ne contredirait pas un peu la transcendance de cette vision des choses ?
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par kantien le 31 octobre 2017 à 10:56. Évalué à 2. Dernière modification le 31 octobre 2017 à 10:58.
        
        Je précise ici ma réponse sur ZF vu comme un langage dynamiquement typé. On pourra continuer la discussion de cette sous-question sous ce commentaire et laisser celle sur la physique à un autre fil.
        
        Je comprend bien l’idée, mais l’analogie trouve ses limites vu que la logique du premier ordre n’est pas constructive.
        
        Ici tu confonds deux choses : la logique du premier et la logique intuitionniste. La première concerne les règles de formation des jugements, la seconde traite des règles d'inférences ou raisonnements. J'ai déjà écrit ailleurs un commentaire, en réponse à une question de Michaël, sur la différence entre les deux notions, le rapport entre programmes et preuves de théorème (correspondance de Curry-Howard) et la distinction entre les systèmes de types de OCaml et de Coq.
        
        Si x n’appartient pas à Oméga, ben, rien, ça ne pose pas de problème.
        
        Si ça pose problème : dans un cas l'énoncé est prouvable dans ZF (c'est un théorème) dans l'autre il est réfutable, et cela selon les règles intuitionnistes (sans raisonnement par l'absurde). Exemples :
        
        Le premier se paraphrase en français ainsi : tout ordinal fini est soit vide, soit le successeur d'un ordinal fini. Le second se paraphrase ainsi : tout ensemble est soit vide, soit le successeur d'un autre. Tu remarqueras, au passage, que le français est tout à fait apte à exprimer de tels énoncés, sans recourir à un symbolisme quelconque. ;-)
        
        Le premier est trivialement vrai, le second est trivialement faux dans ZF. Le premier exprime le type de la fonction prédécesseur. En OCaml, on écrirait cela ainsi :
        
        type nat = | O : nat | S : nat -> nat let pred_nat n = match n with | O -> O | S m -> n val pred_nat : nat -> nat = <fun>
        
        En Coq, cela se formalise de manière assez similaire :
        
        Inductive Nat := | O : Nat | S : Nat -> Nat. Fixpoint pred x := match x with | O => O | S n => n end. (* j'y adjoins la preuve du théorème *) Theorem pred_spec : forall (n : Nat), n = O \/ exists (m : Nat), n = S m. Proof. intro n. destruct n. - left; reflexivity. - right; exists n; reflexivity. Qed.
        
        Ici la fonction pred est sous-spécifiée (elle a pour type Nat -> Nat), mais on pourrait lui donner un type plus précis analogue à ce qu'exprime le théorème, qui est la traduction en Coq du premier énoncé pour ZF. En revanche les contraintes de typage statique de l'un ou l'autre langage ne permettent pas d'exprimer le second énoncé. Contrairement à Python :
        
        >>> def pred(x): ... if type(x) == int : ... if x == 0: ... return 0 ... else: ... return x - 1 ... else: ... return "not an int" ... >>> pred(2) 1 >>> pred("a") 'not an int' >>> pred_unsafe = lambda x: x - 1 >>> pred_unsafe("a") Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<stdin>", line 1, in <lambda> TypeError: unsupported operand type(s) for -: 'str' and 'int'
        
        La fonction pred avec vérification dynamique de type s'apparente au premier énoncé, tandis que la seconde fonction pred_unsafe s'apparente au second.
        
        J'espère que la chose te semble plus claire maintenant. Il vaudrait mieux, du moins, car c'est une promenade de santé par rapport au problème du rapport entre le kantisme et ce qu'il entend par réalité. Ma réponse à ce sujet viendra plus tard, peut être ce midi ou en fin de journée si je trouve le temps qu'il faut pour la rédiger.
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Thomas Douillard le 31 octobre 2017 à 16:40. Évalué à 4.
        
        Ici tu confonds deux choses : la logique du premier et la logique intuitionniste. La première concerne les règles de formation des jugements, la seconde traite des règles d'inférences ou raisonnements.
        
        Mmm après réflexion je dirai plutôt que je fais une erreur stupide : je confonds implication et déduction. Par définition, une logique s’intéresse aux règles de constructions et à la formation des jugements … La non constructivité induit qu’il n’existe pas forcément de moyen de former un algorithme à partir du théorème ou de la formule, et c’est bien tout … Je crois que tu confonds « formule de la logique du premier ordre » et « logique du premier ordre ». Ou alors c’est moi qui confond … Parce que dans mon esprit, la logique du premier ordre est un système formel, donc comprend les règles de déduction : https://en.wikipedia.org/wiki/First-order_logic (et wp semble être d’accord avec moi) ou alors j’ai rien compris à ce que tu dis :) La logique intuitionniste est aussi un système de déduction, mais avec des règles de déduction différente. Ou alors tu voulais dire « la logique intuitionniste du premier ordre est l’archétype du typage dynamique » ?
        
        Du coup je me fourvoyai effectivement, tu parlais à chaque fois de système de déduction intuitionnistes. Tu établis 'une correspondance preuve/programme qui ne fonctionne que pour ces système, et je pensai que tu associais un système non intuitionniste pour les langages dynamiques. Alors que tu établies plus une distinction théorie à variable typée/théorie à variable pas typée.
        
        Cela dit j’ai quand même l’impression d’être grugé. Dans un cas, le connecteur « -> » est vu par correspondance de curry-howard comme le type d’une fonction, alors que dans l’autre pour un langage dynamique tu as complètement oublié cette correspondance implication/fonction et c’est le quantificateur qui joue ce rôle.
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par kantien le 02 novembre 2017 à 21:26. Évalué à 2.
        
        La non constructivité induit qu’il n’existe pas forcément de moyen de former un algorithme à partir du théorème ou de la formule, et c’est bien tout…
        
        La correspondance s'étend aussi au raisonnement par l'absurde et donc à la logique classique, ce sont les exceptions dans les langages de programmation (les blocs try-with-finally). Voir ce texte de Jean-Louis Krivine (page 3).
        
        Je crois que tu confonds « formule de la logique du premier ordre » et « logique du premier ordre ». Ou alors c’est moi qui confond…
        
        Ce n'est qu'une question de vocabulaire : il y a d'un côté les jugements que l'on considère (calcul des prédicats ou calcul propositionnel, au premier ou second ordre) et de l'autre les règles de déductions (classique ou intuitionniste). Comme dans une logique on considère à la fois les règles de formations des jugements et les règles de déduction, pour éviter toute ambiguïté, il serait sans doute préférable de parler de logique classique du premier ordre et de logique intuitionniste du premier ordre.
        
        Cela dit j’ai quand même l’impression d’être grugé. Dans un cas, le connecteur « -> » est vu par correspondance de curry-howard comme le type d’une fonction, alors que dans l’autre pour un langage dynamique tu as complètement oublié cette correspondance implication/fonction et c’est le quantificateur qui joue ce rôle.
        
        Le quantificateur universel c'est le $\lambda$ du lambda-calcul, le\ de Haskell, le fun de OCaml… c'est lui qui abstrait sur la totalité d'un domaine et, effectivement, dans le calcul des prédicats, on abstrait sur tout le domaine du modèle — sur tout l'univers des ensembles dans ZF. Les langages dynamiques sont des langages avec typage statique… qui n'ont qu'un seul type statique. Là où dans les théories des types, comme en Coq, on peut n'abstraire que sur les valeurs d'un type donné.
        
        L'implication est bien toujours le signe d'une fonction mais, dans mon exemple, elle ne spécifie rien sur sa sortie pour une entrée qui n'est pas un ordinal. Si on reprend mon énoncé (légèrement modifié) :
        
        il dit qu'à tout ensemble x, il peut en associer un autre y. Lorsque x est un ordinal, l'énoncé affirme que y est son prédécesseur qui est aussi un ordinal, mais dans le cas contraire (qui peut arriver, on a quantifié sur tous les ensembles), il ne dit rien sur y. La preuve d'un tel théorème expose, dans le cas où x est un ordinal, un moyen de produire un tel y et fournit la preuve que y est aussi un ordinal. En revanche, dans le cas où x n'est pas un ordinal, elle ne dit rien sur y (si ce n'est que c'est un ensemble, donc n'importe quelle valeur possible). Ce qui me fait penser à ce code Go :
        
        func pred(v interface{}) (uint, error) { var res uint var err error switch i := v.(type) { case uint: if i == 0 { res = uint(0) } else { res = uint(int(i) - 1) } default: err = errors.New("not an uint") } return res, err }
        
        Il prend en entrée toute valeur possible (n'importe quel ensemble pour ZF), dans le cas où c'est un uint renvoie un y selon la même spécification que l'énoncé, ou bien renvoie une erreur si l'entrée n'est pas de type uint (cas de la preuve qui ne dit rien sur y, on renvoie une erreur). Ici le procédé est totalement constructif au sens des règles de déductions intuitionnistes. Le fait que la preuve du théorème prouve aussi que y est un ordinal, quand x l'est, se retrouve sur le type de sortie de la fonction en Go.
        
        Après réflexion, on pourrait faire quelque chose de similaire en OCaml. Pour cela, il faut un type dans lequel on puisse plonger des valeurs de n'importe quel type : on parle de type universel. La signature d'un module fournissant un tel type est :
        
        module type Univ = sig type t val embed : unit -> ('a -> t) * (t -> 'a option) end
        
        Je passe les détails d'implémentations d'un tel module (il faut utiliser un type somme extensible, comme l'est celui des exceptions dans le langage) et montre juste son usage en supposant que l'on a module U : Univ, c'est à dire un module fournissant un tel type :
        
        (* ici on a des fonctions pour injecter dans et projeter * depuis le type `U.t` des valeurs de type `int` ou `nat` *) let (inj_int : int -> U.t), proj_int = U.embed() let (inj_nat : nat -> U.t), proj_nat = U.embed() (* on définit maintenant à partir de la fonction `pred` sur `nat` * une fonction `pred` générique sur le type universel `U.t` *) let pred_gen v = match proj_nat v with | None -> None | Some n -> Some (pred n) ;; val pred_gen : U.t -> nat option = <fun> (* si la valeur de type `U.t` contient un `int`, on renvoie `None` *) pred_gen (inj_int 2);; - : nat option = None (* si elle contient un `nat`, on renvoie son prédecesseur *) pred_gen (inj_nat (S (S O)));; - : nat option = Some (S O)
        
        Pour en revenir aux différentes logiques, le problème est bien dans le calcul des prédicats. Il est tel que, lorsqu'on l'interprète, toute les choses dont il parle sont considérées comme étant homogènes. Par exemple, si on veut formaliser la théorie des espaces vectoriels dans un tel symbolisme, il faut mettre les scalaires et les vecteurs dans un même sac fourre-tout et un modèle d'une telle théorie devra donner une signification à la somme d'un scalaire et d'un vecteur (ce qui, fondamentalement, n'a aucun sens dans un tel cadre). Raison pour laquelle je disais que les approches de la logique via la théorie des types captent bien mieux la notion de concept : le concept de scalaire ne sera nullement mélangé arbitrairement avec celui de vecteur, ce seront deux types distincts.
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Thomas Douillard le 27 octobre 2017 à 13:04. Évalué à 2.
        
        Sinon d’accord, j’aurai probablement du dire, la cohérence dans l’axiomatique du modèle sous-jacent. Que l’on peut considérer comme vraie d«s lorsque qu’il en existe un modèle (au sens de la théorie des modèle) qui tient mathématiquement la route. Ce qui ne devrait pas être bien sorcier pour une théorie des types ou pour une logique du premier ordre.
        
        Sinon il semble que la définition de la cohérence comme absence de contradiction soit aussi communément admise. https://fr.wikipedia.org/wiki/Coh%C3%A9rence_(logique)
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par kantien le 23 octobre 2017 à 16:28. Évalué à 2.
        
        Tu devrais tout de même jeter un œil à la vidéo de Xavier Leroy dont j'ai donné le lien au-dessus, il y parle pendant une vingtaine de minutes du milieu de l'avionique et de ses exigences de certification.
        
        C'est sûr, ce n'est pas comme si je n'avais pas déjà certifié 2 ou 3 logiciels.
        
        Je sais bien que tu n'ignores pas les exigences en question, mon conseil de visionnage était là pour te dire que Xavier Leroy non plus, que son projet s'inscrit dans cette démarche d'exigence (raison pour laquelle il aborde le secteur de l'aéronautique), et que tu pourras peut être comprendre en quoi ce logiciel est une avancée dans la recherche de sécurité par rapport aux méthodes antérieures — celles que tu connais déjà, justement.
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: Le cerveau n'est pas logique
        
        Posté par Nicolas Boulay (site web personnel) le 23 octobre 2017 à 17:52. Évalué à 4.
        
        Dans l'outil d'ET, il y a un prouveur qui marche assez bien (surtou avec les machines d'état). Je lui est déjà fait trouver des contres-exemples, mais personne ne l'achète ni ne s'en sert.
        
        "La première sécurité est la liberté"
- [^] # Re: Le cerveau n'est pas logique
  
  Posté par gasche le 18 octobre 2017 à 11:00. Évalué à 4.
  
  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.)
- [^] # Re: Le cerveau n'est pas logique
  
  Posté par Axioplase ıɥs∀ (site web personnel) le 20 octobre 2017 à 20:55. Évalué à 4.
  
  L'intérêt de la formalisation mathématique n'est pas forcément visible pour le programmeur. Ca peut être utilisé pour prouver qu'une nouvelle syntaxe sera transformée en du code qui se comporte bien. Toi, tout ce que tu fais, c'est utiliser la nouvelle syntaxe. T'as pas besoin de faire de maths ni de logique…
  
  Ca peut aussi être utilisé dans le compilateur pour prouver que ton code marche bien. Les systèmes de types, par exemple, font ça. T'as pas besoin de comprendre les types. Si ça passe pas le typage, c'est que t'avais un bug de toute façon et t'aurais été obligé de réfléchir…
# Commentaire supprimé

Posté par Anonyme le 17 octobre 2017 à 19:26. Évalué à -10.

Ce commentaire a été supprimé par l’équipe de modération.
# go 2.0

Posté par Nicolas Boulay (site web personnel) le 17 octobre 2017 à 22:10. Évalué à 3.

Je ne sais pas si vous avez une étude complète disponible pour des langages courants. Go est un train de lancé la réflexion sur go 2.0. Ils veulent surtout des problèmes concrets du langage, et la manière choisit pour les contourner.

J'imagine qu'il serait aussi preneur de votre vision de go 1.x.

"La première sécurité est la liberté"
- [^] # Re: go 2.0
  
  Posté par devnewton 🍺 (site web personnel) le 18 octobre 2017 à 09:20. Évalué à 6.
  
  votre vision de go 1.x
  
  L'absence de généricité est rédi, rhédi, raidibi… Heu bref c'est un no way.
  
  Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
  - [^] # Re: go 2.0
    
    Posté par Nicolas Boulay (site web personnel) le 18 octobre 2017 à 09:50. Évalué à 2.
    
    Le système d'interface règle un bon paquet de problème.
    
    "La première sécurité est la liberté"
    - [^] # Re: go 2.0
      
      Posté par devnewton 🍺 (site web personnel) le 18 octobre 2017 à 18:04. Évalué à 5.
      
      Mais pas tous loin de là. Donc pourquoi j'échangerais mon baril de C++/Java/Rust/… s'il manque un truc de base?
      
      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
      - [^] # Re: go 2.0
        
        Posté par Nicolas Boulay (site web personnel) le 19 octobre 2017 à 09:00. Évalué à 2.
        
        Bonne question : Vitesse de compilation, sécurité plus simple qu'en C++, un seul binaire : zéro runtime mammouth, faire un serveur web performant en 3 ligne, simplicité (beaucoup moins de blague que C++, ou de gestion mémoire que Rust), plus performant que Java.
        
        C'est sûr qu'il ne faut pas coder en go comme en java.
        
        "La première sécurité est la liberté"
        
        [^] # Re: go 2.0
        
        Posté par devnewton 🍺 (site web personnel) le 19 octobre 2017 à 09:02. Évalué à 7.
        
        plus performant que Java
        
        C'est démontré maintenant? Parce que j'avais retenu que le Go est lent.
        
        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
        
        [^] # Re: go 2.0
        
        Posté par Nicolas Boulay (site web personnel) le 19 octobre 2017 à 09:23. Évalué à 2.
        
        C'est démontré maintenant? Parce que j'avais retenu que le Go est lent.
        
        En fait, c'est compliqué :
        - go est un langage compilé, il n'a pas de warm-up time à la java et n'a pas de load d'une énorme jvm
        - go n'a pas de fonction virtuelle, ce qui peut avoir un cout en java dans les piles d'appel de library
        - le compilo go sait choisir entre allouer une variable ou la mettre dans la stack de la fonction, la pression sur la mémoire est moins forte (moins de boxing), et le Gc est largement au niveau de celui de java
        - le modèle concurrent de Go est limpide et facile, il monte très bien à l'échelle (pas besoin d'être un dieu pour utiliser 20 cpu)
        
        Donc, dans le cas général, d'un programme d'une taille raisonnable, go sera rapide, dans le cas d'un programme optimisé java sera plus rapide grâce au compilateur runtime.
        
        "La première sécurité est la liberté"
        
        [^] # Re: go 2.0
        
        Posté par anaseto le 19 octobre 2017 à 10:19. Évalué à 3.
        
        le Gc est largement au niveau de celui de java
        
        En fait, j'aurais dit que c'est justement là le point où Java gagne en performance : le Gc de Go est optimisé pour la latence, tandis que celui de Java pour les performances pures. Mais je suis pas un spécialiste…
        
        [^] # Re: go 2.0
        
        Posté par Nicolas Boulay (site web personnel) le 19 octobre 2017 à 10:26. Évalué à 2.
        
        le Gc de Go est optimisé pour la latence, tandis que celui de Java pour les performances pures.
        
        Oui mais si tu passes un tel GC sur 32 Go de RAM tu te retrouves avec des pauses de plusieurs secondes. C'est rarement acceptable.
        
        "La première sécurité est la liberté"
        
        [^] # Re: go 2.0
        
        Posté par djano le 02 décembre 2017 à 21:46. Évalué à 2.
        
        OpenJDK != Java.
        
        Certes OpenJDK est l'implémentation la plus utilisée (Oracle JDT c'est OpenJDK plus des petites choses en plus, et bientôt ce sera exactement la même chose). Cependant Azul Zing peut s'exécuter avec des centaines de gigaoctets de mémoire sans avoir des stop-the-world GC. Côté OpenJDK, Shenandoah existe déjà et ZGC arrive (https://www.infoq.com/news/2017/11/zgc).
        
        À côté de ça, Azul Zing propose aussi d'accélérer les démarrages des JVM en enregistrant les optimisations réalisées lors des runs précédents, ce qui permet d'éviter de brutales optimisations et deoptimisations. De son côté, OpenJDK propose la compilation AOT (Ahead Of Time) qui n'est rien d'autre qu'une compilation statique, pas au runtime avec un JIT. Bref, le monde Java bouge.
        
        [^] # Re: go 2.0
        
        Posté par claudex le 03 décembre 2017 à 16:32. Évalué à 3.
        
        Il y a aussi OpenJ9 qui est sorti récemment.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: go 2.0
        
        Posté par djano le 03 décembre 2017 à 23:55. Évalué à 2.
        
        Est-ce que tu as eu des échos sur ce que ça vaut? D'après un test phoronix, OpenJDK était systématiquement devant.
        
        [^] # Re: go 2.0
        
        Posté par claudex le 04 décembre 2017 à 11:10. Évalué à 3.
        
        Non, pas du tout, je ne fais pas de Java.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: go 2.0
        
        Posté par Kangs le 23 octobre 2017 à 21:08. Évalué à 1.
        
        En fait, j'aurais dit que c'est justement là le point où Java gagne en performance : le Gc de Go est optimisé pour la latence, tandis que celui de Java pour les performances pures. Mais je suis pas un spécialiste…
        
        Par curiosité, c'est quoi la différence entre 'optimisé pour la latence' et 'optimisé pour les performances pures' ?
        
        [^] # Re: go 2.0
        
        Posté par anaseto le 23 octobre 2017 à 21:40. Évalué à 6.
        
        Un Gc doit normalement faire une pause lorsqu'il fait le ménage : optimiser pour la latence signifie assurer que ces pauses sont courtes ; c'est utile si l'on a besoin d'une application qui soit en état de répondre à de nouvelles requêtes à chaque instant (je sais pas, par exemple un serveur qui doit gérer tout plein de requêtes et être réactif), ou qui ne gêle jamais (intéressant pour les jeux 3D, même si Go est pas vraiment utilisé pour ça actuellement).
        
        Cependant, parfois, réduire le temps des pauses peut entrer en conflit avec la performance en temps d'exécution total de l'application, au sens, au final l'application fera juste plus de petites pauses, le pourquoi du comment se trouvant dans le détail des algos, mais comme je suis pas spécialiste, je me risquerai pas à en dire plus :)
        
        [^] # Re: go 2.0
        
        Posté par Nicolas Boulay (site web personnel) le 24 octobre 2017 à 09:28. Évalué à 3.
        
        Par exemple, le GC de go 1.9 fait maintenant des pauses maximum de 9 ms et utilise des threads. Mais il prends un peu plus de temps cpu pour vérifier la totalité de la RAM. Cela veut dire que pour un serveur chargé qui marche bien actuellement, le nombre de transaction par seconde risque de baisser, même si la latence moyenne pour chaque requête baisse.
        
        "La première sécurité est la liberté"
        
        [^] # Re: go 2.0
        
        Posté par anaseto le 24 octobre 2017 à 10:27. Évalué à 2.
        
        J'ai jamais fait de test pour vérifier moi-même, mais pour go 1.8 ils annoncaient moins de 1ms, et souvent moins de 100μs pour les pauses, 10ms c'était pour go 1.5 (la première version à avoir un Gc concurrent, il me semble, même s'il faisait des stop the world pour le rescan encore). Ce qui est intéressant, c'est que le fil montre aussi que ça a des implications sur les performances totales (ils disent 2% de CPU au total en plus sur leur exemple à la fin, mais 20% en relatif, pas très bien compris par rapport à quoi).
        
        [^] # Re: go 2.0
        
        Posté par Nicolas Boulay (site web personnel) le 24 octobre 2017 à 13:37. Évalué à 3.
        
        J'imagine qu'au final, leur GC est 20% plus lent que l'ancien. Je ne retrouve l'article sur le gc 1.9.
        
        Ils en parlent un peu ici : https://golang.org/doc/go1.9
        
        "La première sécurité est la liberté"
  - [^] # Re: go 2.0
    
    Posté par Clément David (site web personnel) le 19 octobre 2017 à 21:18. Évalué à 1.
    
    Un moyen que je trouve pas inélégant est d'utiliser un générateur de code pour certains types comme genny. Tu as l'équivalent des templates sans la complexité associée et le code Go source compile de façon transparente avec go build (la génération est effectuée automatiquement).
    
    Tu peux même tester simplement que ton code générique est valide pour certains types facilement.
    - [^] # Re: go 2.0
      
      Posté par Nicolas Boulay (site web personnel) le 20 octobre 2017 à 09:46. Évalué à 3.
      
      Pas mal. C'est simple, un type remplacer par génération, et élégant avec le code générique qui compile de base.
      
      D'ailleurs, cela permet de voir la tonne de code généré si on s'amuse avec des modules génériques.
      
      "La première sécurité est la liberté"
- [^] # Re: go 2.0
  
  Posté par c^3 le 18 octobre 2017 à 09:26. Évalué à 9.
  
  Je pense que c'est assez clair que Go 1 ignore complètement les 40 dernières années de recherche en langages de programmation (à l'exception des primitives de concurrence qui ont inspirés ses goroutines). Pour tout le reste, l'absence de generics, de sum types, la présence de nil et de interface{} sont clairement aux antipodes de la plupart des systèmes à la pointe de la recherche (par exemple mezzo, ou même rust) qui sont plutôt du coté fonctionnel avec un typage expressif.
  
  The cake is a lie.
  - [^] # Re: go 2.0
    
    Posté par Nicolas Boulay (site web personnel) le 18 octobre 2017 à 09:58. Évalué à 2.
    
    Go est un langage simple qui permet d'être productif bien plus que les autres.
    
    Les generics peuvent aussi devenir anti-productif, et complexifie beaucoup les outils. Type sum, oui cela serait bien mais une méthode tagless final, avec transformation des package en module, cela serait peut être mieux. J'aimerais beaucoup des packages avec des paramètres.
    
    clairement aux antipodes de la plupart des systèmes à la pointe de la recherche (par exemple mezzo, ou même rust) qui sont plutôt du coté fonctionnel avec un typage expressif.
    
    Les langages à la pointe de la recherche sont loin d'être les langages de programmation de choix. Ce n'est pas Ocaml, haskell, prolog ou autre qui sont le plus utilisé. C'est les trucs bricolés comme javascript, php, voir java, c++ ou perl.
    Un programmeur moyen est incapable d'utiliser un type gadt complexe.
    
    "La première sécurité est la liberté"
  - [^] # Re: go 2.0
    
    Posté par anaseto le 18 octobre 2017 à 10:00. Évalué à 5.
    
    Je pense que ces choses font, au contraire, qu'avoir une sémantique formelle du langage serait probablement plus facile que pour d'autres langages avec plus de fonctionnalités, si on exclut la concurrence, justement.
    
    Et je trouve simplificateur le typique « ignore complètement les 40 dernières années de recherche » dont est souvent victime Go : il se trouve juste que c'est un langage qui avait des objectifs assez précis et qu'ils pèsent vraiment le coût de l'accessibilité et simplicité pour les problèmes courants au moment d'introduire quelque chose dans le langage, et puis ils font la balance avec le reste ; que les choix faits ne plaisent pas à la communauté prisant les systèmes de types complexes et expressifs, avec le choix par exemple plutôt de leurs interfaces implémentées implicitement, approche relativement peu commune parmi les langages, c'est autre chose, mais pas de l'ignorance : tout choix a un coût.
    
    Go attire les utilisateurs de langages dynamiques : accessible (typage simple), plus sûr (interface{} occasionnellement ça leur fait pas peur : dans un langage dynamique il n'y a que ça et c'est même pire, car Go au moins force à être explicite au moment de l'assertion de type), rapide (typage statique), builds rapides (permis par les choix au niveau langage), etc.
    
    Et je dis tout ça en tant que personne qui s'amuse souvent à faire du Coq aussi.
    - [^] # Re: go 2.0
      
      Posté par Nicolas Boulay (site web personnel) le 18 octobre 2017 à 10:04. Évalué à 3.
      
      En tout cas, si vous faites un papier sur le langage, signalez-le dans : https://github.com/golang/go/wiki/ExperienceReports
      
      "La première sécurité est la liberté"
    - [^] # Re: go 2.0
      
      Posté par gasche le 18 octobre 2017 à 10:41. Évalué à 9. Dernière modification le 18 octobre 2017 à 10:42.
      Et je trouve simplificateur le typique « ignore complètement les 40 dernières années de recherche » dont est souvent victime Go
      
      Non, c'est vrai. On peut faire des types sommes et du filtrage de motif en restant tout à fait dans le "budget complexité" de Go, regarde la façon (pas très compliquée) dont ils sont présentés dans OCaml ou Swift par exemple. Pour l'ajout des génériques, je pense que c'est un peu plus compliqué (avoir des génériques qui se mélangent bien à un style objet/interfaces où le sous-typage est omniprésent n'est pas évident), il faudrait peut-être changer certains choix de conception. Mais le fait de n'avoir pas vraiment essayé montre quand même un choix fort de faire un langage sans vraie capacité d'abstraction.
      
      C'est clair en voyant Go que c'est une version améliorée de C->Alef->Limbo qui ignore complètement ce qui s'est fait en recherche en langages dans les autres équipes que celles des gens qui ont fait Go (le résultat est quelque chose qui est très proche de Algol/Modula).
      
      Alors certes il ne serait pas trop difficile de faire une sémantique formelle pour Go, mais
      
      Pourquoi je me casserais les pieds à travailler pour des gens qui trouvent que le travail de ma communauté est inutile ?
      
      Pour qu'un langage profite d'un effort de formalisation, il faut que les concepteurs soient prêts à y participer, à éventuellement s'en inspirer pour changer des choses, et à rester en contact avec les gens qui font le modèle formel pour le faire évoluer en tandem avec le langage. Pour Go on n'a aucune assurance que ses auteurs seraient motivés pour jouer le jeu, et on a plutôt les signes qu'ils ne le seraient pas. (Au contraire des gens de Rust, qui ne se sont pas bougés le petit doigt pour une formalisation du langage pendant des années, mais qui ont au moins toujours été accueillants et positifs quand des académiques les contacts pour cela.)
      
      Pour (1), une réponse possible est "parce que le langage a beaucoup d'utilisateurs et que développer des outils peut donc leur rendre service". C'est une réponse raisonnable et je la respecte. Dans la communauté des langages, des compilateurs etc., il y a un peu deux modes de travail, (a) travailler sur les langages existants, même si c'est moche et injustement difficile, pour améliorer la vie des utilisateurs, et (b) concevoir de nouveaux langages meilleurs pour montrer la voie, même si on sait qu'ils seront peu utilisés et que le transfert principal se fera si des langages plus utilisés reprennent certains aspects. Une personne donnée peut travailler sur les deux aspects à la fois selon ses projets, travailler sur Go serait clairement le cas (a), personnellement j'ai plutôt tendance à m'inscrire dans l'approche (b)—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, mais après chacun son goût. Il y a des gens qui travaillent sur des outils pour Go (par exemple des vérifications de cohérence de protocoles concurrents, à base de canaux comme en Go plutôt qu'en acteurs comme Erlang, plus étudiés précédemment).
      
      Par ailleurs, indépendamment de Go, le langage, qui n'a aucun intérêt ou presque, il y a des choses intéressantes dans Go, en particulier l'idée que finalement on peut rendre un langage bof très agréable à utiliser si on met le paquet sur les outils. C'est hors du cadre discuté dans mon journal ci-dessus, et personellement je ne comprends pas encore très bien, scientifiquement, l'articulation entre un langage de programmation et les outils qui l'entourent. Je pense que c'est une questoin intéressant et que c'est en étudiant des cas d'usage, comme Go, qu'on peut commencer à cerner ces questions—ou au moins avoir des idées de bonnes idées à reprendre pour l'outillage de langages qui nous intéressent plus.
      
      (Le travail sur le runtime concurrent de Go est aussi relativement intéressant, je crois, mais ça ce n'est pas mon domaine.)
      - [^] # Re: go 2.0
        
        Posté par Nicolas Boulay (site web personnel) le 18 octobre 2017 à 11:03. Évalué à 3.
        
        C'est hors du cadre discuté dans mon journal ci-dessus, et personellement je ne comprends pas encore très bien, scientifiquement, l'articulation entre un langage de programmation et les outils qui l'entourent.
        
        Il faut voir cela comme une tache à accomplir avec une quantité non négligeable de code déjà existante. Plus le cycle "mise en avant du problème - correction - test", est rapide plus les développeurs sont contents. Cela peut venir d'outils de check statique ou de vitesse d’exécution (compilation rapide, déploiement simple, lancement de teste en une seul ligne de commande standardisé, possibilité d'instrumentation, etc…)
        
        "La première sécurité est la liberté"
      - [^] # Re: go 2.0
        
        Posté par Dr BG le 18 octobre 2017 à 11:07. Évalué à 4.
        
        Par ailleurs, indépendamment de Go, le langage, qui n'a aucun intérêt ou presque, il y a des choses intéressantes dans Go, en particulier l'idée que finalement on peut rendre un langage bof très agréable à utiliser si on met le paquet sur les outils. C'est hors du cadre discuté dans mon journal ci-dessus
        
        C'est exactement la réflexion que je me faisais, mais je m'abstenais de commenter car ce n'est pas exactement le sujet de ton journal.
        
        J'ai beaucoup d'affection pour les langages comme OCaml, mais je ne l'utilise que très (très) peu car le manque d'outil est frustrant par rapport à un langage comme Java.
      - [^] # Re: go 2.0
        
        Posté par anaseto le 18 octobre 2017 à 13:54. Évalué à 4.
        
        Non, c'est vrai. On peut faire des types sommes et du filtrage de motif en restant tout à fait dans le "budget complexité" de Go, regarde la façon (pas très compliquée) dont ils sont présentés dans OCaml ou Swift par exemple.
        
        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). Mais que juste ceci donne droit aux « 40 années de recherche ignorées » me semble légèrement injuste et traduire une réaction à une difficulté à appréhender qu'est-ce qui attire d'autres personnes vers un langage auquel on ne trouve soi-même rien d'intéressant, et de se rassurer intuitivement en pensant que c'est dû uniquement aux outils.
        
        travailler sur Go serait clairement le cas (a), personnellement j'ai plutôt tendance à m'inscrire dans l'approche (b)
        
        Ça c'est quelque chose que je comprends parfaitement, j'ai tendance à penser pareil : autant poursuivre ses idéaux, peut-être que d'autres s'en inspireront après, plutôt que de faire face à des obstacles qu'on pense vraiment évitables.
        
        Par ailleurs, indépendamment de Go, le langage, qui n'a aucun intérêt ou presque, il y a des choses intéressantes dans Go, en particulier l'idée que finalement on peut rendre un langage bof très agréable à utiliser si on met le paquet sur les outils. C'est hors du cadre discuté dans mon journal ci-dessus, et personellement je ne comprends pas encore très bien, scientifiquement, l'articulation entre un langage de programmation et les outils qui l'entourent.
        
        Eh bien en pratique il me semble que c'est quand même un lien à ne pas négliger, même si scientifiquement on n'arrive pas à le définir facilement. Et, autant d'un point de vue théorique il n'y a rien ou presque d'innovant dans Go, d'un point de vue humain, les choix faits sont intéressants à mon avis : 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.
        
        [^] # Re: go 2.0
        
        Posté par Nicolas Boulay (site web personnel) le 18 octobre 2017 à 14:30. Évalué à 4.
        
        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.
        
        Cela me rappelle ocaml qui est léger graphiquement en virant les "," et les "()" avec des mots clef simple comme "let" et "let in", et puis ils ont rajouté un tas de machin comme ".+", le truc le pire étant camlp4 et les notations à base de "<>" et autre "%". qui ressemble à du "modem line noise".
        
        Un des trucs que j'aimais bien dans Lisaac, c'était sa syntaxe à mot clef. C'est à dire que l'on pouvait écrire des fonctions "à trou" genre func CreateUnObjet (string name) with (string comment). Dans les fonctions à grand nombre de paramètres, c'est plus lisible et moins lourd que les langages utilisant le nom du paramètres (ada, vhdl).
        
        Un des trucs pourris mais finalement génial de ocaml, c'était l'absence d'espace de nom pour les type sum. Je pense que c'est génial, car il n'y a jamais aucune ambiguïté sur le mauvais usage d'un type. En cas d'usage de name space, celui-ci est souvent sous-entendu ce qui peut poser des problèmes pour retrouver le bon.
        
        "La première sécurité est la liberté"
        
        [^] # Re: go 2.0
        
        Posté par Moonz le 18 octobre 2017 à 15:39. Évalué à 3.
        
        Un des trucs que j'aimais bien dans Lisaac, c'était sa syntaxe à mot clef. C'est à dire que l'on pouvait écrire des fonctions "à trou" genre func CreateUnObjet (string name) with (string comment).
        
        Comme en Objective-C ?
        
        [^] # Re: go 2.0
        
        Posté par gasche le 18 octobre 2017 à 15:21. Évalué à 6.
        
        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.
        
        [^] # Re: go 2.0
        
        Posté par Renault (site web personnel) le 18 octobre 2017 à 15:40. Évalué à 3.
        
        Personnellement, je trouve que l'ensemble de ton discours sur C et Go montre une certaine forme de condescendance assez violente de ta part (voire de ton milieu) envers ces langages.
        
        Non pas que ces langages ne présentent pas de défauts, loin de là, mais tu sembles tellement obnubilé sur l'aspect théorique que tu perds toute vision des autres critères pourtant essentiels dans le milieu. Un peu comme certains mathématiciens qui hurlent devant des documents de physiques sur des points qui n'ont finalement pas d'impacts sur la valeur du document et qui sert plus de prétexte à critiquer qu'à vraiment faire avancer le sujet.
        
        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.
        
        Appeler le C de faute professionnelle, c'est un peu fort quand même. Dans ce cas je dirais que tout le monde devrait être au chômage.
        
        Non pas que le C est parfait, je connais ses défauts, mais je connais aussi ses avantages (avantages essentiels pour l'époque) : tu aurais pu écrire UNIX en 1970 avec ML ou un langage similaire, dans les conditions qu'il a été écrit, pour les machines cibles ? J'en doute très certainement.
        
        Tu sembles aussi induire que Ritchie et Thompson sont de sombres incompétents, étant donné leurs parcours, leurs apports et le milieu dans lequel ils ont évolué, j'émets un doute sur cet avis. Apparemment, comme d'autres, ils ont choisi une voie moins élégante théoriquement mais qui permettait de résoudre des problèmes concrets de leur époque.
        
        Cela me fait penser un peu au discours Tanambaum contre Torvalds sur le noyau monolithique contre micro-noyau. Théoriquement le micro-noyau explose tout, mais voilà il y a les contraintes de la vraie vie aussi et 25 ans après on attend toujours le micro-noyau qui montrera que c'était la seule voie à suivre. Ni Apple, ni Microsoft n'ont trouvé le 100% noyau assez séduisant pour l'utiliser massivement, préférant une approche hybride. Et Minix, malgré sa licence libre, peine à convaincre face à Linux dans la plupart des domaines.
        
        Bref, je pense que tu devrais un peu plus t'informer sur les circonstances du choix de conception de certains produits, de constater que la méthode élégante n'était pas à ce moment là pertinente. Ce n'est pas parce que des gens ont choisi une autre voie qu'ils sont incompétents, cela peut être une explication, mais il y en a d'autres.
        
        [^] # Re: go 2.0
        
        Posté par Dr BG le 18 octobre 2017 à 15:47. Évalué à 10.
        
        Appeler le C de faute professionnelle, c'est un peu fort quand même. Dans ce cas je dirais que tout le monde devrait être au chômage.
        
        Tu devrais peut-être relire son commentaire, car il ne dit pas ça.
        
        [^] # Re: go 2.0
        
        Posté par gasche le 18 octobre 2017 à 16:02. Évalué à 10. Dernière modification le 18 octobre 2017 à 16:03.
        
        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.
        
        [^] # Re: go 2.0
        
        Posté par Renault (site web personnel) le 18 octobre 2017 à 16:22. Évalué à 2.
        
        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.
        
        Bah non, je conteste encore, ce serait comme dire que pondre un noyau monolithique serait aussi une faute professionnelle.
        
        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 (qui est un domaine particulier, rarement considéré par la recherche informatique qui semble se concentrer sur des applications plus lourdes / critiques).
        
        Le Go doit donc avoir cette simplicité (de conception) du C, reprendre l'essentiel de sa syntaxe (un développeur C n'est pas choqué par la syntaxe du Go) tout en apportant la possibilité de faire des trucs utiles simplement (comme la programmation parallèle). Le cahier des charges est rempli, il fait son boulot.
        
        Le fait qu'il ne soit pas à l'état de l'art du domaine n'est pas le sujet. En réalité, tout le monde s'en moque de suivre l'état de l'art, ce n'est pas le critère. La question est toujours "est-ce que l'état de l'art m'apporte quelque chose pour répondre à mon cahier des charges ?" Parfois oui, parfois non, j'ai l'impression que pour le Go (de ce que j'en ai lu), c'est plutôt voulu et assumé de faire autrement, car l'état de l'art ne l'aidait pas pour ce qu'ils voulaient faire.
        
        Dire que les gens commettent des fautes, je ne trouve pas que ce soit méprisant.
        
        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 ? Envers ceux qui ont développé et qui utilisent ce langage pour diverses raisons.
        
        J'ai aussi appuyé le commentaire de c3 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.
        
        Bah si, car tu sembles prioriser dans les critères le fait que les concepteurs doivent écouter et suivre les chercheurs systématiquement. Tu fais un jugement de valeur et cela se transcrit tout le long de ta prose ce qui ressemble à une grosse condescendance envers ceux qui n'ont pas les mêmes critères, objectifs que toi et qui du coup ne suivent pas forcément la même voie.
        
        Si tu respectais ces choix, tu n'en ferais pas des pavés pour dire qu'ils sont dans l'erreur et que tu es dans le vrai. Tu le mentionnerais rapidement et tu passerais à autre chose.
        
        [^] # Re: go 2.0
        
        Posté par gasche le 18 octobre 2017 à 16:48. Évalué à 6.
        
        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 ?)
        
        [^] # Re: go 2.0
        
        Posté par Renault (site web personnel) le 18 octobre 2017 à 17:02. Évalué à 4.
        
        Tu t'inventes ta propre histoire de Go.
        
        Pas vraiment. Cette page ne contre indique pas ce que j'énonce.
        En 2007, nombre des domaines qu'ils listent sont trustés par le C, pour des raisons souvent historiques mais aussi parce qu'il est fortement lié à UNIX ce qui le rendait très apprécié pour la programmation système. Et le C a influé grandement le C++, Java et Python même si peu à peu, certains s'en éloignent aujourd'hui.
        
        Bref, ils ne le citent pas directement dans cet article, mais ça reste une caractéristique importante de Go. Le fait que Pike et Thompson, qui ont fait du C (ou du Limbo, que tu parlais précédemment) pratiquement toute leur vie, ont contribué à Go dès les débuts n'est pas je pense étranger à cela.
        
        L'Histoire ne se résume pas à une FAQ d'un site Web (qui peut aussi subir des effets du genre storytelling pour mieux promouvoir le produit maison), c'est aussi un contexte historique, des personnages avec une expérience, un passé…
        
        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".
        
        Mais est-ce un vrai manque ? Les lambda-calculs, ce n'est pas nouveau non plus, beaucoup de langages n'en ont pas. Est-ce grave ? Est-ce que ce que tu énonces était essentiel pour répondre à leur problématique ? J'ai l'impression que non.
        
        Tu as une vision très théorique de la situation. D'autres plus empiriques, ils ne prennent que ce qui est nécessaire ou conforme à ce qui est voulu. Tu disais que les concepteurs de langages devaient écouter les théoriciens, je n'ai rien contre cela, mais l'inverse est vrai aussi, les chercheurs doivent écouter et comprendre ceux qui programment dans l'ensemble des contextes industriels existants.
        
        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 ?)
        
        Il y a une histoire de contexte. 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.
        
        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 ?
        
        [^] # Re: go 2.0
        
        Posté par gasche le 18 octobre 2017 à 17:23. Évalué à 4.
        
        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 ?
        
        [^] # Re: go 2.0
        
        Posté par gasche le 18 octobre 2017 à 17:30. Évalué à 6. Dernière modification le 18 octobre 2017 à 17:30.
        
        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.)
        
        [^] # Re: go 2.0
        
        Posté par gasche le 18 octobre 2017 à 22:08. Évalué à 3.
        
        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.
        
        [^] # Re: go 2.0
        
        Posté par anaseto le 19 octobre 2017 à 08:56. Évalué à 4.
        
        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.
        
        À mon avis (ou alors c'est une coïncidence) ils ont aussi regardé du côté des langages dynamiques et ont copié le côté intégrer de façon ad hoc dans le langage les tableaux dynamiques et les tables de hachages, ce qui je pense rend le langage beaucoup plus accessible aux gens venant de ces langages.
        
        Dans le même genre d'idées, ils ont mis des choses dans le langage comme la réflection qui, bien qu'imparfaits, sont en même temps une solution simple (d'un point de vue théorique) à des choses comme la sérialisation qui me semblent être des points délicats et demandant un traitement particulier dans les langages avec système de types plus évolués que j'ai utilisés (Haskell et OCaml), même s'il y a du progrès.
        
        Les interfaces Go (qui sont le point central à la réflection en Go) sont un mécanisme simple qui permet de faire beaucoup, même si pas autant que d'autres systèmes. En pratique, l'avantage c'est que les gens les utilisent (contrairement au type class Haskell, qui sont pas pour les débutants, ou les modules et foncteurs en OCaml, ou certains systèmes objets plus compliqués). Et on retrouve ça partout dans la librairie standard: il suffit d'implémenter String() pour un type et on peut utiliser toutes les fonctions de formattage sytle printf après, et c'est seulement un exemple (la gestion de différent types de buffers et entrées sorties utilisant une même interface commune est aussi très agréable).
        
        Leur sémantique de package, ainsi que la possibilité de répartir dans plusieurs fichiers les éléments d'un même module, est aussi plutôt bien trouvée, même si c'est un point à la limite du langage.
        
        Bref, Go doit au minimum un certain nombre de traits aux langages dynamiques actuels (par accident ou non), ce qui le rend très différent de C. J'ai un peu l'impression de passer ce journal à défendre ce langage, mais il me semble qu'il y a des jugements un peu trop rapides à son sujet :)
        
        [^] # Re: go 2.0
        
        Posté par gasche le 19 octobre 2017 à 11:55. Évalué à 4.
        
        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.
        
        [^] # Re: go 2.0
        
        Posté par anaseto le 19 octobre 2017 à 14:42. Évalué à 2.
        
        Les cas simples avec les type-class sont ok, c'est sans doute plus une question de savoir les présenter (donc pas propre au langage) : parmi les première que décrivent pas mal de tutos, c'est celle des monades ; et, il me semble (mais ça fait plusieurs années que je fais pas de Haskell), que pour des choses concrètes équivalentes au Writer et Reader de Go, il faut aller chercher dans les packages. Après, le fait qu'il soit possible de faire des classes sur des types plus complexes et des concepts plus avancés n'est pas intéressant pour un langage comme Go : un principe du langage c'est qu'au bout d'une semaine tu peux lire le code de n'importe qui sans barrière de compétence sur le langage. Du coup, au mieux, ils auraient pu viser un sous-ensemble de la solution à base de type-class ; est-ce qu'en pratique le résultat aurait changé beaucoup par rapport aux interfaces ?
        
        [^] # Re: go 2.0
        
        Posté par gasche le 19 octobre 2017 à 15:11. Évalué à 3.
        
        Je n'essaie pas de dire que les interfaces devraient être remplacées par les classes de types, ce sont deux fonctionnalités très différentes (même si elles sont utilisées en partie pour répondre au même besoin).
        
        Puisque tu es intéressé par le fait de discuter des interfaces, poussons un peu la discussion. Go utilise les interfaces de plein de façon différentes :
        
        pour présenter une interface commune à plein de types différents ayant des opérations en commun, en partant du principe qu'il n'y a qu'une seule interface possible pour chaque type; c'est la façon dont marche la généricité sur Writer/Reader par exemple
        
        comme un mécanisme de sealed classes (en Scala) du pauvre où on imite les types sommes en donnant une interface commune à un ensemble de types (un pattern assez proche des "empty bases classes" de C++), et on repose sur le dispatch dynamique sur le sous-type (appelé "type switches" en Go)
        
        interface{} comme un type existentiel fourre-tout suivi par des upcasts quand nécessaire; c'est la programmation générique du pauvre, comme avec Object en Java.
        
        À mon avis les interfaces sont une approche raisonnable pour (1), à comparer par exemple aux "traits" de Rust. (Les type-classes sont beaucoup plus expressives (elles n'imposent pas d'être toujours attachées à une valeur), mais demandent de savoir coder un moteur d'inférence de type plus riche). Je pense que (2) serait, dans la plupart des cas, mieux fait avec des vraies sommes, et que (3) est toujours autant une aberration que quand c'était fait en Java avec Object.
        
        [^] # Re: go 2.0
        
        Posté par anaseto le 19 octobre 2017 à 15:29. Évalué à 2.
        
        (3) est toujours autant une aberration que quand c'était fait en Java avec Object.
        
        C'est pas rassurant, mais « aberration »… C'est ce qui est fait pour absolument tous les objets dans les langages dynamiques. Là tu le fais juste très rarement, tu es obligé d'écrire explicitement ton assertion de type dans le code, et dispose de la possibilité de faire un wrapper sûr autour : verbeux, je te l'accorde. Je t'accorde aussi que le risque existe que les programmeurs abusent de ceci et fassent du code aberrant, pour reprendre ton terme.
        
        [^] # Re: go 2.0
        
        Posté par gasche le 19 octobre 2017 à 15:38. Évalué à 2.
        
        Disons que si on décide d'utiliser un langage au typage statique, c'est aussi pour bénéficier d'une certaine sûreté apportée par le fait que le typeur vérifie qu'on fait les choses à peu près correctement. C'est un peu dommage de se retrouver complètement abandonné, et de devoir se reposer sur le fait de suivre un pattern sans faute d'inattention (et de payer le coût de la maintenance supplémentaire, par exemple quand on change d'avis sur le type dynamique qu'on veut transporter), dès qu'on veut définir une structure de donnée un peu générique (donc suivre des bons principes de programmation).
        
        Mais je pense que tu sais tout ça et qu'on est d'accord.
        
        [^] # Re: go 2.0
        
        Posté par anaseto le 19 octobre 2017 à 15:56. Évalué à 3. Dernière modification le 19 octobre 2017 à 15:57.
        
        Oui, oui, on est d'accord, c'est juste qu'entre langage au typage statique et langage dynamique il y a tout un gradient, tout comme il y a un gradient dans l'aberration :)
        
        [^] # Re: go 2.0
        
        Posté par gasche le 19 octobre 2017 à 16:08. Évalué à 2.
        
        Mouais. Les langages dynamiques les plus intéressants sont ceux qui profitent de l'absence des ceintures-bretelles pour faire des choses vraiment marrantes, tant qu'à faire. Le live development à la CLisp où tu redéfinis tes fonctions une par une dans le terminal en expérimentant, voire à la Smalltalk où tu arrêtes le programme au milieu, c'est assez fun. (Et recharger du code à chaud c'est très utile en Erlang.) Générer des classes/types dynamiquement ou faire du monkey patching (Python, Ruby), moi ça ne m'a jamais séduit mais c'est une audace. Implémenter des constructions de folies qu'on n'a pas su bien typer pendant longtemps (les continuations délimitées, le multistage programming). Utiliser l'introspection pour se brancher directement sur des données et les transformer comme si c'était des types natifs du langage. Tout ça.
        
        Je veux bien dire que le typage dynamique c'est quand le type utilisé ne sert à rien, mais je ne voudrais pas dire que les langages dynamiques se résument à ça.
        
        [^] # Re: go 2.0
        
        Posté par gipoisson le 19 octobre 2017 à 18:26. Évalué à 1.
        
        […] il me semble (mais ça fait plusieurs années que je fais pas de Haskell), que pour des choses concrètes équivalentes au Writer et Reader de Go, il faut aller chercher dans les packages.
        
        Vu tout le fil, le point que je relève est un détail, allons-y tout de même si ça ne te pose pas de souci. Alors, si Reader / Writer dans ton propos évoque la page liée — ici, mon illettrisme en Go devrait être totalement visible — je dirais qu'en Haskell ce genre d'abstractions est fourni dans les paquets venant avec GHC, le compilateur de facto du langage. J'ai nommé MonadIO, dans le paquet transformers donc. Cela vient avec l'avantage que les effets abstraits ne se limitent pas à des entrées/sorties, mais sont potentiellement composables avec toute autre monade. Bref, de base GHC n'est pas si dépourvu que ça.
        
        [^] # Re: go 2.0
        
        Posté par anaseto le 20 octobre 2017 à 09:16. Évalué à 3.
        
        Je pense que le paquet transformers est ce à quoi je pensais, même si j'ai pas mal oublié, donc un peu oublié si c'était inclus avec GHC (mais c'est un paquet à part, c'est pas dans base, je dirais). Après, je viens de regarder la doc, pour vérifier, et après plusieurs années sans faire de Haskell, je t'assure que tu mets un moment à te dire, ah oui, ça y est je comprends, parce que Reader et Writer sont carrément dans des modules différents (deux pour Writer, versions strictes et lazy) au milieu d'un tas d'autres, avec zéro exemples pour Reader et Writer, donc le nombre de fonctions plus de détails techniques liés au monades et compagnie accompagné de zéro exemples est déroutant pour moi ; imagine pour un débutant après quelques jours… J'aurais osé espérer qu'après plusieurs années ce genre de choses (en particulier la doc) s'améliorerait, là j'ai un peu peur :)
        
        [^] # Re: go 2.0
        
        Posté par gasche le 20 octobre 2017 à 09:42. Évalué à 4. Dernière modification le 20 octobre 2017 à 09:43.
        
        Mais les problèmes que tu pointes là sont du ressort de la conception de la bibliothèque standard (le choix d'avoir mis en avant la plus concrète (et donc plus simple) ou plus abstraite (et donc plus générique)) et des choix de documentation, pas de la définition du langage lui-même (on ne parle pas de changer les mots-clés, le typage, etc.) : on pourrait tout à fait avoir des classes de type correspondant aux interfaces Reader et Writer de la bibliothèque standard Go, et ce serait aussi simple à utiliser.
        
        (Il y a une différence entre les deux usages, qui est qu'en Haskell (ou avec les implicites en Scala) il faut déclarer explicitement "le type truc est une instance de Reader avec telles méthodes", alors qu'en Go c'est automatique à partir du moment où une fonction du nom recherché existe. Je ne pense pas que l'un soit plus simple que l'autre pour un débutant. Par contre ça a un impact important sur la flexibilité du mécanisme, son ergonomie à l'usage et sa modularité—il y a des avantages et des inconvénients à chaque approche. On peut détailler un peu si ça intéresse des gens, mais ça concerne des usages plus avancés qui ne sont pas visibles pour le cas simple "classe standard pour la sérialisation".)
        
        [^] # Re: go 2.0
        
        Posté par anaseto le 20 octobre 2017 à 10:09. Évalué à 2.
        
        Ah, oui, là, tout à fait, ce n'est pas quelque chose d'intrinsèque au langage, c'était plus une remarque que, visiblement, quand un langage est très expressif, la tentation de faire complexe semble grande et qu'il faudrait, je sais pas, tout un mouvement communautaire avec une vision bien définie pour proposer des approches alternatives moins puissantes et plus accessibles. L'approche Haskell c'est plutôt de faire des tutos de vulgarisation, mais à mon avis, bien qu'utile, c'est pas suffisant : c'est les bibliothèques elles-mêmes qu'il faudrait vulgariser sans honte (après, en Haskell, des choses comme monade IO vs ST, ou Strict vs Lazy, je sais pas comment les éviter).
        
        Par contre ça a un impact important sur la flexibilité du mécanisme, son ergonomie à l'usage et sa modularité
        
        C'est un point intéressant, oui, mais tu as raison, la différence n'est pas très visible ni importante au premier abord.
        
        [^] # Re: go 2.0
        
        Posté par Nicolas Boulay (site web personnel) le 20 octobre 2017 à 09:48. Évalué à 4.
        
        Le temps de re-rentrer dans du code perdu de vue depuis longtemps est un très bon moyen d'évaluer l'ergonomie d'un langage, je trouve :)
        
        "La première sécurité est la liberté"
        
        [^] # Re: go 2.0
        
        Posté par gipoisson le 20 octobre 2017 à 15:59. Évalué à 1.
        
        Sur le fond, la réponse de gasche ci-dessus est suffisante : quand on documente une bibliothèque, on est obligé à faire des choix entre rester au niveau le plus général ou spécialiser (arbitrairement) la documentation.
        
        Je trouve que, pour une bibliothèque livrée avec le compilateur, spécialiser un concept général n'est pas optimal : on pourrait bien mettre du texte dans MonadIO expliquant comment dériver la classe pour créer des fonctions lisant/écrivant des fichiers sur le disque, mais quid des gens qui viendront lire la doc en ayant besoin de travailler plutôt avec des bases de données ? Serait-ce une adéquate utilisation de leur temps en les promenant sur des paragraphes ne traitant pas de leurs besoins ? La voie des tutoriels, conférences, et autres postes de blogs me paraît être la bonne dans ce cas.
        
        Par contre, quand les usages d'une bibliothèque sont presque totalement connus, illustrer la doc est tout à fait adéquat. Dans le cas des bibliothèques maintenues par GHC-HQ, on ne se prive pas de le faire.
        
        Ceci dit, il y a des contre-exemples de bibliothèques implémentant des concepts généralistes mais dont la doc est bourrée d'exemples pour quelques restrictions d'applications ; voir par exemple la fameuse lens.
        
        Et n'oublions pas que c'est du logiciel libre : je ne doute pas que tu as les compétences nécessaires pour rédiger un patch de la documentation que tu as potassée ; pourquoi ne pas contribuer ? Et ça tombe bien, l'outillage est en train d'être ripoliné pour faciliter les contributions.
        
        P.S. Pour maximiser le sous-hors-sujet Haskell dans un déjà hors-sujet Go, à propos des opérateurs qui seraient horribles comme tu l'écrivais ailleurs dans les commentaires: je trouve qu'utiliser une bibliothèque en explicitant tous les éléments qu'on en importe aide énormément à rendre le code intelligible même après des années d'abandon. Ceci vaut aussi pour Prelude. Concrètement :
        
        Première itération d'écriture du code : mettre des import Foo dans l'en-tête, import Prelude comprise.
        
        Deuxième itération: dire au compilateur de nous indiquer ce qu'on a utilisé, ghc -ddump-to-file -ddump-minimal-imports
        
        Enfin, remplacer les imports manuels par ceux automatisés. Comme ça, des mois plus tard, quand on rencontrera un opérateur ésotérique, il suffira de voir où il se trouve dans l'en-tête et suivre la documentation du module correspondant.
        
        [^] # Re: go 2.0
        
        Posté par anaseto le 20 octobre 2017 à 19:16. Évalué à 2.
        
        La voie des tutoriels, conférences, et autres postes de blogs me paraît être la bonne dans ce cas.
        
        Je sais bien que c'est celle qui est souvent choisie en Haskell, et c'est peut-être juste une question d'habitude et un lien au point d'entrée de la doc de référence vers un de ces tutoriels ferait l'affaire.
        
        Ceci dit, il y a des contre-exemples de bibliothèques implémentant des concepts généralistes mais dont la doc est bourrée d'exemples pour quelques restrictions d'applications ; voir par exemple la fameuse lens.
        
        Faudrait que je lise ça sérieusement un jour. J'avoue avoir utilisé une fois seulement les lens un tout petit peu avec un des framework web Haskell : j'avais commencé par faire du simple copié-collé d'un exemple qu'ils avaient sans comprendre exactement les agencements et, comme je voulais avoir un résultat vite, pas le temps d'apprendre, j'avais finalement recodé le truc vite-fait en Perl (de quoi faire peur à certains ^^), et c'est toujours ça qui tourne sans grands changements depuis :)
        
        C'est un peu lié à ce qu'on dit juste avant : quand on approche le concept avec la volonté d'apprendre, la lecture de tutoriels est une expérience très positive, mais quand on a un besoin un peu urgent, c'est facile de perdre patience en lisant en diagonale ce type de ressource pédagogique, plus adapté pour une lecture tranquille.
        
        Et n'oublions pas que c'est du logiciel libre : je ne doute pas que tu as les compétences nécessaires pour rédiger un patch de la documentation que tu as potassée ; pourquoi ne pas contribuer ?
        
        Parce que je fais d'autres choses aussi, qu'Haskell est plus très frais dans ma mémoire et que mon temps libre est limité, donc je me contente de faire du retour d'expérience, c'est pas beaucoup, mais mieux que rien peut-être :)
        
        D'ailleurs, quand je critique la doc, je fais pas vraiment un reproche, mais plutôt une remarque sur le fait que toutes les communautés n'ont pas la même approche à ce niveau et que c'est probablement un point à étudier d'un point de vue humain avec ses éventuels liens avec le langage en soi. C'est un sujet sur lequel j'aimerais bien savoir s'il y a une quelconque recherche sérieuse : l'influence du langage sur la communauté (style de la doc, outils, etc.) et les moyens de contrôler ça. Pas évident.
        
        Pour maximiser le sous-hors-sujet Haskell dans un déjà hors-sujet Go
        
        Ça part un peu dans tous les sens, mais c'est pas si mal d'avoir des exemples concrets pour alimenter la réflexion, même si ça part plus dans l'humain/les outils et leur interaction pas évidente avec le langage en soi :)
        
        à propos des opérateurs qui seraient horribles comme tu l'écrivais ailleurs dans les commentaires
        
        Je sais pas si c'était moi, ça, je me souviens juste avoir mentionné la prolifération des pragmas, mais je commence à m'y perdre un peu dans mes propres commentaires dans ce fil :)
        
        [^] # Re: go 2.0
        
        Posté par gipoisson le 20 octobre 2017 à 20:25. Évalué à 1.
        
        Oui, un de ces quatre, ré-essaie du Haskell, c'est du bon :)
        
        […] j'aimerais bien savoir s'il y a une quelconque recherche sérieuse [sur] l'influence du langage sur la communauté (style de la doc, outils, etc.) et les moyens de contrôler ça.
        
        Dans mes heures perdues, je lis de la Sociologie et disciplines apparentées, il y a des spécialités dans ces domaines tournées sur les sciences et pratiques de l'Informatique. Je n'ai pas une référence bien précise à donner tout de go, mais juste la première qui me vient après quelques clics sur Google Scholar : Type Systems and Programmers. Page 39 (traduction à l'arrache) :
        
        « Les annotations de type font partie de la documentation dans le sens où elles transmettent avec le code l'intention de son utilisation. Elles ont également un rôle normatif dans le sens où elles prescrivent ce à quoi le code ne devrait pas servir. »
        
        Visiblement, pour les auteurs et l'échantillon considéré, entre typer et faire de la prose, le choix est vite fait :) (O.K., je trolle, c'est vendredi …) À la page suivante, les auteurs relatent les effets de partir sur des exemples : quand le public visé a des niveaux hétérogènes, il y aura toujours des individus laissés pour compte.
        
        Je n'ai pas convenablement lu la thèse, ne pourrai donc en faire un juste résumé et place la référence ici comme un bookmark contextualisé (à mon usage). Peut-être qu'en y creusant, tu trouveras des pistes quant à ton questionnement.
        
        [^] # Re: go 2.0
        
        Posté par anaseto le 20 octobre 2017 à 21:12. Évalué à 2.
        
        Visiblement, pour les auteurs et l'échantillon considéré, entre typer et faire de la prose, le choix est vite fait :) (O.K., je trolle, c'est vendredi …)
        
        À un moment, en faisant du Perl et du Tcl, surpris par leurs documentations très exhubérantes (même trop pour Perl parfois), je m'étais fait la réflexion presque inverse : dans un langage totalement dynamique, les développeurs ressentent peut-être plus l'urgence de la documentation et des exemples, parce que n'ayant même pas d'outil extrayant des signatures automatiques pour les fonctions, même pas le nombre et les noms des arguments, ils ne sont jamais tentés de laisser quelque chose implicite à intuiter à partir d'une signature. En pratique, dans le pire des cas, c'est bien sûr pas d'exemples ni de signatures :)
        
        Je n'ai pas convenablement lu la thèse, ne pourrai donc en faire un juste résumé et place la référence ici comme un bookmark contextualisé (à mon usage). Peut-être qu'en y creusant, tu trouveras des pistes quant à ton questionnement.
        
        Merci pour le pointeur ! Il y a peut-être en effet de la matière à lire sur le sujet :)
        
        [^] # Re: go 2.0
        
        Posté par Moonz le 19 octobre 2017 à 10:19. Évalué à 2. Dernière modification le 19 octobre 2017 à 10:23.
        
        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.
        
        https://github.com/golang/go/issues/19412
        
        This has been discussed several times in the past, starting from before the open source release
        
        C’est pas qu’ils n’ont pas pris la peine de se poser la question, c’est qu’ils se sont posés la question et qu’ils ont décidé que ça n’en valait pas la peine.
        
        [^] # Re: go 2.0
        
        Posté par gasche le 19 octobre 2017 à 11:49. Évalué à 5.
        
        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.
        
        [^] # Re: go 2.0
        
        Posté par gasche le 19 octobre 2017 à 12:04. Évalué à 8.
        
        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".
        
        [^] # Re: go 2.0
        
        Posté par Nicolas Boulay (site web personnel) le 19 octobre 2017 à 12:13. Évalué à 4.
        
        Franchement écrit une proposition propre sur les type sum et poste un lien sur le blog de go 2.0
        
        https://github.com/golang/go/wiki/ExperienceReports
        
        Ils veulent des exemples, et nous on voudrait les types sum. Ils manquent sans doute une bonne explication entre les 2.
        
        L'idéal serait de faire la même chose pour transformer les packages en module, en rajoutant une déclaration "parameter" pour définir des paramètres à remplir à l'import d'un package ou simplement d'ajouter une liste de paramètre à la déclaration de package, puis de fixer un moyen de créer des package "complet" avec ses paramètres. Cela évite un peu la duplication de code, si l'instanciation est faite une seul fois. Si la syntaxe de ces paramètres est exactement symétrique avec des paramètres de fonction, cela devrait rester simple. Il reste la création de signature de package dont je ne vois pas trop à quoi il pourrait ressembler en go. L'idéal serait qu'un package soit à la fois une signature de module et un module, c'est plus simple.
        
        "La première sécurité est la liberté"
        
        [^] # Re: go 2.0
        
        Posté par gasche le 19 octobre 2017 à 13:01. Évalué à 7.
        
        Franchement écrit une proposition propre sur les type sum et poste un lien sur le blog de go 2.0
        
        On en revient aux soucis que j'avais signalés ici:
        
        Alors certes il ne serait pas trop difficile de faire une sémantique formelle pour Go, mais
        
        Pourquoi je me casserais les pieds à travailler pour des gens qui trouvent que le travail de ma communauté est inutile ?
        
        Pour qu'un langage profite d'un effort de formalisation, il faut que les concepteurs soient prêts à y participer, à éventuellement s'en inspirer pour changer des choses, et à rester en contact avec les gens qui font le modèle formel pour le faire évoluer en tandem avec le langage. Pour Go on n'a aucune assurance que ses auteurs seraient motivés pour jouer le jeu, et on a plutôt les signes qu'ils ne le seraient pas. (Au contraire des gens de Rust, qui ne se sont pas bougés le petit doigt pour une formalisation du langage pendant des années, mais qui ont au moins toujours été accueillants et positifs quand des académiques les contacts pour cela.)
        
        J'ai beaucoup de projets sur lesquels bosser qui m'intéressent, c'est moins motivant de travailler sur les types sommes en Go quand on ne sait pas si les concepteurs/implémenteurs du langage vont y consacrer un quelconque intérêt—il n'y a qu'à voir les réactions de la communauté LinuxFR ici pour voir que ce n'est pas gagné.
        
        Après peut-être que sur le long terme ça serait bénéfique en terme de d'impact sur l'imaginaire collectif des programmeurs, faire le travail de popularisation et de rendre l'idée "mainstream". Peut-être que Swift et Rust suffiront, et qu'on peut laisser Go rester un langage peu intéressant dans son coin ?
        
        [^] # Re: go 2.0
        
        Posté par chimrod (site web personnel) le 19 octobre 2017 à 13:48. Évalué à 5.
        
        il n'y a qu'à voir les réactions de la communauté LinuxFR
        
        Ça me gêne quand je vois ton amertume à ce sujet : je trouve que tu fais un super boulot pour communiquer sur des sujets assez pointus. À chaque fois que tu viens communiquer sur un sujet, je sais que je vais trouver un contenu détaillé et riche (et sur des sujets qui m'intéressent bien que ça ne me concerne pas directement.)
        
        Je vois ton journal comme une envie de parler d'un sujet qui te tiens à cœur, chose jamais simple quand on s'adresse à une communauté hétérogène (en terme de profil et caractères). Il faut s'attendre à 1) que l'on ne sache comment s'exprimer avec chacun 2) que le message ne soit pas compris par tout le monde. Dans tout les cas, ça ne sert à rien de vouloir s'entêter.
        
        Je peux comprendre que tu souhaites faire autre chose de ta vie que la vulgarisation à des masses qui ne comprennent pas vraiment de quoi tu es en train de parler (je force le trait volontairement), mais en venant présenter un journal sur le sujet ici, je pense que tu avais quand même l'intention de vouloir faire découvrir un sujet à des gens qui ne sont pas connaissent pas le sujet en question.
        
        Voilà. C'est la phrase qui m'a fait réagir, et sortir de mon statut de lecteur passif. Maintenant que j'ai commencé à écrire qqch, autant que ça serve quelque chose.
        
        Quitte à prendre du recul sur la programmation, autant en revenir à une question fondamentale : à quoi sert un langage de programmation ? Ton journal décrit les caractéristiques qui permettent d'évaluer un langage, mais n'aborde pas cette question. Est-ce qu'aujourd'hui en 2017, le langage de programmation est-là pour représenter la pensée d'un développeur, où pour lui permettre d'accéder à des espaces que sa pensée ne peut pas formaliser ?
        
        Je prends un exemple : les tours de Hanoi. Face au jeu, je serai incapable de résoudre le problème et lister les opérations à réaliser. Je ne peux donc pas décrire la procédure pour l'écrire dans un programme. Par contre, je peux écrire un programme (étonnamment court d'ailleurs) qui va me guider dans la solution. Dans cette situation qui dirige qui ?
        
        Autre question, qui porte cette fois sur la représentation d'un programme : est-ce qu'u n développeur se représente un programme comme un espace géographique (je sais où se trouve cette fonction), temporel. Et est-il possible de faciliter (à travers la grammaire et la présentation du code) la représentation qu'un être humain peut avoir du programme. (Est-ce que le principe d'utiliser l'indentation pour séparer les blocs conditionnels est pertinent ?)
        
        Je pense que ces questions ne te concernent pas personnellement et ne relèvent pas de tes compétences, mais si l'on veut ouvrir la question sur le domaine de la recherche en langage de programmation, il y a plein de questions qui peuvent se poser ^^
        
        [^] # Re: go 2.0
        
        Posté par gasche le 19 octobre 2017 à 15:02. Évalué à 3.
        
        Pour préciser peut-être (et dé-dramatiser un peu), je ne crois pas qu'il y ait de problème d'incompréhension du fond sur LinuxFR (la communauté est souvent pointue, sur des sujets différents, mais peut s'intéresser à des choses techniques)—et je ne me sens pas découragé par les commentaires. Ce qui me gêne plutôt c'est l'hostilité qui s'installe très vite dans les échanges. Mais dans la phrase que tu cites je faisais remarquer que la réaction des gens qui sont sur la défensive par rapport à Go dans ce fil, au point de ne pas vouloir reconnaître des choses qui sont assez évidentes il me semble, est assez caractéristique et que, évidemment, dans la communauté Go c'est pareil. (Évidemment pour vendre une collaboration à la communauté Go il est prudent de ne pas commencer à leur dire qu'ils ne font pas le job, même quand ce n'est pas faux.)
        
        La question de fond est nuancée est c'est la façon qu'on a de discuter ici (sur LinuxFR) qui lui enlève toute sa nuance. Peut-être que la meilleure façon de communiquer sur ce site c'est de poster un journal, de s'interdire de répondre aux commentaires, et de laisser les gens se débrouiller. Sur le coup c'est difficile de se retenir de commenter.
        
        [^] # Re: go 2.0
        
        Posté par anaseto le 21 octobre 2017 à 09:50. Évalué à 2.
        
        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.
        
        J'ai repensé après coup à ça, sur le moment acceptant ceci sans problèmes (rust fait ça avec ses traits), mais, que faire de la reflection si les interfaces ne sont plus des valeurs ? Ça semble être utile pour des choses comme un Marshall type-safe automatique d'une structure quelconque ou avec quelques restrictions (donc pas comme celui d'OCaml, qui n'est pas type-safe à la lecture) : je serais intéressé de savoir s'il y a des alternatives sans réflection, à la rigueur à coup de deriving semi-automatisé.
        
        [^] # Re: go 2.0
        
        Posté par gasche le 21 octobre 2017 à 11:51. Évalué à 3.
        
        La partie du message qui m'intéressait c'est "sum types are just types". Le traitement proposé des interfaces (comme des existentiels je suppose) est indépendant.
        
        Une interface Go c'est:
        - une valeur à un certain type $\alpha$
        - un morceau d'information $\mathsf{DynType}\;\alpha$ qui permet, quand on pattern-matche dessus, d'apprendre l'identité de $\alpha$ (en fait c'est string, ou int, etc.)—il serait naturel de représenter cela comme un cas particulier de type algébrique (extensible) généralisé, GADT, mais on peut aussi définir des règles de typage spécifique comme Go fait pour les "type switches"
        - de l'information (la vtable) sur où trouver les méthodes de l'interface, que l'on peut voir comme un produit/record des fonctions de l'interface et dont on peut appeler le type $\mathsf{Dict}\;\alpha$
        - le tout empaqueté dans un type existentiel qui rend la valeur de $\alpha$ "abstraite":
        
        Il pourrait être intéressant de se demander si ça vaudrait le coup de donner accès à ces composants de façon indépendante :
        
        Le fait que les existentiels sont forcément de la forme $\exists alpha. (\alpha \times ...)$ veut dire que tu ne peux pas avoir une interface qui n'est pas attachée à précisément une valeur du type. Généraliser permettrait plus d'expressivité. En Haskell par exemple tu peux définir une classe de type Default a qui est disponible pour les types a qui ont une valeur par défaut, et on veut pouvoir invoquer la méthode default :: a sans avoir de valeur de ce type sous la main. Il y a aussi plein de cas où un existentiel trimballe plusieurs valeurs de type $\alpha$ , une liste de valeurs, etc.
        
        Dans certain cas tu veux que les gens n'aient pas accès au type dynamique de la valeur, pour pouvoir protéger ton abstraction (et donc avoir la garantir que tu peux changer le type concret sans casser le code de l'utilisateur de ta bibliothèque).
        
        Ça semble être utile pour des choses comme un Marshall type-safe automatique d'une structure quelconque ou avec quelques restrictions (donc pas comme celui d'OCaml, qui n'est pas type-safe à la lecture) : je serais intéressé de savoir s'il y a des alternatives sans réflection, à la rigueur à coup de deriving semi-automatisé.
        
        Les classes de type marchent assez bien pour gérer le type Dyntype a, parce que c'est typiquement le genre de valeurs que tu veux passer implicitement, et pour lequel tu n'as pas envie/besoin d'avoir plusieurs implémentations pour un même type. Sinon on peut ajouter cette construction en dur dans le langage, ça a été prototypé pour OCaml (Runtime types in OCaml), mais l'interaction avec les barrières d'abstraction (le système de module) est un problème délicat.
        
        [^] # Re: go 2.0
        
        Posté par anaseto le 21 octobre 2017 à 12:55. Évalué à 2.
        
        Ok, je pense avoir à peu près tout compris, merci pour ces explications limpides !
        
        [^] # Re: go 2.0
        
        Posté par kantien le 21 octobre 2017 à 15:08. Évalué à 3. Dernière modification le 21 octobre 2017 à 15:10.
        
        Les classes de type marchent assez bien pour gérer le type Dyntype a, parce que c'est typiquement le genre de valeurs que tu veux passer implicitement, et pour lequel tu n'as pas envie/besoin d'avoir plusieurs implémentations pour un même type.
        
        On en revient toujours au fait que les modules implicites seraient une fonctionnalité géniales pour OCaml. Elle rendrait les modules encore moins citoyen de seconde classe que ne le font les first-class modules. ;-)
        
        Lorsque j'avais mentionné à Leo White l'article-tutoriel sur les structures canoniques en Coq, il m'a répondu l'avoir déjà lu (effectivement, cela fait même partie des références de l'article de présentation du prototype sur les modules implicites). Cela étant, ils mentionnent un autre article intéressant, qui pourrait servir de base pour la formalisation, dans leurs références : The Implicit Calculus: A New Foundation for Generic Programming qui mentionne aussi le tutoriel sur les structures canoniques. Mais il me vient à l'esprit une interrogation :
        
        l'article sur le calcul implicite se limite au système F ;
        
        les auteurs précisent que les structures canoniques n'ont pas été formellement spécifiées ;
        
        le mécanisme des arguments implicites est décrit pour tous les système du lamda-cube dans la partie 4 de la thèse de Amokrane Saïbi (en français \o/).
        
        S'il est vrai que dans sa thèse il décrit un algorithme d'unification plutôt qu'une formalisation à base de règles d'inférence à la Gentzen, les deux approches ne me semblent pas si éloignées et je ne vois pas ce qu'il manque à ce système pour fournir ce dont ont besoin les modules implicites pour synthétiser les arguments implicites.
        
        Dans un autre registre, sur le statut des modules dans le langage : que penses-tu des travaux de Rossberg, Russo et Dreyer sur 1ML présentés à l'ICFP en 2015 ? Cela demanderait trop de modifications à apporter au langage pour avoir cela dans OCaml ?
        
        An alternative view is that 1ML is a user-friendly surface syntax for System Fω that allows combining term and type abstraction in a more compositional manner than the bare calculus.
        
        et ça résoudrait les incompréhensions de Nicolas Boulay, ils y définissent les modules avec la syntaxe des enregistrements. ;-)
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: go 2.0
        
        Posté par anaseto le 18 octobre 2017 à 16:28. Évalué à 4.
        
        Go ignore (volontairement) les développements en langages de programmation qui ne viennent pas de ses auteurs
        
        Peut-être simplement qu'ils connaissent mal ces développements ou qu'ils n'étaient pas sûrs de comment les intégrer à leur langage et n'avaient pas le temps d'approfondir, qu'ils ont fait des compromis, etc. Car, pour autant que j'en sais, ils sont même ouverts à la programmation générique (à ce qu'ils disent), ils n'ont juste pas vu d'approche qui leur plaise intégrée à leur langage (un des développeurs du langage a écrit 4 propositions qu'il a lui-même rejetées, alors que ça a dû lui prendre bien du temps, car il n'arrivait pas à un truc satisfaisant). Donc si tu as un lien pour justifier ce « volontairement » comme philosophie déclarée du projet, ça m'intéresse. Qu'ils donnent volontairement une priorité secondaire à ces choses par rapport au reste semble déjà plus crédible.
        
        [^] # Re: go 2.0
        
        Posté par gasche le 18 octobre 2017 à 17:16. Évalué à 9.
        
        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.
        
        [^] # Re: go 2.0
        
        Posté par anaseto le 18 octobre 2017 à 18:20. Évalué à 3.
        
        Je suis d'accord que pour eux c'était quelque chose de secondaire (même si la première version stable date de 2011) et que leur approche à la création du langage donnait clairement priorité aux problèmes concrets qu'ils voulaient résoudre, dont éviter simplement (donc sans trop avoir à innover) la complexité. Pour le GC ils ont peu plus creusé la recherche, car c'était nécessaire pour leurs priorités. C'est juste que tel que c'est mentionné dans ce fil à plusieurs reprises, on dirait qu'ils font ça volontairement juste pour ignorer la recherche, comme s'ils avaient une dent contre la recherche :)
        
        Mais c'est sans doute juste l'effet fil de discussion linuxfr qui part dans tous les sens ;)
        
        [^] # Re: go 2.0
        
        Posté par SpaceFox (site web personnel, Mastodon) le 18 octobre 2017 à 16:06. Évalué à 9.
        
        J'appuie avec un exemple tout droit sorti de l'industrie. Dans beaucoup de secteurs, l'industrie a des préoccupations à des années-lumières des considérations développées ici. Beaucoup – trop – de code est écrit pour être jetable, et ce de façon tout à fait volontaire : la course effrénée à la nouveauté dans certains domaines (le web, les applications mobiles, qui sont deux secteurs très pourvoyeurs de codes et d'emploi informatique) fait qu'il est souvent plus rentable, en termes financiers, de sortir un produit au code crade, buggué, mais qui fait en gros le boulot, que de concevoir quoi que ce soit d'élégant. Parce que de toutes façons tout sera refait, avec un cycle de vie qui va de quelques mois à quelques années selon les parties du programme.
        
        Les besoins d'une grosse partie de l'industrie, aujourd'hui, ce n'est pas un langage mathématiquement élégant, ou qui a un quelconque rapport avec la recherche même d'il y a 40 ans.
        
        Ce que veut une grosse partie des « consommateurs » de langages de programmation, c'est un langage qui permet de :
        
        Écrire du code vite.
        
        Éviter les bugs triviaux.
        
        Soit simple à comprendre pour qu'on puisse mettre n'importe qui dessus avec le minimum de formation possible.
        
        Or si les langages qui plaisent aux chercheurs peuvent remplir 1 et 2, le 3 est généralement très loin d'être évident, surtout quand on parle d'introduire des paradigmes fonctionnels dans une industrie qui y touche assez peu, ce qui impliquerait une grosse quantité de formation pour le faire admettre.
        
        Un bel exemple concret de l'effet du pragmatisme dans l'utilisation des langages de programmation, c'est le couple Kotlin/Scala, deux langages conçus en réaction aux problèmes de Java et qui ont pour cible de tourner sur la JVM, tout en étant interopérable avec Java.
        
        Scala est intéressant conceptuellement, et a été inventé à l'École polytechnique fédérale de Lausanne. Il a son petit succès dans le monde des langages à JVM, mais n'a jamais été massivement adopté par d'énormes institutions et se traine une réputation de complexité d'approche et conceptuelle.
        
        Kotlin a été conçu par une industrie (JetBrains) et son approche est 100 % pragmatique : « si ça aide le développeur, on prends, sinon tant pis ». Il ressemble donc beaucoup plus à un gros tas de sucre syntaxique sur Java ; mais en dépit de concepts assez inintéressants et de qualité variable, il se développe dans le monde des langages à JVM comme aucun avant lui : https://trends.google.fr/trends/explore?date=all&q=%2Fm%2F0_lcrx4,%2Fm%2F091hdj,%2Fm%2F02js86
        
        Je ne dis pas que l'un est meilleur que l'autre. Mais déconsidérer des langages en se basant sur leur propreté mathématique ou leur rapport à la recherche, c'est faire une erreur d'appréciation monumentale qui ignore une part énorme des besoins et contraintes qui régissent l'utilisation desdits langages. Et c'est une erreur que je croise depuis des années dans la recherche en informatique ou même dans pas mal de communautés qui font des langages fonctionnels ( = censément meilleurs mathématiquement).
        
        La connaissance libre : https://zestedesavoir.com
        
        [^] # Re: go 2.0
        
        Posté par gasche le 18 octobre 2017 à 16:22. Évalué à 5.
        
        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.
        
        [^] # Re: go 2.0
        
        Posté par SpaceFox (site web personnel, Mastodon) le 18 octobre 2017 à 16:30. Évalué à 5.
        
        Jolie interprétation complètement à côté de la plaque de mon commentaire. Du coup, pas la peine de répondre à tes interrogations, vu qu'elles ne correspondent à rien.
        
        Je ne dis pas qu'il faut se passer de théoriciens. Bien sûr qu'ils sont indispensables !
        
        Mon point est que les positions à base de « c'est moche théoriquement, on ne devrait pas faire comme ça » sont, elles, problématiques. L'industrie a besoin des bons langages avec les bons outils au bon moment. Ce fait décorrèle complètement les inventions sur les langages de leur application « grand public ».
        
        Or, je vois encore trop souvent des critiques de langages qui ne se basent que sur leur intérêt théorique, sans tenir compte des problématiques pragmatiques (et politiques aussi : Go est poussé par Google) qui ont fait qu'ils sont arrivés là où ils sont.
        
        La connaissance libre : https://zestedesavoir.com
        
        [^] # Re: go 2.0
        
        Posté par gasche le 18 octobre 2017 à 17:03. Évalué à 1.
        
        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 ?
        
        [^] # Re: go 2.0
        
        Posté par Nicolas Boulay (site web personnel) le 18 octobre 2017 à 17:16. Évalué à 5. Dernière modification le 18 octobre 2017 à 17:17.
        
        1) pour avoir des briques de base sur lesquelles réfléchir
        
        2) parce que la beauté théorique n'est qu'une des multiples dimensions d'un langage (clarté, simplicité, debug, vitesse de compile, performance au runtime, …)
        
        "La première sécurité est la liberté"
        
        [^] # Re: go 2.0
        
        Posté par gasche le 18 octobre 2017 à 17:53. Évalué à 3. Dernière modification le 18 octobre 2017 à 17:54.
        
        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.
        
        [^] # Re: go 2.0
        
        Posté par Nicolas Boulay (site web personnel) le 19 octobre 2017 à 09:06. Évalué à 2.
        
        si elles demandaient d'introduire des choses difficiles à formaliser dans le langage.
        
        Non pas seulement. Difficile à comprendre par exemple, le comportement de la généricité avec les sous classe, le comportement de l'héritage multiple en diamant, etc… La gestion des multiples constructeur en C++ qui nécessite de bien comprendre le fonctionnement sous-jacent.
        
        En Ocaml, le code de base ne me pose pas de problème, si tu joues avec les modules et leur définition et un gadt au milieu, je vais beaucoup transpirer.
        
        A l'inverse, l'immutabilité de Ocaml permet d'éviter le concept de pointeur que tout débutant déteste.
        
        "La première sécurité est la liberté"
        
        [^] # Re: go 2.0
        
        Posté par kantien le 19 octobre 2017 à 10:24. Évalué à 2.
        
        En Ocaml, le code de base ne me pose pas de problème, si tu joues avec les modules et leur définition et un gadt au milieu, je vais beaucoup transpirer.
        
        Qu'est-ce qui te pose problème avec les modules ? Ce sont juste des enregistrements (tout comme les objets) avec des déclarations de type (pas comme les objets : les modules c'est des objets sous stéroïdes). Exemples :
        
        (* un point en 2D vu comme un enregistrement *) type pt_2D = {x : float; y :float} (* un point en 2D vu comme un objet *) class type obj_pt_2d = object method x : float method y : float end (* un point en 2D vu comme un module *) module type mod_pt_2D = sig val x : float val y : float end (* une valeur pour chaque type représentant le même point *) let rp : pt_2D = {x = 1.0; y = 2.0} let op : obj_pt_2d = object method x = 1.0 method y = 2.0 end module MP : mod_pt_2D = struct let x = 1.0 let y = 2.0 end rp.x = op#x && rp.y = op#y && rp.x = MP.x && rp.y = MP.y;; - : bool = true
        
        Contrairement aux enregistrements, on peut étendre les objets et modules par héritage :
        
        class type obj_pt_3D = object inherit obj_pt_2d method z : float end module type mod_pt_3D = sig include mod_pt_2D val z : float end let op_3D : obj_pt_3D = object method x = op#x method y = op#y method z = 3.0 end module MP_3D = struct include MP let z = 3.0 end op_3D#x = MP_3D.x && op_3D#y = MP_3D.y && op_3D#z = MP_3D.z;; - : bool = true
        
        mais seuls les modules peuvent contenir des déclarations de type, ce qui rend le concept plus abstrait, c'est à dire plus générique. ;-)
        
        module type Point_2D_t = sig (* type des coordonnées *) type t (* coordonnées du point *) val x : t val y : t end (* les annotations de type ne sont pas nécessaires, je les mets juste pour souligner qu'ils réalisent la signature *) module Pt_float : Point_2D_t with type t = float = struct type t = float include MP end module Pt_int : Point_2D_t with type t = int = struct type t = int let x = 1 let y = 2 end
        
        On pourrait faire la même chose en utilisant un enregistrement paramétrique : généricité sur les enregistrements (avec les objets, ça marche aussi).
        
        type 't pt_2D_t = {x : t; y : t} let p_float : float pt_2D_t = { x = 1.0 ; y = 2.0} let p_int : int pt_2D_t = {x = 1; y = 2} Pt_float.x = p_float.x && Pt_float.y = p_float.y;; - : bool = true Pt_int.x = p_int.x && Pt_int.y = p_int.y;; - : bool = true
        
        Mais là où seuls les modules peuvent exprimer un tel degré de généricité, c'est lorsque le type déclaré dans le module est lui-même paramétrique.
        
        module type Par = sig type 'a t type u val v : u t end module M : Par with type 'a t = 'a list and type u = string = struct type 'a t = 'a list type u = string let v = ["Hello World !"] end module N : Par with type 'a t = 'a option and type u = int = struct type 'a t = 'a option type u = int let v = Some 1 end
        
        Les modules permettent de pousser la généricité du code à un niveau inaccessible aux enregistrements et aux objets.
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: go 2.0
        
        Posté par Nicolas Boulay (site web personnel) le 19 octobre 2017 à 10:31. Évalué à 4.
        
        Les modules permettent de pousser la généricité du code à un niveau inaccessible aux enregistrements et aux objets.
        
        J'avais bien compris. Par contre, ce n'est pas du tout évident en lisant tes exemples. Et pourquoi 3 syntaxes différentes pour faire la même chose ou presque ?
        
        "La première sécurité est la liberté"
        
        [^] # Re: go 2.0
        
        Posté par kantien le 19 octobre 2017 à 12:07. Évalué à 2.
        
        Par contre, ce n'est pas du tout évident en lisant tes exemples.
        
        Essaye de faire le dernier exemple avec un enregistrement, tu verras le problème. ;-)
        
        type ('t,'u) par = {v : 'u 't};; Error: Syntax error
        
        Il est possible d'encoder la chose avec des enregistrements en utilisant la bibliothèque Higher et la technique dite de défonctionnalisation de Reynolds (transformer un code fonctionnel vers un langage non fonctionnel), mais ça devient aussi tricky que les modules.
        
        (* ce type sert d'encodage pour dire que l'on applique le type paramétrique 't à la variable de type 'a *) type ('a, 't) app module Higher_Kind (T : sig type 'a t end) = struct (* on a notre type paramétrique *) type 'a s = 'a T.t (* on le manipule de l'extérieur comme un type non paramétrique *) type t (* une injection et une projection pour passer de la version paramétrique à son encodage non paramétrique *) external inj : 'a s -> ('a, t) app = "%identity" external proj : ('a, t) app -> 'a s = "%identity" end module Higher_list = Higher_Kind(struct type 'a t = 'a list end) module Higher_option = Higher_Kind(struct type 'a t = 'a option end) type ('t, 'u) par = {v : ('u, 't) app} let m = {v = Higher_list.inj ["Hello World !"]};; val m : (Higher_list.t, string) par = {v = <abstr>} let n = {v = Higher_option.inj (Some 1)};; val n : (Higher_option.t, int) par = {v = <abstr>} M.v = Higher_list.proj m.v && N.v = Higher_option.proj n.v;; - : bool = true
        
        Manipuler les types paramétriques (qui sont des fonctions des types vers les types) comme des types de première classe au niveau des abstractions est ce que l'on appelle communément higher-kinded polymorphism : cela revient à voir le langage des types comme un langage fonctionnel et à lui associer son propre système de type (ou kind) en conséquence.
        
        Et pourquoi 3 syntaxes différentes pour faire la même chose ou presque ?
        
        Parce que les 3 ne font pas la même chose : les modules permettent de faire ce que font les deux autres, les objets ont l'héritage et le sous-typage mais pas les enregistrements, tous les modules ne peuvent pas être manipuler correctement en tant que citoyen de première classe (ceux qui ont des types paramétriques justement), et que le compilateur ne leur associe pas la même représentation mémoire en conséquence des différentes possibilités qu'ils offrent.
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: go 2.0
        
        Posté par Nicolas Boulay (site web personnel) le 19 octobre 2017 à 12:17. Évalué à 5.
        
        Parce que les 3 ne font pas la même chose
        
        En fait, je pensais au cas d'usage qui reviennent au même. Dans l'esprit, c'est 3 façon d'écrire la même chose, c'est anti-ergonomique, même si c'est formel.
        let rp : pt_2D = {x = 1.0; y = 2.0} let op : obj_pt_2d = object method x = 1.0 method y = 2.0 end module MP : mod_pt_2D = struct let x = 1.0 let y = 2.0 end
        
        "La première sécurité est la liberté"
        
        [^] # Re: go 2.0
        
        Posté par kantien le 19 octobre 2017 à 14:43. Évalué à 2.
        
        En fait, je pensais au cas d'usage qui reviennent au même.
        
        Mais s'il y a trois notations distinctes ce n'est pas pour l'espace de fonctionnalité qu'elles ont en commun, mais justement pour les fonctionnalités où elles diffèrent.
        
        Lorsque l'on écrit :
        
        let rp : pt_2D = {x = 1.0; y = 2.0} let op : obj_pt_2d = object method x = 1.0 method y = 2.0 end module MP : mod_pt_2D = struct let x = 1.0 let y = 2.0 end
        
        il y a des situations où utiliser l'une ou l'autre ne change rien (c'est le cas de tous mes exemples, sauf le dernier qui était là pour montrer ce que seul les modules peuvent faire sans encodage tricky), mais il y a des cas d'usage que seul l'une des approche permet d'appréhender. Tout dépend des besoins du programmeur et des choix architecturaux qu'il fera pour son application. Si je veux juste un dictionnaire de valeurs, je prends un enregistrement ; si je veux un dictionnaire avec relation de sous-typage (la base du paradigme objet), je prends un objet ; si j'ai besoin d'un plus haut niveau d'abstraction et de généricité qu'offre le langage, je prends un module. Comme l'absence de généricité ne semble pas te gêner dans un langage (en 2017 pour un langage jeune, j'ai du mal à comprendre), je comprends que l'utilité des modules ne te semble pas évidente.
        
        Je t'ai lu, plus d'une fois, disant que tu appréciais l'approche tagless-final pour l'interprétation¹ mais sans un niveau de généricité acceptable tu oublies (et sans higher-kinded polymorphism ça doit être une plaie à faire): c'est une condition sine qua non que doit offrir le langage hôte pour la mettre en pratique !
        
        même si c'est formel
        
        Il ne faut pas trop se prendre la tête sur cette notion de formel ou de formalisme. Toute pensée, consciemment ou inconsciemment, explicitement ou implicitement, est formelle : une pensée informelle est un non-sens, une contradiction dans les termes, un carré rond si tu préfères. Ce que font les approches formelles c'est rendre explicite le formalisme sous-jacent qui se trouve à la source de la pensée exprimer dans tel ou tel langage.
        
        Pour moi tout langage (et je ne parles pas là que des langages de programmation) n'est qu'une affaire d'interprétation, je préfère de loin cette notion à celle, souvent plus douteuse, de sémantique. Un compilateur : c'est une interprétation ; un type-checker : c'est une interprétation; un évaluateur : c'est une interprétation; un colorateur syntaxique : c'est une évaluation; une interface graphique : c'est une interprétation… La pensée, et de manière incidente son moyen d'expression : le langage, n'est rien d'autre qu'une affaire d'interprétation. ↩
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: go 2.0
        
        Posté par Nicolas Boulay (site web personnel) le 19 octobre 2017 à 15:23. Évalué à 3.
        
        Je trouve la généricité, les modules très utile. Mais je trouve que leur forme dans ocaml est très complexe et très peu lisible. Cela parait peut être évident pour toi qui est tombé dedans que tu es petit. Mais pour un concept complexe, il faut qu'il ressemble le plus possible à quelques choses de connu (principe UX de moindre surprise). Les modules ressemblent ici vaguement à des objets, avec des définitions de type dedans, mais avec une autre syntaxe.
        
        En fait, je pense qu'il doit être possible de proposer des modules en GO mais avec une syntaxe ultra simplifié pour la compréhension.
        
        Genre :
        package toto (type t, int i)
        
        func sort(tab t[i]) {…
        
        import "toto"(int, 1024) -> l'idéal serait d'avoir un seul module instancié pour ce couple de paramètre
        
        Pour l’extension d'un package, j'imagine qu'il doit y avoir déjà l'équivalent d'un "open".
        
        "La première sécurité est la liberté"
        
        [^] # Re: go 2.0
        
        Posté par gasche le 19 octobre 2017 à 15:26. Évalué à 2.
        
        (Pour information, moi aussi je trouve que les modules OCaml sont trop compliqués — dans les détails avancés. C'est très, très difficile de faire un bon système de modules, en fait c'est un problème de recherche ouvert.)
        
        [^] # Re: go 2.0
        
        Posté par kantien le 19 octobre 2017 à 18:40. Évalué à 2. Dernière modification le 19 octobre 2017 à 18:42.
        
        Les usages poussés du système sont effectivement compliqués, mais cela me semble en grande partie inhérent aux concepts même de modules. Cela ne m'étonne pas qu'il soit très difficile de faire un bon système de modules.
        
        Cela étant, si les utilisateurs de Go aimeraient avoir un équivalent dans le langage (comme semble l'exprimer Nicolas Boulay), ils peuvent toujours renvoyer les concepteurs du langage à l'article de Xavier Leroy A modular module system ;-)
        
        Abstract
        
        A simple implementation of an SML-like module system is presented as a module parameterized by a base language and its type-checker. This implementation is useful both as a detailed tutorial on the Harper-Lillibridge-Leroy module system and its implementation, and as a constructive demonstration of the applicability of that module system to a wide range of programming languages.
        
        C'est moi qui graisse.
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: go 2.0
        
        Posté par kantien le 19 octobre 2017 à 18:02. Évalué à 3.
        
        Mais je trouve que leur forme dans ocaml est très complexe et très peu lisible.
        
        J'ai fini par m'y habituer, mais il est vrai que le langage des modules et foncteurs est assez verbeux. Après sur la syntaxe concrète de définition d'un module sans paramètre, je ne vois pas bien la différence entre l'usage d'accolades ou celle de mots-clés :
        
        module type M = sig type t val v : t end (* VS *) module type M = { type t ; v : t ; }
        
        Par exemple, en Coq, où la distinction entre type et valeur n'a pas lieu d'être (les types sont des valeurs comme les autres et vivent dans le même monde), on utilisera la syntaxe des enregistrements pour écrire cela (même si Coq a aussi son système de modules).
        
        Record M : Type := mkM { t : Type ; v : t ; }.
        
        Quoi qu'il en soit, je ne trouve pas la syntaxe concrète pour écrire des modules ou leur signature si illisible que cela. Même dans les usages simples des foncteurs (qui sont des fonctions des modules vers les modules), je trouve la notation assez proche du langage des fonctions du langage.
        
        (* une signature pour exprimer la possibilité de convertir un type quelconque vers un string : c'est la donné conjointe d'un type et d'une fonction de conversion. *) module type Showable = sig type t val show : t -> string end (* à partir d'un tel module, il n'est pas difficile de définir des fonctions pour afficher le type à l'écran. On passera par un foncteur. On commence par étendre la signature précédente pour ajouter des fonctions d'affichage, puis celle du foncteur qui transforme un module du premier genre dans le second *) module type Printable = sig include Showable val print : t -> unit val println : t -> unit end module type Print_abs = functor (M : Showable) -> Printable module type Print = functor (M : Showable) -> Printable with type t = M.t
        
        Ici, c'est là que le langage commence à devenir verbeux, mais c'est par nécessité. Un module permet de cacher au monde extérieur la représentation concrète de ses types : pour faire en sorte que les données du type de M : Showable soient compatibles avec celles du module résultant de l'application Print(M), il faut le préciser explicitement via l'annotation with type t = M.t. Sans cela, le vérificateur de type se plaindra :
        
        module Show_int = struct type t = int let show = string_of_int end module Print_abs : Print_abs = functor (M : Showable) -> struct type t = M.t let show = M.show let print x = print_string (show x) let println x = print_endline (show x) end module Print : Print = functor (M : Showable) -> struct type t = M.t let show = M.show let print x = print_string (show x) let println x = print_endline (show x) end;; module Print_int_abs = Print_abs (Show_int) module Print_int = Print (Show_int) (* incompatibilité des types *) Print_int_abs.println 1;; Error: This expression has type int but an expression was expected of type Print_int_abs.t (* types compatibles *) Print_int.println 1;; 1 - : unit = ()
        
        Cependant l'aspect verbeux peut, dans les faits, se limiter aux fichiers d'interface .mli et le code effectif du fichier .ml être tout simplement :
        
        module Show_int = struct type t = int let show = string_of_int end module Print (M : Showable) = struct type t = M.t let show = M.show let print x = print_string (show x) let println x = print_endline (show x) end module Print_int = Print (Show_int)
        
        Cela parait peut être évident pour toi qui est tombé dedans que tu es petit.
        
        Je ne suis pas tombé dedans quand j'étais petit : c'est un niveau d'abstraction (auquel je suis largement habitué pour d'autres raisons, et encore je ne trouve pas cela très abstrait) dont j'ai ressenti le besoin, et j'ai appris la façon dont OCaml le met à disposition et à m'en servir. Si on n'en ressent pas soi même le besoin pour des raisons de généralisation, le concept de module semble tombé comme un cheveux sur la soupe.
        
        Les modules ressemblent ici vaguement à des objets, avec des définitions de type dedans, mais avec une autre syntaxe.
        
        Les deux syntaxes sont assez proches : ce sont les mots-clés qui changent. Cela me semble utile, voire conseiller au niveau du principe de moindre surprise, le second généralisant (en quelque sorte) le premier il serait surprenant que la syntaxe ne le signifie pas par un moyen quelconque : autrement on risquerait de confondre les deux notions.
        
        Pour conclure ce commentaire déjà bien long, comme toutes ces questions tournent autour de la notion d'abstraction (fonction, type paramétré, objet, module, foncteur…) il est normal que le lamba-calcul soit un outil théorique de premier choix. Dans ce langage, il n'y a que deux notions fondamentales : l'abstraction (le lambda) et l'usage d'abstraction (l'application). :-)
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: go 2.0
        
        Posté par Nicolas Boulay (site web personnel) le 20 octobre 2017 à 10:16. Évalué à 3. Dernière modification le 20 octobre 2017 à 10:18.
        
        il est vrai que le langage des modules et foncteurs est assez verbeux.
        
        Attention, la concision est souvent l'ennemi de la clarté. VHDL et ADA sont très verbeux mais très lisible. Je pense que l'abus de symbole est horrible pour la lecture. L'exemple typique sont les regexp Perl qui sont un cauchemar à lire, mais pas à écrire.
        Je me demande même si les symboles ne prennent pas "plus de place" dans la tête car il ne se prononce pas, sauf les symboles de base (+).
        
        module type M = sig
        type t
        val v : t
        end
        
        Pour moi, ce truc est bizarre car 2 mots clef se suivent ce qui est très rare ("Module type"), ensuite je lit "M = sig", sig étant un mot clef et ne m'indique pas du tout le début d'une liste qui se fait d'habitude avec des '(' ou des '{' ou des '[' voir des '<'. Ensuite, il y a le ':' qui alourdit la notation, alors que ocaml est ultra light d'habitude (pas de ',', ni de '(').
        
        En go, cela donnerait :
        
        type M module {
        type t
        var v t
        }
        
        (les types sont des valeurs comme les autres et vivent dans le même monde),
        
        C'est génial ça, il existe un autre langage où c'est possible, ou c'est impossible à compiler ?
        
        module type Showable = sig …
        
        Tu te rends compte qu'en go, cette fonctionnalité se fait simplement avec une fonction String() dans un objet ? Elle est reconnu comme présent dans la bonne interface, et le tour est joué.
        
        type Stringer interface {
        String() string
        } // est définit dans le code du package fmt
        
        Les deux syntaxes sont assez proches : ce sont les mots-clés qui changent. Cela me semble utile, voire conseiller au niveau du principe de moindre surprise,
        
        Non, elles ne sont pas proche justement, ni symétrique.
        
        il serait surprenant que la syntaxe ne le signifie pas par un moyen quelconque : autrement on risquerait de confondre les deux notions.
        
        C'est le but. Coq lui même ne fait pas la différence entre type et valeur, et c'est plus simple.
        
        "La première sécurité est la liberté"
        
        [^] # Re: go 2.0
        
        Posté par Moonz le 19 octobre 2017 à 10:34. Évalué à 3.
        
        Prend l’exemple sur lequel tu rales depuis le début de ce topic : l’absence de type somme dans Go.
        
        Peut-être que d’un point de vue d’un théoricien, c’est mieux. Peut-être. Je ne suis pas théoricien. Je te fais confiance.
        
        Mais s’ils veulent l’implémenter, il va falloir : l’implémenter, maintenir du code supplémentaire, le documenter, maintenir une documentation plus lourde, le tester, maintenir plus de tests. Et ce n’est pas simplement l’implémentation de référence : l’écosystème aussi va avoir à le supporter (par exemple, les outils d’analyse statique, de fuzzing, de génération de documentation, d’autocomplétion dans les IDE…)
        
        Tout ça a un cout bien réel, peu importe l’élégance théorique du concept.
        
        [^] # Re: go 2.0
        
        Posté par gasche le 19 octobre 2017 à 11:14. Évalué à 4.
        
        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.)
        
        [^] # Re: go 2.0
        
        Posté par Nicolas Boulay (site web personnel) le 19 octobre 2017 à 11:32. Évalué à 3.
        
        tu devrais lire le lien sur la discussion sur les types sum.
        
        Il demande par exemple comment filtrer "int | interface{}" sachant que interface{} fonctionne pour tout.
        
        "La première sécurité est la liberté"
        
        [^] # Re: go 2.0
        
        Posté par gasche le 19 octobre 2017 à 11:42. Évalué à 3.
        
        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).
        
        [^] # Re: go 2.0
        
        Posté par anaseto le 19 octobre 2017 à 15:06. Évalué à 2.
        
        Les types sommes pourraient être ajoutés, on est d'accord. Mais ce pour quoi ils sont utiles est déjà couvert (en moins bien si on veut) par les constantes (enums) et les interfaces (avec assertion de type) pour le reste. Ajouter maintenant les types somme signifierait que les programmeurs auraient maintenant deux façons différentes d'écrire certains programmes. Pour les fonctions renvoyant une erreur on aurait maintenant deux signatures : celles qui font comme maintenant, et celles qui renvoient un type option. Je comprends qu'étant donné l'actuel ça ne soit pas très cohérent de les ajouter. Tu vas me dire que c'est de la complexité accidentelle que d'utiliser constantes et interfaces pour faire des sommes (disjointes si on veut, il suffit d'implémenter une interface spécifique), mais personellement je me risquerais à parier que, dans ce cas, la complexité accidentelle est moindre que celle d'étendre le langage.
        
        Le concept de l'interface typée vérifiée par des couples (type, valeur) (en interne) est peut-être pas satisfaisant en théorie des types, mais c'est quand même très flexible pour vraiment pas cher (réflection quasi-gratuite en prime), je trouve, et une avancée par rapport à un langage purement dynamique.
        
        [^] # Re: go 2.0
        
        Posté par octachron le 19 octobre 2017 à 11:19. Évalué à 10.
        
        Tout ça a un cout bien réel, peu importe l’élégance théorique du concept.
        
        D'un autre côté, l'absence d'une implémentation des types sommes dans le langage a un coût bien réel à chaque fois qu'un programme utilise la notion de type sommes (parfois sans le savoir): il devient nécessaire de passer par des encodages compliqués pour implémenter le concept en se passant du soutien du compilateur: détection d'erreur, avertissements divers et variés, syntaxes plus légères.
        
        Un exemple concret, dernièrement je me suis amusé à écrire un binding OCaml pour Vulkan, dans l'API Vulkan on retrouve des structures comme
        
        typedef struct VkPipelineColorBlendAttachmentState { VkBool32 blendEnable; VkBlendFactor srcColorBlendFactor; VkBlendFactor dstColorBlendFactor; VkBlendOp colorBlendOp; VkBlendFactor srcAlphaBlendFactor; VkBlendFactor dstAlphaBlendFactor; VkBlendOp alphaBlendOp; VkColorComponentFlags colorWriteMask; } VkPipelineColorBlendAttachmentState;
        
        Un problème pratique avec cette structure est que si blendEnable vaut false tous les autres champs n'ont aucune importance; mais c'est un point qu'il est impossible de voir dans le système de type, et il devient difficile de savoir si ne pas initialiser le champ alphaBlendOp est une erreur ou pas. Au contraire, dans un système de type avec des types sommes, il devient possible d'écrire
        
        type VkPipelineColorBlendAttachmentStateCore = | Diabled | Enabled { srcColorBlendFactor: VkBlendFactor; dstColorBlendFactor: VkBlendFactor ; colorBlendOp: VkBlendOp; srcAlphaBlendFactor: VkBlendFactor; dstAlphaBlendFactor: VkBlendFactor; alphaBlendOp: VkBlendOp; colorWriteMask: VkColorComponentFlags; }
        
        et soudainement les cas d'ambigüités sur des champs non initialisés disparaissent.
        
        Et ce n'est qu'un cas parmi d'autres, de réimplémentation locale de types sommes dans l'API Vulkan.
        
        [^] # Re: go 2.0
        
        Posté par Moonz le 19 octobre 2017 à 12:25. Évalué à 0.
        
        Personne n’a dit le contraire. Ce qu’on dit, c’est qu’ajouter des fonctionnalités n’est pas un bénéfice « gratuit » sans contrepartie. Implémenter ou non implémenter, les deux ont des bénéfices et des couts. Pour le type somme, les concepteurs de Go ont jugé que le bénéfice apporté (dont personne n’a soutenu qu’il était nul) était plus faible que les surcouts.
        
        [^] # Re: go 2.0
        
        Posté par gasche le 19 octobre 2017 à 13:03. Évalué à 8. Dernière modification le 19 octobre 2017 à 13:04.
        
        À chaque version du langage les implémenteurs de Go ré-écrivent leur GC pour être moins naïf qu'avant. Ils auraient les sous de payer quelqu'un pour implémenter les types sommes (et les documenter, et adapter les outils, tout ça) s'ils en avaient envie. Le problème c'est le manque de connaissance et d'envie.
        
        [^] # Re: go 2.0
        
        Posté par auve le 18 octobre 2017 à 16:32. Évalué à 2.
        
        […] 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 ? […] 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 ?
        
        Je pense que c'est plus ou moins explicitement l'objectif d'une large partie de la recherche en ingénierie logicielle qui a lieu en France et à l'étranger.
        
        [^] # Re: go 2.0
        
        Posté par gasche le 18 octobre 2017 à 16:28. Évalué à 3.
        
        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.
        
        [^] # Re: go 2.0
        
        Posté par Nicolas Boulay (site web personnel) le 18 octobre 2017 à 16:45. Évalué à 4.
        
        Je pense que Renaut veut dire que la propreté formelle d'un langage ne le rend pas forcément clair et concis. C'est mieux, mais on peut vivre sans.
        
        "La première sécurité est la liberté"
        
        [^] # Re: go 2.0
        
        Posté par SpaceFox (site web personnel, Mastodon) le 18 octobre 2017 à 16:45. Évalué à 1. Dernière modification le 18 octobre 2017 à 16:46.
        
        L'exemple de Ceylon est intéressant, parce qu'il ressemble beaucoup à Kotlin par pas mal de points, a lui aussi été conçu et poussé par un industriel (RedHat)… mais a complètement foiré.
        
        Pourquoi ? Mystère.
        
        Mon interprétation personnelle du peu d'expérience que j'en ai, c'est que malgré ses qualités il ne répondait pas à la problématique qu'il cherchait à résoudre :
        
        Quand je fait du Java, j'ai l'impression de passer trop de temps à faire du code « technique » (boilerplate code, les machins qui sont là « pour que ça marche ») et pour peu de code « utile » (la logique de mon application, là où il y a l'intérêt à développer et de la valeur ajoutée).
        
        Quand je fais du Kotlin, j'ai l'impression ne ne faire pratiquement plus que du code « utile ».
        
        Quand je fais du Ceylon, j'ai surtout l'impression d'avoir un meilleur boilerplate code à écrire.
        
        Je ne sais pas s'il y a des recherches qui s'intéressent à l'ergonomie du code, mais ça serait intéressant à creuser.
        
        PS : souvent en programmation, on a : clair != concis.
        
        La connaissance libre : https://zestedesavoir.com
        
        [^] # Re: go 2.0
        
        Posté par gasche le 18 octobre 2017 à 16:52. Évalué à 4. Dernière modification le 18 octobre 2017 à 16:52.
        
        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.
        
        [^] # Re: go 2.0
        
        Posté par GTof le 19 octobre 2017 à 06:21. Évalué à 2.
        
        L'exemple microkernel vs monolytique n'est pas une bonne analogie. A ma connaissance, l'état de l'art sur les systèmes a micronoyaux n'a pas encore depassé celui des architectures monolithiques mis a part dans certains domaines très précis mais pas de manière générale. Alors que ca fait de nombreuses années que les concepts comme les generics, types somme, etc sont matures. Très rares sont aujourdh'ui les langages typés sans polymorphisme paramétrique.
        
        Opposer théorie et pratique n'a pas de sens. De plus en plus de programmeuses et programmeurs s'interessent a la théorie des types, a celle des catégories, aux systèmes de types affines (a la rust), etc. On ne compte plus le nombre d'articles de blog, de talk ou de livres sur les monades dans tel ou tel langage. On voit de plus en plus de talks d'introduction aux catégories dans des conférences de langages ou de livres a destination des programmeuses.eurs (cf celui de Bartosz Milewski), de nouveaux langages chechant a formaliser les effets ou verifier statiquement la justesse des allocations mémoires et accès concurents. Et bien sur aussi les langages a types dépendants qui gagnent en maturité.
        
        Tout ceci n'est pas un hasard, toutes ces avancés améliorent la productivité. Au rythme ou vont les choses, ils sera de moins en moins justifiable d'avoir des segfault par exemple. Certes ces nouveaux outils impliquent un cout non négligeable de formation, mais a choisir en entre cout de formation et cout en QA ou debugging, le choix sera vite fait. Payer des journées de dev pour coder ce qui pourrait se faire automatiquement avec des langages modernes ou a débugger des data race alors que le compilo pourrait en garantir l'absence a chaque build sera une position de plus en plus dur a justifier.
        
        [^] # Re: go 2.0
        
        Posté par Nicolas Boulay (site web personnel) le 19 octobre 2017 à 09:09. Évalué à 4.
        
        Tu ne travailles pas dans l'industrie, je me trompe ? Personne ou presque n'utilise de langage si avancé que ça. Un utilisateur d'ocaml/scala/haskell est vu comme un fou avant-gardiste. Les principaux langages sont toujours javascript, php, C, C++, Java, C#, perl, Go, ruby…
        
        "La première sécurité est la liberté"
        
        [^] # Re: go 2.0
        
        Posté par GTof le 22 octobre 2017 à 22:57. Évalué à 3.
        
        Justement si, je travaille bel et bien dans l'industrie. Les principaux langages sont effectivement Java, C#, C++, JS etc mais deux points importants sont a noter. D'une part les langages comme OCaml, F#, Scala, Haskell ou Rust sont de plus en plus utilisés dans l'industrie, d'autre part les langages plus classiques s'en inspirent. Le C++ à fait de gros progrès ces dernières années en programmation fonctionnelle avec les fonctions anonymes, l'inférence de types, optional, etc. Java lui aussi s'est vu doté de fonctions anonymes. Et il me semble que C# 7 va accueillir les tuples, record et pattern-maching.
        
        Scala est aujourd'hui un langage très utilisé. Certes moins utilisé que Java, mais ce dernier étant l'un des langages les plus utilisé, ça ne veut pas dire que Scala l'est peu, bien au contraire. Je connais moins les sphères professionnelles OCaml/F#/Rust/Haskell mais je pourrais citer pour chacun des acteurs majeurs l'utilisant. Le cas d'Haskell est d'ailleurs très intéressant car Elm et Purescript qui en sont d'inspiration très claire, gagent en popularité sur le font-end.
        
        L'industrie n'est pas hostile à l'utilisation de langages et techniques avancées, bien au contraire, du moment que ces dernières lui apportent un bénéfice anticipable. Dans la pratique 3 choses entre en ligne de compte: les bénéfices (en terme de productivité, ressources humaines, en terme d'image, de qualité produit, etc), les coûts (en terme de formation, difficulté de recrutement, etc) et la pérénité de la solution (pour la durée de vie du produit). Si tu arrives a convaincre les décideur.euses sur ces 3 points, c'est souvent dans la poche.
        
        J'utilise les outils théorique que j'ai cité tous les jours dans mon code et cela ce passe très bien (pour le code en questions et les collègues). Evidemment il n'est pas question de faire de la science et encore moins "pour la science" mais simplement d'utiliser les outils adaptés quand c'est pertinent.
        
        [^] # Re: go 2.0
        
        Posté par Renault (site web personnel) le 19 octobre 2017 à 09:16. Évalué à 4.
        
        L'exemple microkernel vs monolytique n'est pas une bonne analogie. A ma connaissance, l'état de l'art sur les systèmes a micronoyaux n'a pas encore depassé celui des architectures monolithiques mis a part dans certains domaines très précis mais pas de manière générale.
        
        Pourtant au niveau de la recherche sur le sujet, le noyau monolithique est obsolète par conception. Ce n'est pas moi qui le dit mais Tanambaum en 1992, qui est quand même un chercheur émérite du domaine. D'autant plus qu'il parlait au nom de son milieu, et non uniquement son point de vue personnel. Et il a répété jusqu'à sa retraite de la recherche que la conception de Linux, en n'étant pas un noyau monolithique, était toujours une erreur, que seuls les pure micro-noyaux avaient grâce à ses yeux.
        
        Il a comparé Linux, en 1992 quand Torvalds était encore qu'un étudiant, qu'il ne lui donnerait même pas la moyenne pour ce projet à cause de ce choix architectural dépassé.
        
        Bref, c'est en tout point semblable à ce que gasche déclare à propos de Go en tant que faute professionnelle en ignorant la recherche de son secteur d'activité sur le sujet.
        
        Opposer théorie et pratique n'a pas de sens.
        
        Bah, si.
        Les deux doivent communiquer pour que le tout avance, mais on ne peut pas prétendre qu'une bonne idée théorique est systématiquement une bonne idée pratique. Nous en avons constamment la preuve, les noyaux (domaine que je connais mieux que les langages) en est une bonne démonstration car le modèle actuel dominant est plus sur les approches hybrides (monolithique modulaire pour Linux et *BSD ou noyau hybride comme ceux de macOS ou Windows) que pure micro-noyau qui sont réservés aujourd'hui à des niches.
        
        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 théorie ne s'en préoccupe pas vraiment et c'est normal. Mais la pratique ne peut faire comme la théorie et tout refaire de zéro car la théorie dit que c'est mieux ainsi.
        
        Certes ces nouveaux outils impliquent un cout non négligeable de formation, mais a choisir en entre cout de formation et cout en QA ou debugging, le choix sera vite fait. Payer des journées de dev pour coder ce qui pourrait se faire automatiquement avec des langages modernes ou a débugger des data race alors que le compilo pourrait en garantir l'absence a chaque build sera une position de plus en plus dur a justifier.
        
        Mais tu ne peux dire demain de jeter des millions de lignes de code, de former des millions de développeurs d'un coup sur les nouvelles pratiques et espérer que ce soit économiquement intéressant. Les processus d'évolution que tu cites demandent du temps. Beaucoup de temps. Même certains langages comme COBOL, pourtant décriés, avec peu de personnes capables d'en tirer quelque chose était jusqu'à peu le pilier des applications bancaires. La transition vers Java fut très longue. Tu ne crois quand même pas qu'ils vont passer à Rust ou autre dès demain, si ?
        
        Sinon dès demain tout le monde utiliserait Coq pour avoir un programme sans bogue. Mais ce n'est pas le cas, car le gain n'en mérite peut être pas le coût associé. Ce n'est pas pour rien que Coq est globalement employé par les secteurs où le niveau de criticité est telle que Coq revient finalement moins cher qu'un code C minimal testé de toute part. Car c'est là qu'il se met en valeur.
        
        [^] # Re: go 2.0
        
        Posté par gasche le 19 octobre 2017 à 10:07. Évalué à 9.
        
        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.
        
        [^] # Re: go 2.0
        
        Posté par Renault (site web personnel) le 19 octobre 2017 à 10:39. Évalué à 3.
        
        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)
        
        Deux choses. Encore une fois, tu oublies significativement le contexte ou tu le rends négligeable. Pourtant ils sont fondamentaux.
        
        Linux était un projet jouet pour Torvalds, pour apprendre l'x86. Le monolithique était juste le moyen le plus simple pour aboutir à un résultat rapidement. Ce sont ensuite les autres qui ont porté Linux au delà du projet jouet, car Linux était à ce moment là, le seul noyau libre convenable. *BSD avait l'épée de Damoclès du procès (et est de toute façon monolithique aussi), Minix n'était pas libre et Hurd on l'attend toujours.
        
        Torvalds n'aurait jamais lancé un tel projet si un micro-noyau libre existait et fonctionnait, Linux n'aurait jamais été un micro-noyau car ce n'était pas l'objectif de Torvalds avec le contexte de l'époque.
        
        Et l'avenir lui a donné raison, il n'existe aucun micro-noyau pur avec une utilisation très large. Windows et macOS (qui ne sont pas codés par des ignorants non plus) n'ont jamais franchi le pas de tout mettre en espace utilisateur faute de performances acceptables.
        
        Et on peut largement sécuriser encore le noyau Linux sans aller dans le micro-noyau fondamentalement. Mais là encore, la sécurité absolue au niveau noyau, c'est contre les performances aussi. Il faut faire des compromis. Et le compromis, ce n'est pas un micro-noyau pur.
        
        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.
        
        Tu as pourtant reproché des choses à Go qui demanderaient de changer l'architecture de Go. et qui est difficile à faire aujourd'hui car ce n'est pas cohérent avec l'architecture choisie. Que c'est trop tard.
        
        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".
        
        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. Honnêtement, je ne suis toujours pas convaincu que c'est un manque aussi important que tu l'énonces.
        
        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).
        
        Tu oublies le code passé et la formation des gens. Il y a bien plus de gens, surtout dans le milieu où Go évolue, où le C (voire C++ et Python) est la référence qu'OCaml ou Rust. Go était destiné quand même à ces gens là, une évolution en douceur. Cela ne me paraît pas débile de garder un langage simple et assez proche d'un autre langage pour attirer les développeurs sans leur faire peur.
        
        De la même façon que développeurs COBOL n'est pas parti sur OCaml non plus pour refaire les systèmes bancaires alors que les avantages du langage sont évidents. Mais voilà, pareil, les gens efficaces en Java tu en as suffisamment et les développeurs de COBOL trouvent sans doute la transition plus douce aussi.
        
        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
        
        Tu es toujours dans l'histoire du théorie -> pratique, mais au vue de tes déclarations où tu sembles (volontairement ou non) ignorer ce qu'est la vraie vie d'un projet informatique en entreprise, du savoir des développeurs. Je dirais que l'inverse devrait aussi se faire, que les théoriciens ne s'offusquent pas car ils n'ont pas été entendus par eux. Peut être qu'ils l'ont été mais qu'ils ont arbitré différemment avec leur justification (ce que Go notamment a explicité sur certains choix). Je trouve facile de toujours réclamer à être entendu mais de ne pas faire l'effort soi même dans l'autre sens.
        
        [^] # Re: go 2.0
        
        Posté par gasche le 19 octobre 2017 à 11:35. Évalué à 6. Dernière modification le 19 octobre 2017 à 11:37.
        
        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.)
        
        [^] # Re: go 2.0
        
        Posté par anaseto le 19 octobre 2017 à 15:24. Évalué à 3.
        
        C'est une faute de ne pas le faire !
        
        Une faute, une faute, je sais pas pourquoi il faut essayer de culpabiliser les autres ^^ Ils ont fait un truc qui correspondait plus ou moins à leurs besoins, aux besoins d'autres personnes aussi, faut pas chercher beaucoup plus loin : à la base le langage est pensé par trois personnes uniquement, pas tout Google. La faute, ça serait autant aux autres, d'avoir accepté le truc tel quel. Et bon, perso je suis bien content que ce langage existe, je l'utilise juste pour quelques projets sur mon temps libre, mais ça m'a permis de pas avoir à m'inquiéter de choses comme la sérialisation (sauvegarder une structure plus ou moins quelconque se fait en quelques lignes, alors que dans d'autres langages ce n'est pas trivial), les builds, etc. et quand je reviens plusieurs mois après sur mon projet, j'ai pas l'impression d'avoir oublié la moitié du langage (bonjour Haskell et ses lentilles et flèches). Je suis content aussi que d'autres langages existent et que de meilleurs langages soient développés (système de types évolué, super outils, builds rapides, etc.). On aura peut-être tout ça en même temps un jour :)
        
        Go aurait pu être une occasion pour un nouveau public de découvrir, c'est une occasion manquée, c'est très dommage.
        
        Bon, soyons plus optimiste, au moins ils ont eu les lambdas depuis le début, et ils sont assez populaires et faciles à utiliser, pas comme en Java :) Là le grand public apprend les lambdas, ça prépare le terrain pour les types somme dans la prochaine décennie ;)
        
        [^] # Re: go 2.0
        
        Posté par gasche le 19 octobre 2017 à 13:12. Évalué à 3.
        
        Tu as pourtant reproché des choses à Go qui demanderaient de changer l'architecture de Go. et qui est difficile à faire aujourd'hui car ce n'est pas cohérent avec l'architecture choisie. Que c'est trop tard.
        
        Tu mélanges ce que j'ai dit sur les types sommes et les génériques, qui sont deux fonctionnalités très différentes.
        
        (J'aime pas trop me mettre à discuter de "ah mais tu as dit", "ah mais non j'avais pas dit…"; je clarifie ici mais je ne répondrai plus sur ce terrain là.)
        
        [^] # Re: go 2.0
        
        Posté par Thomas Douillard le 19 octobre 2017 à 11:30. Évalué à 3.
        
        J’ajouterai perso que la théorie sur la sémantique d’un langage, ça devrait largement aider à construire un outillage puissant pour l’écosystème du langage.
        
        L’exemple de l’inférence de type est un cas d’école, je pense : c’est une fonctionnalité très bien comprise théoriquement, qui permet d’aider le programmeur à faire moins d’erreur. La coloration syntaxique, c’est quand même utile d’avoir une grammaire formelle pour l’implémenter, et ces objets sont très bien connus théoriquement. Ça fait partie du baggage de base d’un informaticien. Peut être d’ailleurs qu’un des boulot du chercheur en langage c’est d’essayer de penser à des outils que la formalisation des langages peut aider à concevoir … après tout si c’est plus régulier et plus compréhensible pour les humains, c’est aussi très utile pour les machines pour raisonner sur le programme …
        
        [^] # Re: go 2.0
        
        Posté par Nicolas Boulay (site web personnel) le 19 octobre 2017 à 10:23. Évalué à 3. Dernière modification le 19 octobre 2017 à 10:24.
        
        "Il a comparé Linux, en 1992 quand Torvalds était encore qu'un étudiant, qu'il ne lui donnerait même pas la moyenne pour ce projet à cause de ce choix architectural dépassé."
        
        Et on peut voir que Linus avait raison. Les tentatives de micronoyau ont tous abandonné, ou on finit avec des très gros noyau pour des raisons de performances (windows NT, le truc d'apple,…). Rien ne va plus vite qu'un appel de fonction.
        
        Si tu veux de la sécurité, il faudrait activer les protections mémoires dans le noyau lui-même( avec une gestion de droit interne). Il le font bien maintenant même pour les DMA.
        
        "La première sécurité est la liberté"
        
        [^] # Re: go 2.0
        
        Posté par claudex le 19 octobre 2017 à 14:07. Évalué à 3.
        
        ême certains langages comme COBOL, pourtant décriés, avec peu de personnes capables d'en tirer quelque chose était jusqu'à peu le pilier des applications bancaires. La transition vers Java fut très longue.
        
        Elle n'est même pas finie. Si tu veux bien gagner ta vie, fait du Cobol, je connais des endroits qui engagent encore sur ces compétences.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: go 2.0
        
        Posté par SpaceFox (site web personnel, Mastodon) le 19 octobre 2017 à 10:14. Évalué à 3.
        
        De plus en plus de programmeuses et programmeurs s'interessent a la théorie des types, a celle des catégories, aux systèmes de types affines (a la rust), etc.
        
        Ce qui est horrible en fait dans la réalité, c'est la quantité de développeurs (dans le sens : des gens qui travaillent ou veulent travaille dans ce boulot) qui ne s'intéressent absolument pas à ce qu'ils font : c'est juste un boulot alimentaire comme un autre (mais qui souvent a nécessité 5 ans d'études, va comprendre).
        
        Dans mon ancienne boite, une SSII correcte dans son genre, une des premières questions qu'on posait en entretient était : « Comment est-ce que vous vous tenez au courant des nouveautés dans le domaine » – question cruciale dans le développement web ou mobile, où tout change très vite. Eh bien un gros tiers des candidats ne se tenait pas à jour du tout, et on était contents de trouver quelqu'un qui s'intéresse un minimum au sujet. Et ce en ne recrutant que des ingénieurs.
        
        C'est un état de fait qui me désole. Mais la triste réalité du terrain, c'est que y'a une part non négligeable de ceux qui produisent n'utilisent les nouveautés technologiques que contraints par le projet. Et ça devient un vrai problème quant ce comportement se retrouve chez des gens expérimentés censément porteurs de projet.
        
        La connaissance libre : https://zestedesavoir.com
        
        [^] # Re: go 2.0
        
        Posté par Blackknight (site web personnel, Mastodon) le 19 octobre 2017 à 13:57. Évalué à 3.
        
        Mais la triste réalité du terrain, c'est que y'a une part non négligeable de ceux qui produisent n'utilisent les nouveautés technologiques que contraints par le projet.
        
        Il y a un problème avec l'inverse, c'est quand un développeur utilise dans son coin, hors préconisation du projet, son petit bijou technologique bien hype que lui seul connait.
        A partir de ce moment, c'est la mort pour la maintenance du projet si le mec se barre.
        C'est du boulot pas de l'expérimentation.
        D'ailleurs, quand on voit la durée de vie de certains frameworks JS, c'est pas franchement raisonnable de parier sur le tout nouveau tout beau.
        
        [^] # Re: go 2.0
        
        Posté par anaseto le 18 octobre 2017 à 16:15. Évalué à 4.
        
        (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 !)
        
        C'est moins satisfaisant qu'un type somme, en effet. Mais j'ai du mal à en faire tout un pâté inadmissible comme toi : en tous cas, j'ai codé en Go et OCaml, et (a, err) := m'a pas causé plus de soucis que les exceptions (invisibles dans la signature) en OCaml ; en fait moins : d'accord, c'est peut-être juste parce qu'on abuse des exceptions en OCaml, donc pas propre au langage, mais on trouve cela jusque dans la librairie standard.
        
        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.
        
        En effet, mais 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, car en ayant une vision trop ancrée système de types, on finit par ne voir plus que cela dans le langage ; je vois ça dans ma communauté aussi (qui est similaire à la tienne), et même si je comprends et moi aussi j'apprécie les avancées dans le domaine, j'aimerais voir plus d'auto-critique sur certains langages : par exemple Haskell suit la voit de la complexité et des pragmas à tout va, OCaml de plus en plus aussi, avec tout plein d'annotations spéciales maintenant, qu'ils finissent par ressembler au C++ et ça fait peur ; surtout qu'OCaml est un langage que j'aime bien en dehors de quelques manques et fonctions dans la librairie standard et la syntaxe, plus la couche objet qui n'est pas rentable à mon avis, et la syntaxe limitée pour la programmation impérative avec des tableaux (qui a le mérite d'exister, contrairement au cas d'Haskell).
        
        [^] # Re: go 2.0
        
        Posté par Nicolas Boulay (site web personnel) le 18 octobre 2017 à 16:50. Évalué à 3.
        
        Je suis du même point de vue.
        
        ocaml sans l'objet et sans le gadt, et le coté module illisible pour non-initié est un super langage simple, mais avec un lib pauvre.
        
        ELM http://elm-lang.org/ est un nouveau langage qui veut reprendre les bonne pratique des nouvelles lib javascript mais vérifier correctement l'usage (react, DOM virtuel…). Il inclus le type sum. C'est un truc à regarder.
        
        "La première sécurité est la liberté"
        
        [^] # Re: go 2.0
        
        Posté par anaseto le 18 octobre 2017 à 17:57. Évalué à 2.
        
        Ce qui est amusant, c'est qu'on dirait que les deux on aime bien OCaml, mais qu'on a réussi a apprécier Go aussi, et parfois ça surprend (en tous cas dans ma communauté). C'est plus typique les passages Python/Ruby/Perl vers Go.
        
        [^] # Re: go 2.0
        
        Posté par Nicolas Boulay (site web personnel) le 19 octobre 2017 à 09:13. Évalué à 3.
        
        Je n'ai pas eu le choix. Je voulais garder ocaml, mais pour faire un server web, c'est juste pas possible. ocsigen est peut être très bien, mais il faut un bac+12 en théorie des langages pour comprendre l'exemple de 100 lignes, en plus, ce n'est plus vraiment du ocaml.
        
        La simplicité de go me repose l'esprit. Tu retrouves toujours les mêmes pattern de code, tu rentres en 10s dans un nouveau code. Tu ne passes pas ton temps sur une nouvelle particularité du langage. J'aime bien aussi le système d'interface qui rend inutile les class mère, ce qui permet d'avoir plus de réutilisation de code.
        
        "La première sécurité est la liberté"
        
        [^] # Re: go 2.0
        
        Posté par gasche le 18 octobre 2017 à 17:35. Évalué à 2. Dernière modification le 18 octobre 2017 à 17:36.
        
        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.
        
        [^] # Re: go 2.0
        
        Posté par anaseto le 18 octobre 2017 à 18:00. Évalué à 2.
        
        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.
        
        Je sais bien, je suis de temps en temps ce qui se fait sur OCaml, même si j'avoue être un peu à la traîne sur les dernières nouveautés :)
        
        [^] # Re: go 2.0
        
        Posté par Nicolas Boulay (site web personnel) le 18 octobre 2017 à 16:36. Évalué à 3.
        
        Avec la lib de base de Ocaml tu ne fais pas grand chose. En dehors d'un "filtre unix", tu n'as rien sous la main (tout ce qui prend des fichiers en entré et qui produit une sortie). Tout ce qui est serveur ou interface graphique, est obsolète ou niveau bricolage dans ocaml.
        
        Pour faire un compilateur ocaml est génial, pour du web ou une interface graphique, il faut tout refaire soi-même. c'est d'ailleurs pour ça que j'ai regardé golang.
        
        Et si ocaml stagne, c'est Rust qui risque de lui prendre un peu de sa niche écologique restante.
        
        "La première sécurité est la liberté"
        
        [^] # Re: go 2.0
        
        Posté par lendemain le 19 octobre 2017 à 11:05. Évalué à 1.
        
        Pour moi la faute professionnelle est plus à attribuer aux personnes qui ont choisi go pour implémenter un gros projet et se plaignent au bout d'un moment que go n'a pas suffisamment d'abstractions pour facilité la complexité d'un large projet.
        
        [^] # Re: go 2.0
        
        Posté par gasche le 19 octobre 2017 à 11:17. Évalué à 2.
        
        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.
  - [^] # Re: go 2.0
    
    Posté par damaki le 18 octobre 2017 à 16:30. Évalué à 2.
    
    Absolument. Go 1 ne part pas du tout de la recherche en langages mais du vécu des langages existants. Go 1 part du principe que continuer à faire tout ce qu'on fait actuellement en C, c'est douloureux, c'est complexe et qu'on a souvent aucune autre bonne raison que "le compilateur est dispo partout". Un autre principe est que la programmation orientée objet ajoute de la complexité et de l'imprévisibilité. Et pour finir, il y a des outils pour la concurrence de processus, prévus de base, parce que c'est toujours pénible à gérer à la main.
# Questions en vrac.

Posté par kantien le 18 octobre 2017 à 10:18. Évalué à 3.
Avant de te poser quelques questions qui me viennent en vrac, je voudrais d'abord te dire que cela fait plaisir de te lire à nouveau dans ces colonnes. :-)

Ma première question sera une question quelque peu indiscrète en réponse au pourquoi de ton journal : pourquoi avoir écrit un journal sur la question ? Autrement dit, qu'est-ce qui t'a amené à écrire là, maintenant, un article sur l'intérêt de la recherche en langages de programmation ?

La seconde m'est venue à la lecture de ce passage :

Il s'agit en quelque sorte d'un ensemble de tests pour évaluer un langage. Cet ensemble de tests évolue au fil du temps, car nous affinons notre compréhension de ces propriétés formelles et nous en proposons de nouvelles, à partir de nos expériences d'utilisation des langages existants ou expérimentaux.

As-tu lu le dernier ouvrage de Jean-Yves Girard : Le fantôme de la transparence ? Il y expose les avancées de la logique mathématique, en particulier la logique linéaire, et le rapport syntaxe-sémantique y est présenté via l'image de l'usine et de l'usage qui se testent réciproquement (son exemple fil rouge est celui du lecteur blue-ray et du blue-ray et des convertisseurs blue-ray vers dvd : un lecteur teste que l'objet est un bien blue-ray, comme le blue-ray peut tester que lecteur en est bien un).

La suivante a trait à la cohérence des langages et plus particulièrement OCaml. J'ai toujours trouvé qu'il y a un manque de cohérence dans la syntaxe concrète des types paramétriques : ce sont des fonctions des types vers les types, pourquoi ne pas utiliser la même syntaxe que les fonctions et la curryfication ? Haskell n'a pas ce défaut et ReasonML le corrige pour OCaml (c'est bien là la seule amélioration de cette syntaxe, pour le reste j'espère bien que ça ne s'étendra pas au-delà de la communauté Javascript). Ce point a-t-il déjà été abordé au sein de l'équipe en charge du développement du langage ?

Enfin, sans doute la question la plus importante : où en est le langage Chamelle ? A-t-il suivi les évolutions de son binôme soumis à l'impérialisme linguistique de la perfide Albion ? Un tel code est tout de même plus convenable pour un francophone :-D
```
type 'a arbre = Feuille de 'a | Nœud de 'a arbre * 'a arbre

soit rec feuille_existe p arbre =
  filtre arbre avec
  | Feuille v -> p v
  | Nœud (gauche, droite) ->
      feuille_existe p gauche
      || feuille_existe p droite
```
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
- [^] # Re: Questions en vrac.
  
  Posté par gasche le 18 octobre 2017 à 10:49. Évalué à 3.
  
  La syntaxe des types paramétrés est une vieille discussion qui n'a pas attendu Reason; la "syntaxe révisée" de Camlp4 était déjà disponible en 2001 et faisait ce changement. Je n'ai pas en mémoire de discussion récente au sein de l'équipe de développement, mais je pense que tout le monde est convaincu que l'écriture list 'a est meilleure sur le long terme¹. (Un autre aspect de la syntaxe révisée qui était une amélioration est pour les constructeurs, Cons of 'a and 'a list et ensuite Cons 1 Nil dans les expressions et les motifs).
  
  ¹: par "sur le long terme" j'entends que la syntaxe int list est en fait assez naturelle (voire élégante) en anglais—elle a été choisie pour ça—mais que les coûts se sont révélés avec le temps: le fait que tous les langages utilisent l'autre ordre et qu'on programme plus au niveau des types qu'à l'époque où ML est né, c'est clair qu'utiliser le même sens que l'application au niveau des termes est le meilleur choix. Après je fais partie des gens qui préféreraient qu'on écrive en maths, mais c'est encore un autre débat.
- [^] # Re: Questions en vrac.
  
  Posté par gasche le 18 octobre 2017 à 10:52. Évalué à 3. Dernière modification le 18 octobre 2017 à 10:53.
  
  Je n'ai pas (encore ?) lu "Le fantôme de la transparence", mais je pense que tu sautes un peu du coq (sic) à l'âne. En réalisabilité, en ludique, et sans doute dans les derniers machins de Girard l'idée des tests est importante, mais on utilise le mot "test" dans ce contexte parce que ça nous rappelle les "tests" que l'on effectue quand on écrit un programme mais aussi quand on construit une voiture, un lave-linge etc. Je pense que c'est une idée importante de parler de propriétés (subject reduction, principal types, type erasure…) comme de tests de concepts, mais pour moi c'est à approcher du cadre général des lave-linges et des voitures. C'est donc lié aussi, transitivement, aux tests de la réalisabilité ou de la ludique, mais ce n'est pas plus lié à ces derniers qu'à ceux des cuisinières à gaz.
  - [^] # Re: Questions en vrac.
    
    Posté par kantien le 18 octobre 2017 à 15:03. Évalué à 2. Dernière modification le 18 octobre 2017 à 15:08.
    Je n'ai pas (encore ?) lu "Le fantôme de la transparence", mais je pense que tu sautes un peu du coq (sic) à l'âne.
    
    Oui, je saute du coq à l'âne, cette question m'est juste venue à l'esprit par association d'idée, je ne sous-entendais pas un lien fort entre les deux concepts de tests.
    
    dans les derniers machins de Girard […]
    
    Il y a une chose qui m'intringue chez Girard dans sa lecture de la syllogistique aristotélicienne. Il met systématiquement en rapport la forme Barbara (les animaux sont mortels, or les hommes sont des animaux, donc les hommes sont mortels) avec la transitivité de l'implication (composition des morphismes catégoriques pour la logique classique, composition des opérateurs hilbertiens pour la logique linéaire) :
```
(*
|- A -> B    |- B -> C
-----------------------
      |- A -> C
*)

fun g f x -> f (g x);;
- : ('a -> 'b) -> ('b -> 'c) -> 'a -> 'c = <fun>
```
    là où, pour moi, il m'apparait plus évident que Barbara c'est du sous-typage structurel :
```
 S <: M    M <: P
------------------
      S <: P
```
    Barbara : c'est la transitivité du sous-typage, raison pour laquelle les prédicats sont unaires chez Aristote et qu'il n'y a aucune distinction logique entre sujet et prédicat : quelque chose qui ne peut être pensée que comme sujet mais jamais comme prédicat est une substance, concept qui appartient à la métaphysique mais non à la logique (comme un terme qui ne peut être également vu comme un type).
    
    Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
# Concernant la clarté

Posté par plr le 18 octobre 2017 à 15:20. Évalué à 2.

Merci pour ton partage. Concernant ton paragraphe sur la clarté, j'émets des réserves et des désaccords.

la clarté: En lisant le texte d'un programme, il faut qu'il soit facile de comprendre l'intention des personnes qui l'ont écrit.

Je suis entièrement d'accord et j'irais même plus loin: un code source "beau" est plus facile à comprendre et vérifiable (relecture) que s'il suivait strictement les "règles" édictées par des normes, règles d'usages, etc.
"C'est véritablement utile puisque c'est joli." (Saint Exupéry - Le Petit Prince)

On dit qu'un programme a un bug (un défaut de fabrication) quand sa signification (pour l'ordinateur) ne correspond pas à l'intention de ses auteurs—une erreur a été faite pendant la transcription des idées dans le texte du programme.

Je pense que ta définition du bug est trop réductrice, incomplète et donc erronée. J'illustrerai ce point ci-dessous.

La clarté est un composant essentiel de la sûreté (éviter les comportements inattendus et dangereux).

C'est ton avis et celui-ci n'est pas objectif et ne correspond pas à la réalité de la production de code informatique: la clarté du langage est différente de la clarté du code produit.

Pour l'améliorer, 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.

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.
La réalité dans le monde des systèmes informatiques embarqués est tout autre: actuellement, je remarque que dans un bon nombre de cas, les bugs sont liés à des problèmes d'architectures, de "design", c'est à dire d'un malfonctionnement du cerveau du ou des personnes en charge de la cohérence d'un programme. Ensuite, des problèmes du non-respect du mode d'emploi des objets pilotés. Finalement assez peu de la transcription en elle-même: la faille WiFi WPA2 plaide en ma faveur!

1) Pour prendre 3 exemples:
- c'est l'histoire d'un architecte qui avait inversé le rôle de maître/esclave entre un producteur de données et d'un consommateur de données. Concrètement, celà donnait des trous et des désynchronisations de l'audio par rapport à la vidéo lors de l'affichage d'une vidéo (heureusement, la société a été rachetée, diluée, et avec ceci, la reconversion de ces personnes arrivés à leur niveau d'incompétence (principe de Peter): et oui, je suis frustré par ces personnes qui n'ont pas voulu écouter)
- ou encore plus proche, l'autoradio qui lit les AAC/MP3 dans ma voiture (Peugeot) interrompt la lecture avant la fin du fichier (et passe au fichier suivant) dès qu'il a envoyé la dernière trame au décodeur et pas dès que le dernier échantillon sonore a été réellement produit par le haut-parleur: en regardant le code, l'architecture, les tests, tu auras 100% de réussite aux vérifications et aucun bug trouvé! Pourtant mon vieux lecteur iPOD le fait correctement.
- Dans le domaine médical? Pourquoi le système de radiographie n'a-t-il pas pu démarrer le samedi quand je me suis présenté aux urgences et qu'il a fallu changer de service pour en trouver un qui accepte de démarrer? Je n'ai aucune preuve, mais je doute qu'il y ait un bug dans la transcription d'une idée

2) Le code est souvent écrit pour qu'il soit plus facilement vérifiable et contrôlé par des outils automatiques que pour la facilité de relecture: MISRA, SIL, PEP8 (ou autres règles rédigées par des personnes en manque de pouvoir). Ce qui donne du code illisible: i.e. immonde à relire et donc à vérifier la transcription. Finalement, la clarté du langage est dégradée par les normes et règles de production ce qui fait que beaucoup de code source passe les étapes de validation sans avoir été relu, compris et vérifié mais juste signé par un individu lambda. (pour le code d'Apple: qu'il n'ait pas été fait consciencieusement me surprendra moins que si on me dit qu'il n'y avait pas de relecture/peer review du code source!)

Mes conclusions sont:
- il y a, à notre époque, plus de problèmes dans le cerveau des concepteurs plutôt que dans la transcription des idées (dans le mien en premier!)
- La clarté du langage et du code source est régulièrement mise à mal par l'obligation de respecter des normes/règles de codage
- Les normes et règles de codage sont cependant indispensables pour réduire le nombre de bugs de transcription des idées au risque de dégrader la clarté.

D'où les questions: quels sont les liens entre la clarté d'un code source et celle du langage en lui-même? La clarté d'un code source peut-elle être forcée par le langage?
- [^] # Re: Concernant la clarté
  
  Posté par gasche le 18 octobre 2017 à 15:38. Évalué à 4.
  
  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.)
  - [^] # Re: Concernant la clarté
    
    Posté par Nicolas Boulay (site web personnel) le 18 octobre 2017 à 17:06. Évalué à 5.
    
    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.
    
    Il me semble que tu te limites trop. Tu embarques ça dans le terme "outils", mais je ne pense pas qu'un code informatique doit se limiter à du texte dans un éditeur de fichier. Eclipse introduit des sorte de lien hypertexte, l'auto-completion et la vérification d'erreur en ligne, cela aide beaucoup le codeur. Il y a une masse d'information qui pourrait être fournis par l'outil de dev, qui ne nécessite pas une notation du codeur. L'idée est qu'un codeur veut de la concision, quitte à faire trop de raccourci (oublies de vérifier les erreur ou les exceptions), mais un relecteur veut de la clarté (il est plus facile de vérifier l'oublie d'un test d'erreur qu'un catch d'exception). Un codeur veut un texte pour décrire ses objets rapidement, un relecteur veut un diagramme de classe ou de machine d'état ou de block pour tout appréhender rapidement.
    
    Cette vidéo est absolument à voir : https://www.youtube.com/watch?v=PUv66718DII C'est un rêve de dev d'avoir une boucle de rétroaction aussi rapide.
    
    Je pense vraiment qu'il faut arrêter de voir la sémantique d'un langage uniquement à travers une suite de caractère. Et la meilleur méthode pour écrire un code, n'est pas forcément la meilleur pour le relire.
    
    "La première sécurité est la liberté"
  - [^] # Re: Concernant la clarté
    
    Posté par Nicolas Boulay (site web personnel) le 18 octobre 2017 à 17:14. Évalué à 3.
    
    Si on ne spécifiait tout qu'une seule fois, sans jamais aucun recouvrement, on ne pourrait pas détecter automatique d'incohérence.)
    
    Je suis assez d'accord avec toi. Mais tu peux rajouter une dimension : on peut vouloir forcer l'usage d'une library d'une certaine façon (contrat). Ainsi, on évite les bug d'un usage de travers. Il y a duplication, mais dans le temps.
    
    Cela me rappelle une discussion sur un codeur MS qui avait rajouter des checks de cohérence avec des assert() dans une lib. Ses utilisateurs râlaient, mais cela voulait surtout dire que des bug étaient masqués.
    
    D'ailleurs si tu regardes la normes aéronautiques (FACE), il y a une description des variables d'entrée assez mortel avec 4 dimensions (ex: vitesse, vitesse par rapport au sol, en m/s, en fixe 32 bit de 0 à 300). Cela permet de coller des lib qui traitent de vitesse et de faire des conversions automatiques par génération de code statiques si l'unité n'est pas la bonne.
    
    "La première sécurité est la liberté"
# Avec un peu de distance...

Posté par arnaudus le 23 octobre 2017 à 10:13. Évalué à 10.

J'ai l'impression d'arriver un peu après la bataille, mais je me permets de proposer un point de vue un peu moins orthodoxe. Je suis assez d'accord sur les trois aspects demandés à un langage de programmation (concision, clarté, cohérence), bien que chacun de ces aspects doivent probablement plus à l'habilleté du programmeur qu'au langage lui-même. On peut bien sûr estimer que certains langages rendent la tâche plus ou moins facile, mais il reste tout à fait faisable d'écrire du code verbeux, obscur, et incohérent dans tous les langages de programmation.

Par contre, j'avoue me retrouver un peu perdu par la suite du journal, qui se focalise sur la formalisation mathématique et l'invention / la distribution d'outils de programmation innovants. Je suis un simple "utilisateur" de langages de programmation, je ne suis pas informaticien, et pour moi la programmation n'est pas une fin en soi, c'est juste un outil qui permet d'arriver à un résultat scientifique. Mon approche de la programmation est donc assez pragmatique, et l'objectif est d'optimiser un gloubiboulga de temps de formation, temps de codage, temps de déboggage, et temps d'exécution ; bref, de trouver des compromis. Or, j'ai l'impression que la "recherche en langage de programmation", telle que décrite dans ce document, n'a pas du tout pour objectif de faciliter la tâche de gens qui sont dans le même cas que moi. Je sens même que ça pourrait être le contraire. Typiquement, ce qui me gène le plus au quotidien, c'est le compromis performances/productivité. Pour les mini-projets, les langages de haut niveau (non-typés, avec d'énormes bibliothèques livrées par défaut—algorithmique, statistiques, GUI, I/O, etc) sont hyper-productifs ; en 5 minutes on peut avoir un script qui fonctionne, qui est portable, et qui fonctionnera encore probablement dans 15 ans. D'expérience, j'ai beaucoup moins de bugs dans ce genre de programmes que dans des langages compilés (pas de pointeurs, pas de comportements indéfinis, pas de dépassement de capacité…). Ce sont des langages qui sont concis, clairs, et cohérents pour l'usage au quotidien. En fait, je crois que c'est ça le problème : la programmation au quotidien, c'est 1% d'algorithmique et 99% de "trucs" autour, et ce sont ces trucs qui pourrissent la vie (lecture/écriture, formattage de données, internationalisation, etc).

Du coup, la discussion ci-dessus sur le langage Go est particulièrement éclairante. J'ai l'impression que Go est typiquement un outil dont une partie substantielle des programmeurs a besoin. Or, je suis surpris de voir autant de mépris de la part de la communauté des chercheurs en langages de programmation envers Go. Quelque part, je ne peux pas m'empêcher d'y voir un fossé énorme entre ce que les programmeurs ont besoin, et ce dont les chercheurs pensent que les programmeurs ont besoin. Et du coup, ce passage vers la formalisation mathématique des langages, moi, ça me laisse complètement froid, ce n'est pas ça dont j'ai besoin. Je n'ai pas besoin de démontrer mathématiquement que mon code est parfait, ça me semble même totalement inutile. Ce que je veux, c'est coder vite, que le code soit clair et évolutif, que mes collaborateurs et mes étudiants puissent le comprendre sans 4 ans de formation, et que le programme fonctionne vite et sans surprise (et qu'il plante s'il y a un bug).
# Coquille

Posté par cpm le 06 novembre 2017 à 14:21. Évalué à 2.

Relevé d'une petite coquille mineure dans ce texte très intéressant :

En particuliar […]