Delphine Demange et les compilateurs

Posté par Ysabeau 🧶 (site web personnel, Mastodon) le 17 octobre 2025 à 10:22. Édité par vmagnin, Julien Jorge et Arkem. Modéré par Pierre Jarillon. Licence CC By‑SA.

Étiquettes :

oct.

2025

Cette année, la date de la journée Ada Lovelace, une journée dont l’objectif est d’accroître la visibilité des contributions des femmes dans les domaines scientifiques, technologiques, mathématiques et ingénierie (STEM), est le 15 octobre 2025.

Pour l’occasion, en 2023, LinuxFr avait consacré une dépêche à Lorinda Cherry, Evi Nemeth et Jude Milhon. En 2024, cela avait donné lieu à une mini-série sur la participation des femmes à la conquête de l’espace. Cette année, on se penchera sur les compilateurs, créés par Grace Hopper, et qui ont valu à Frances Allen un prix Turing en 2006 et on dressera le portrait de Delphine Demange, lauréate du prix Gilles Kahn 2013.

Bandeau Journée Ada Lovelace, la photo vectorisée d’Ada sur fond d’un de ses manuscrits dans des tons sépia

Sommaire

Qu’est-ce qu’un compilateur ?
Delphine Demange : comment vérifier que les compilateurs font leur travail correctement
- Parcours
- La vérification des logiciels
Quelques autres sources d’information
Questions et remerciements

Qu’est-ce qu’un compilateur ?

La naissance des compilateurs

Le premier compilateur, il s’appelait « translator » (traducteur) à l’époque, a été inventé par Grace Murray Hopper pour l’UNIVAC 1 en 1951, l’A-O System. Soit après la sortie de l’IBM 604 (1948), avant celle de l’IBM 650 (1954) et un peu avant le FORTRAN, langage compilé, créé vers 1953 par John Backus pour l’IBM 701 et lancé en 1957. La même année où IBM embauche Frances Allen pour former des scientifiques et des ingénieurs réticents à l’utilisation du langage. Elle sera, en 2006, la première femme à obtenir un prix Turing. Elle raconte, dans les Annals of History of Computing (Volume 6, N°1, janvier 1984) que :

L’une des façons dont le laboratoire de recherche a convaincu les gens à utiliser ce langage a été d’imposer son utilisation via un règlement.

Elle ajoutera :

le compilateur FORTRAN a établi la norme en matière d’efficacité du code objet. Mais surtout, il a démontré la faisabilité de l’utilisation des langages de haut niveau. Lorsque j’ai enseigné le FORTRAN en 1957, l’utilisation de ce langage a rencontré une forte résistance. Cette résistance a rapidement été érodée par le type de code produit par le compilateur.

John Backus, qui trouvait par ailleurs que Grace Murray Hopper était difficile à égaler, détaillait dans ces mêmes annales les auteurs et l’autrice du compilateur. Peter Sheridan avait écrit la section 1 qui analysait les expressions algébriques, les traduisait en code et optimisait ce code. Pour la section 2, Harlan Herrick avait inventé l’instruction DO, rédigé : « la partie de la section 1 qui regroupe toutes les informations sources non utilisées dans les expressions algébriques dans des tableaux nécessaires aux sections suivantes. ».

C’est également à Herrick que l’on doit l’introduction des mots clés GO TO ! Roy Nutt a conçu la majeure partie du langage d’entrée/sortie et rédigé la partie de la section 1 qui traduisait les instructions d’E/S en boucles DO. Il a également rédigé la section 6, qui assemblait le programme symbolique final et complétait le traitement des instructions d’E/S. C’est également à Nutt que l’on doit l’introduction de l’instruction FORMAT. Bob Nelson et Irv Ziller ont rédigé la section 2, qui s’est avérée être la plus grande section du compilateur. Elle analysait les références aux tableaux dans les boucles DO et produisait un code hautement optimisé pour le reste du programme source. Leur travail a eu un impact important sur le niveau global d’optimisation que j’ai mentionné précédemment. Dick Goldberg a rédigé la section 3, qui rassemblait le code compilé par les sections 1 et 2 et produisait d'autres informations nécessaires aux sections suivantes. Les gens continuaient à se concerter et à demander aux auteurs des sections précédentes de produire un peu plus, quelques tableaux supplémentaires dont ils avaient finalement besoin. Dick a également joué un rôle important dans le débogage de la section 5. Lois Haibt (en) a rédigé la section 4, qui effectuait une analyse statistique de la fréquence d'exécution […] Ici, la section 4 a également préparé de nombreux tableaux pour la section 5, si je comprends bien. Sheldon Best a écrit la section 5, qui a converti le programme utilisant de nombreux registres d'index en un programme en utilisant trois. Ses méthodes ont eu un impact considérable sur les travaux ultérieurs dans ce domaine et ont eu un effet majeur sur le niveau d'optimisation du compilateur. Enfin, David Sayre a rédigé un manuel du programmeur exceptionnellement clair et concis et a aidé Dick Goldberg à déboguer la section 5.

Structure d’un compilateur : 1 déclarations identifieur et traducteur, 2 analyse indice et déclaration DO, 3 Interface entre 1 et 4, 4 anlyseur de flux de contrôle, 5 allocateur de registre global, 6 assemblage final
Schéma de la structure du compilateur de l’ordinateur IBM 704 adapté de celui fait par Frances Allen dans les « Annals of History of Computing », Volume 6, N°1, janvier 1984 (page 24).

De leur côté, les Soviétiques, qui fabriquaient aussi des ordinateurs, utilisaient également des compilateurs. Dans son article sur les ordinateurs soviétiques, Yves Logé rapporte qu’ils utilisaient, en 1955, les langages de compilation : PP2 – PP et BESM. Le BESM étant un ordinateur sorti en 1953. La fondatrice de la programmation théorique en Ukraine, Katerina Yushchenko (en), y a fort probablement contribué.

À quoi ça sert ?

En août 2001, dans un entretien (en) avec Janet Abbate qui lui demandait comment elle définirait un compilateur, Frances Allen répondait :

Je pense qu’un compilateur sert à traduire ce que l’utilisateur de l’application […] demande […] à la machine de manière à obtenir la bonne réponse, mais aussi à utiliser au mieux les ressources de la machine. C’est ça, l’optimisation. On peut se contenter de transposer les choses sans tirer parti des registres et de nombreuses autres unités de calcul, mais cela ne serait pas aussi efficace. L’optimisation consiste donc à tirer parti des ressources de la machine et à très bien connaître cette dernière. C’est en quelque sorte combler un fossé, afin que l’utilisateur n’ait pas besoin de tout savoir !

Plus généralement, un compilateur est décrit comme un programme dans un langage de haut niveau qui traduit le code-source en code objet pour le rendre exécutable en détectant les erreurs et en l’optimisant par la même occasion.

Schéma d’un compilateur
Le code source est envoyé au compilateur qui le traduit en langage machine.

Les compilateurs sont des outils essentiels et très complexes qui interviennent dans tous les programmes, notamment des logiciels très critiques :

Par exemple, les programmes embarqués dans les systèmes bancaires, dans les systèmes de contrôle de vol des avions, ou même dans la chirurgie assistée par ordinateur ou les centrales nucléaires […] : la présence d’erreur durant leur exécution pourrait avoir des conséquences désastreuses, que ce soit en termes de vies humaines, de dégâts écologiques, ou de coût financier. (Delphine Demange, Semantic foundations of intermediate program representations, Thèse soutenue le 19 octobre 2012.)

Comment ça marche ?

Réponse rapide : avec beaucoup de mathématiques. Réponse un peu plus détaillée : à partir de différents types d’analyses après une phase de pré-traitement qui permet de déterminer comment traiter les informations.

L’analyse lexicale : découpe le code en unités lexicales ou « tokens » qui vont permettre au compilateur de traiter les données par la suite. Ce faisant le compilateur sépare les différents types d’éléments : variables, opérateurs, séparateurs, mots-clés, etc.
L’analyse syntaxique : vérifie que le programme source ne contient pas d’erreur de syntaxe et que le code source est correct et, évidemment le compilateur signale les erreurs qu’il a pu trouver à ce stade.
L’analyse sémantique : après la syntaxe, c’est le sens du code qui est examiné. Le compilateur va ainsi vérifier s’il y a des erreurs de logique, passant, que le code fait bien ce qu’il est censé faire. À ce stade, le compilateur va aussi signaler les erreurs, voire, rejeter un code incorrect.
L’optimisation : permet de nettoyer le code pour le rendre plus rapide à exécuter. À l’heure actuelle avec des processus très gourmands en ressources, c’est une étape-clé, ça n’a pas toujours été forcément le cas.
La génération du code final : c’est la dernière phase dont le résultat est le code exécutable.

Delphine Demange : comment vérifier que les compilateurs font leur travail correctement

Parcours

Delphine Demange entre en licence d’informatique à l’université de Rennes 1 en 2004. Elle y obtiendra un magistère Informatique et télécommunications en 2006 puis fera le mastère de recherche en informatique de la même université en 2008. Elle achèvera cette partie de ses études par un stage de master à l’IRISA (équipe Celtique), en vérification de programme. Au bout des cinq mois de stage, en 2009, elle s’inscrira en thèse. Une thèse, Fondements sémantiques des représentations intermédiaires de programmes (en), soutenue en 2012 et qui lui vaudra le prix de thèse Gilles Kahn 2013 de la SIF, et qui porte sur :

la vérification formelle de logiciel, c’est-à-dire à l’ensemble des techniques et d’outils scientifiques qui permettent d’assurer qu’un logiciel remplit ces exigences [de qualité des systèmes critiques]. (Résumé étendu de sa thèse).

Elle part ensuite pour les USA, à l’Université de Pennsylvanie pour une année de post-doctorat. Là, elle travaillera sur un projet alliant vérification et sécurité. De retour en France, elle passe des concours. Elle est, depuis 2013, maîtresse de conférence à l’université Rennes 1.

En février 2024, elle donnait un cours au Collège de France : Représentations intermédiaires pour la compilation : s’affranchir du graphe de flot de contrôle.

On peut retrouver ses communications et articles ainsi que sa thèse, toutes en anglais, sur HAL science ouverte.

La vérification des logiciels

Comme elle le dit en résumé de sa thèse :

Nos vies quotidiennes dépendent de plus en plus, sans même parfois que nous nous en rendions compte, de l’utilisation de programmes informatiques. Ces programmes n’ont toutefois pas tous le même niveau de criticité. Par exemple, les programmes embarqués dans les systèmes bancaires, dans les systèmes de contrôle de vol des avions, ou même dans la chirurgie assistée par ordinateur ou les centrales nucléaires sont appelés systèmes critiques : la présence d’erreur durant leur exécution pourrait avoir des conséquences désastreuses, que ce soit en termes de vies humaines, de dégâts écologiques, ou de coût financier. Ce type de programme requiert donc de fortes garanties : leur exécution ne devrait pas échouer, et leur correction fonctionnelle devrait être garantie.

Elle ajoute plus loin que les compilateurs étant des logiciels, ils sont à leur tour susceptibles d’avoir des bugs comme n’importe quel autre programme. Il est donc nécessaire qu’ils répondent aux mêmes exigences infaillibilité que les systèmes critiques sur lesquels ils travaillent.

Dans un entretien accordé au site de l’université de Rennes en 2014, elle précise que son travail a pour but final :

d’assurer, par une preuve mathématique et assistée par ordinateur, que les compilateurs compilent correctement les programmes (i.e. ils n’ajoutent pas de nouveaux comportements aux programmes), et que les vérifieurs calculent des propriétés sur des modèles corrects des programmes (si le modèle du programme ne comporte pas d’erreur, alors le programme d’origine n’en comporte pas non plus).

Ses travaux de thèse portant les représentations intermédiaires (IR) des programmes sur lesquels travaillent les compilateurs et vérificateurs. Ces IR simplifient les analyses de ces outils qui peuvent analyser des programmes très complexes. Elle continue, depuis, ses recherches dans le même domaine avec :

la vérification des techniques de compilation optimisantes pour les langages de haut-niveau, en y incluant les aspects les plus difficiles des langages modernes, comme la gestion de la mémoire, la concurrence et les modèles de mémoire faibles. (entretien, Université de Rennes).

Tout cela demande beaucoup de mathématique, parfait pour quelqu’un qui a hésité entre les maths et l’informatique.

Quelques autres sources d’information

Sur les compilateurs, internet est bien pourvu en ressources en français sur le sujet, par exemple :

— Compilation informatique : définition concrète et rôle, Journal du net, 2016,
— Comment fonctionnent les compilateurs, IBM, [sd],
— Qu’est-ce qu’une conception de compilateur ? Types, outils de construction, exemple, Kaia Céruléen, GURU99, [septembre 2025 ?],
— Cours de compilation, [sd],
— Compilation, pdf à télécharger,
— Langages de programmation et compilation, Jean-Christophe Filliâtre, septembre 2016,
— Représentations intermédiaires pour la compilation : s’affranchir du graphe de flot de contrôle, cours au Collège de France, 15 février 2024
— Fondements sémantiques des représentations intermédiaires de programmes, thèse, en anglais, de Delphine Demange.

Sinon on peut aussi lire ou relire l’hommage à France Allen sur LinuxFr. Il y a aussi, en anglais, cet article Early Computers and Computing Institutions (en) qui raconte les débuts de FORTRAN. C’est très intéressant. Mais il faut soit l’acheter (15,50 dollars pour les membres ou 30 dollars pour les non-membres) ou faire partie d’une structure adhérente.

Questions et remerciements

Compte de tenu de l’importance des compilateurs, la question se pose de la raison pour laquelle la personne qui a été à l’origine du premier compilateur et du COBOL, Grace Murray Hopper (1906-1992) n’a pas reçu le prix Turing pourtant créé de son vivant, en 1966, et à une époque où elle était encore active. Le récipiendaire du prix Turing 1966 ayant d’ailleurs été Alan J. Perlis pour la construction de compilateurs.

Question complémentaire, pourquoi France Allen n’a reçu son prix Turing qu’en 2006 « pour ses contributions pionnières à la théorie et à la pratique des techniques utilisés par les compilateurs optimiseurs qui ont jeté les bases des compilateurs optimiseurs modernes et de l’exécution parallèle automatique. » Frances (“Fran“) Elizabeth Allen. A.M. Turing Award 2006 (en), alors qu’elle avait pris sa retraite depuis 2002. Elle reste toujours aussi importante : un de ses textes de 1970 fait partie de la bibliographie de la thèse de Delphine Demange.

Dernière question, dans son discours de remise du prix Turing en 2007, Frances Allen disait qu’après une phase de stagnation des compilateurs, on devrait avoir une phase de progrès significatifs dans le domaine. Est-ce que vous avez une idée de ce à quoi elle aurait pu penser ?

Un très grand merci à vmagnin pour son aide et les documents qu’il m’a envoyés pour m’aider à rédiger cette dépêche.

Aller plus loin

Page Delphine Demange sur le site de l'Irisa (81 clics)
Entretien avec Delphine Demange (60 clics)

# Prix Turing et Grace Hopper

Posté par lasher le 17 octobre 2025 à 18:14. Évalué à 10 (+12/-0).
Sommaire
De l'attribution du prix Turing

Pourquoi Alan Perlis et pas Hopper ? Parce que c'est lui qui a fourni un premier compilateur fonctionnel (qui prend un programme de « haut niveau » — si j'ai bien compris, il s'agissait de formules mathématiques — en entrée et génère du code machine en sortie).

Grace Hopper a proposé le premier langage (et le compilateur associé) « pour humains » je dirais, et que je qualifierais de « généraliste » (même si je pense que le langage créé par Perlis était aussi Turing-complet). C'est l'une des premières personnes à insister sur la notion de lisibilité des programmes (au sens d'avoir un programme écrit « en anglais », ou quelque chose d'approché), et très clairement la première à avoir mené à bien ce projet.

Par contre, il existe un prix Hopper (et à ma connaissance pas de Prix Perlis), qui récompense une contribution unique et majeure accomplie avant 35 ans. Bon, il a été créé après la mort de Grace Hopper, et ça fait un peu guise de mea culpa de la part de l'ACM, mais peu de personnes peuvent se targuer d'avoir un prix à leur nom (même de façon posthume). Il y a aussi un Prix Hopper décerné « en interne » par la marine US pour les femmes qui ont des contributions majeures dans le numérique/l'informatique.

Concernant le côté tardif des remises de prix, honnêtement ça dépend aussi parfois de l'ère du temps. L'un des deux co-récipiendaires en 2025, Charles Sutton, récompensé pour ses travaux sur l'apprentissage renforcé (sur lequel il publie depuis les années 70, et qui a de vraies applications depuis longtemps), est bien plus vieux que Yann Le Cun (2015), récompensé pour son travail sur l'apprentissage profond de réseaux de neurones artificiels (et de mémoire, il a commencé à publier dessus vers 1989).

Enfin, concernant les progrès en compilation, il y a beaucoup de choses en ce qui concerne les compilateurs optimisants. La parallélisation automatique « générale » ne fonctionne pas (ou pas bien), ou bien est limitée au cas « triviaux » (sur des programmes qui respectent des propriétés facilement déterminées à la compilation). Je vais BEAUCOUP simplfier dans ce qui suit.

Modèle polyédrique

Par contre, il y a eu beaucoup de travaux sur l'optimisation et la parallélisation automatique de certains types de programmes, en particulier l'optimisation sur des nids de boucles imparfaits. Il s'agit d'optimisations reposant sur le modèle polyédrique. L'idée est que si des boucles imbriquées dans un programme respectent certaines propriétés bien spécifiques (notamment qu'on peut garantir le « sens » dans lequel les tableaux utilisés dans ces nids de boucles est « monotone », c'est-à-dire que l'accès est toujours croissant ou décroissant), alors il est possible de créer une représentation de l'espace d'itération de ces boucles sous forme de polyèdre, et les points qui le composent sont les points de l'espace d'itération. On peut ensuite « tordre » ce polyèdre pour changer l'ordre des boucles, dérouler certaines boucles, fusionner certaines instructions, etc., en fonction des contraintes d'optimisation voulues (taille du code, rapidité du programme, etc.).

Le modèle (et les premières implémentations semi-automatisées) a été proposé par Paul Fautrier dans les années 80. Il a co-écrit un article dans « Encyclopedia of Computer Science » qui résume l'approche. On peut trouver une version complète sur ResearchGate.

Il y a eu beaucoup de recherche en France, mais tout était très théorique, et quand c'était vraiment implémenté, c'était surtout des implémentations faites à la main pour montrer que les algos marchaient. Courant des années 2000, certaines implémentations dans des compilateurs (GCC avait une branche dédiée, mais qui a mis beaucoup de temps a être fusionné avec le tronc commun ; clang/llvm a eu des implémentations très rapidement). Ironiquement, pas mal de profs qui travaillent à Ohio State University ont fait leur postdoc dans des labos français fin des années 80/courant 90, et ont fait ce que les français n'ont pas su : ils ont implémenté le modèle polyédrique dans un compilateur dès le début des années 2000. Depuis, le modèle est disponible dans LLVM, et il me semble qu'il n'est plus nécessaire d'activer explicitement une option pour que ce soit utilisé.

Le modèle polyédrique permet non seulement l'optimisation du code concerné, mais aussi la parallélisation automatique lorsqu'il s'applique. Cependant, pour paraphraser Feautrier, « Malheureusement le modèle polyédrique ne s'applique qu'aux polyèdres. » Un programme qui fait des accès indirects à une liste ou un tableau (A[B[i]]) ne peut être optimisé grâce au modèle polyédrique, car le compilateur est a priori incapable de garantir la monotonie des accès au tableau A dans mon exemple. Il existe des compilateurs (commerciaux) qui proposent d'annoter le code pour donner les infos nécessaires aux compilateurs optimisants reposant sur le modèle polyédrique pour l'aider à savoir quand il est possible de l'utiliser.

Renouveau des langages fonctionnels pour exploiter le parallélisme

Parmi les autres choses que je peux voir, c'est qu'avec la généralisation du parallélisme dans les ordinateurs (à cause de la venue des processeurs multicœurs vers 2004, et leur généralisation vers la fin des années 2000), tout un tas de langages, notamment fonctionnels, ont vu leur utilisation augmenter, mais aussi la recherche liée aux langages fonctionnels a aussi repris du poil de la bête (au moins à l'époque). La raison étant que les langages fonctionnels ont tendance à moins s'appuyer sur un état global du programme, ce qui veut dire que lorsqu'on crée des tâches pour s'exécuter en parallèle sur un système multiprocesseurs/multicœurs, alors il y a moins de risques de conflits, car les zones mémoires partagées sont moins grandes et moins nombreuses.

LLVM en général

LLVM est à la base un projet de compilateur financé par la NSF aux US (début des années 2000). Bien qu'il y ait des contributions au domaine de la compilation qui en sont dérivés, le projet en lui-même était innovant en termes d'architecture logicielle (et de génie logiciel) : il s'agissait d'intégrer dans un même cadre toutes les techniques d'optimisation ayant un impact positif significatif, et de proposer une architecture modulaire permettant de facilement intégrer de nouvelles passes de compilation (il y a aussi eu pas mal de publications sur la représentation interne du graphe de représentation des programmes donnés en entrée à LLVM).

L'impact de LLVM sur la recherche en compilation est extrêmement important. En proposant un logiciel raisonnablement bien documenté, et très bien architecturé, cela a permis à beaucoup de gens (étudiant-e-s en info « éclairés », technicien-ne-s/ingénieur-e-s, et bien entendu chercheurs et chercheuses dont c'est le métier) d'explorer et d'expérimenter pour l'optimisation de code, là où franchement, avec GCC, c'était bien plus galère.

C'en est au point que les compilateurs d'Intel et Nvidia/PGI, et je crois aussi celui de Microsoft, sont tous basés sur LLVM (bien entendu il y a des histoires de licences aussi, mais pas que).

LLVM innove beaucoup grâce à son système de représentation intermédiaire. L'IR de base reprend les « bonnes pratiques » pour un compilo, mais est aussi super facilement extensible (toutes proportions gardées — on parle d'un compilateur quand même). Récemment (vers 2019 ?) il a été proposé MLIR, qui est une sorte de moyen de créer ses propres représentations intermédiaires dans LLVM, exprimées à partir de l'IR de LLVM. Ça permet de rajouter des opérations et opérateurs utiles pour certains domaines (par exemple, la prise en compte de tenseurs pour des programmes qui s'en servent, comme les logiciels générant des modèles d'apprentissage profond).

Je suis pas mal à la ramasse sur tout ce qui s'est passé depuis 10-15 ans, du peu que j'ai suivi, Fran Allen avait bien raison en 2007 : il y avait un gros bouillonnement lié à l'arrivée des multicœurs et manycores. :-)
Répondre
- [^] # Re: Prix Turing et Grace Hopper
  
  Posté par Ysabeau 🧶 (site web personnel, Mastodon) le 18 octobre 2025 à 15:53. Évalué à 5 (+3/-1). Dernière modification le 18 octobre 2025 à 16:49.
  
  Merci pour ce commentaire. Je ne suis pas très convaincue par les explications, précautionneuses, sur le prix Turing cela dit 🙂
  
  J'apprécie vraiment le topo sur l'évolution des compilateurs et de l'optimisation que je pense avoir à peu près compris. Sachant que les compilateurs sont quelque chose de très complexe, avec des langages de très haut niveau, j'imagine bien que c'est très très simplifié. Mais je pense que cela est une bonne base pour avoir envie d'en apprendre plus au besoin et pour savoir de quoi on parle le reste du temps.
  
  Et enfin, un grand merci pour enfin avoir répondu à cette question qui me turlupinait depuis 2020 sur les progrès des compilateurs à venir en 2007 après une phase de stagnation (ça ne m'a pas empêché de dormir, mais c'est bien de le savoir).
  
  Je n’ai aucun avis sur systemd
  
  Répondre
- [^] # Re: Prix Turing et Grace Hopper
  
  Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) le 19 octobre 2025 à 20:34. Évalué à 3 (+1/-0).
  
  Lire la partie dédiée à LLVM de votre commentaire m’évoque l’idée que le succès de ce compilateur est aussi lié à, si j’ai bien compris, une rare forme d’enshittification « pour la bonne cause : » la direction de gcc ne souhaitant pas adopter une architecture plus moderne qui aurait facilité les travaux et intégrations diverses. Comme quoi, mêmes causes mêmes effets, position dominante -> dégradations volontaires. Ce n’est pas réservé aux amis de Donald.
  
  « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
  
  Répondre
  - [^] # Re: Prix Turing et Grace Hopper
    
    Posté par Benoît Sibaud (site web personnel) le 20 octobre 2025 à 07:45. Évalué à 4 (+1/-0).
    
    une rare forme d’enshittification « pour la bonne cause
    
    Cela parait un peu abusif de qualifier ainsi un comportement assez passif, si j'ai bien suivi. Je ne qualifierai pas le vieillissement de merdification ou l'accumulation de la poussière : parce qu'il suffit de ne rien faire. Pour gcc ça semblerait plus à une sclérose, quelle que soit la raison (ou les raisons), entre manque de contributions, rétrocompatibilité, dette technique, gouvernance, feuille de route, priorités différentes, etc. À noter que llvm a aussi fait progresser gcc en réaction.
    
    Répondre
    - [^] # Re: Prix Turing et Grace Hopper
      
      Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) le 20 octobre 2025 à 08:11. Évalué à 2 (+0/-0).
      
      OK. Vous en savez sûrement plus long que moi sur le sujet. J'avais cru lire quelque part dans ces colonnes qu'il y avait eu refus explicite et répété de la part de la direction du projet pour les raisons évoquées ci-avant ? Mais j'aurais bien du mal à citer la moindre source, et le sujet sort totalement de mon domaine de compétences.
      
      « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
      
      Répondre
      - [^] # Re: Prix Turing et Grace Hopper
        
        Posté par pulkomandy (site web personnel, Mastodon) le 20 octobre 2025 à 08:30. Évalué à 6 (+3/-0).
        
        Le développement de llvm a accéléré surtout suite au passage de gcc à la license GPL version 3. Apple (gros utilisateur et contributeur historique de gcc) n'a pas validé l'utilisation de cette license pour l'intégration dans Mac OS, les clauses sur les brevets étant jugées trop contraignantes pour eux.
        
        Pour d'autres parties de leur système ils ont pu trouver un remplacement (par exemple, bash a été remplacé par zsh). Mais pour le compilateur, il n'y avait pas d'autre choix que llvm, projet peu connu à l'époque mais qui fournissait un point de départ acceptable.
        
        Ce n'est pas la peine de chercher une raison plus loin, même si les critiques sur gcc à l'époque (refus d'intégrer du C++ dans la base de code pour mieux la structurer, par exemple) peuvent être justifiées.
        
        Répondre
        
        [^] # Re: Prix Turing et Grace Hopper
        
        Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) le 20 octobre 2025 à 08:45. Évalué à 4 (+2/-0).
        
        « Le développement de llvm a accéléré surtout suite au passage de gcc à la license GPL version 3. Apple (gros utilisateur et contributeur historique de gcc) n'a pas validé l'utilisation de cette license pour l'intégration dans Mac OS, les clauses sur les brevets étant jugées trop contraignantes pour eux. »
        
        Histoire d'être certains qu'il n'y ait pas de quiproquo, ce que mon commentaire qualifie --- peut-être à tort --- d''enshittification de gcc ce n'est assurément pas le passage à la GPL v3 ; bien au contraire. Que le libre fasse hurler et fuir les acteurs principaux et acharnés de ce phénomène, comme la lumière les vampires, est tout sauf un corollaire inattendu.
        
        « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
        
        Répondre
        
        [^] # Re: Prix Turing et Grace Hopper
        
        Posté par BAud (site web personnel) le 22 octobre 2025 à 13:13. Évalué à 3 (+1/-0).
        
        ce que mon commentaire qualifie --- peut-être à tort --- d''enshittification de gcc
        
        ce à quoi on te répond qu'il n'y en a pas — contrairement à ce que tu affirmes — de merdification : il y a au contraire une volonté de gérer la dette technique (avec ses limites, mauvaise volonté parfois, trop d'impacts, structure de greffons rajoutée en surcouche et non pensée dès le début : qui aurait pensé ajouter cobol, fortran, ada au début à gcc, déjà c++ semblait cohérent…).
        
        LLVM a permis de redonner une dynamique et c'est une émulation saine (autant avoir plusieurs compilateurs multi-plateformes : arm, mips, risc-v, x86…)
        
        Répondre
        
        [^] # Re: Prix Turing et Grace Hopper
        
        Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) le 22 octobre 2025 à 17:25. Évalué à 2 (+0/-0).
        
        Ce à quoi on me répond aussi :
        
        « Absolument. Dans le cas de GCC, certaines branches dont les fonctionnalités avaient été correctement débuggées et validées par leurs développeurs avaient été mises de côté pendant un très long moment. Et quand les mêmes ont été développées dans Clang/LLVM, l'équipe de devs de GCC a accéléré l'intégration de fonctionnalités qui étaient en attente de merge depuis un moment. »
        
        « C'est directement du à Stallman qui voulait volontairement conserver cet aspect obscur afin de permettre la viralité du code gpl. »
        
        « LLVM a permis de redonner une dynamique et c'est une émulation saine (autant avoir plusieurs compilateurs multi-plateformes : arm, mips, risc-v, x86…) »
        
        Là dessus aussi nous sommes bien d'accord :-).
        
        « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
        
        Répondre
        
        [^] # Re: Prix Turing et Grace Hopper
        
        Posté par lasher le 20 octobre 2025 à 10:56. Évalué à 6 (+4/-0).
        
        Absolument. Dans le cas de GCC, certaines branches dont les fonctionnalités avaient été correctement débuggées et validées par leurs développeurs avaient été mises de côté pendant un très long moment. Et quand les mêmes ont été développées dans Clang/LLVM, l'équipe de devs de GCC a accéléré l'intégration de fonctionnalités qui étaient en attente de merge depuis un moment.
        
        Je trouve cependant assez parlant que GCC ne se soit officiellement équipé d'un système de plugins que depuis 2016, là où LLVM dispose de cela depuis presque le début¹. Certes, une partie est due à de la dette technique, mais il me semble aussi beaucoup à un certain conservatisme de la part des mainteneurs de GCC.
        
        J'exagère bien entendu, mais pas tant que ça. La modularité est au cœur du développement de LLVM. ↩
        
        Répondre
  - [^] # Re: Prix Turing et Grace Hopper
    
    Posté par octane le 20 octobre 2025 à 12:31. Évalué à 3 (+2/-1).
    
    la direction de gcc ne souhaitant pas adopter une architecture plus moderne qui aurait facilité les travaux et intégrations diverses.
    
    C'est directement du à Stallman qui voulait volontairement conserver cet aspect obscur afin de permettre la viralité du code gpl. Un compilo plus simple à comprendre aurait permis de découper bibliothèques et programmes, ce qu'il ne voulait pas car cela aurait permis des bibliothèques non libres dans des programmes libres.
    
    Il ne s'agit pas d'enshitification, mais de frein à la rétroingénierie pour permettre la diffusion de code GPL.
    
    Et forcément j'avais un super article qui en parlait mais je ne met plus la main dessus, c'est google qui s'enshittifie :-(
    
    Répondre
    - [^] # Re: Prix Turing et Grace Hopper
      
      Posté par pulkomandy (site web personnel, Mastodon) le 20 octobre 2025 à 14:36. Évalué à 5 (+2/-0).
      
      Ces histoires remontent assez loin, en fait la question s'est posée pour le frontend Objective-C de gcc avant 1992, avec une explication de Stallman lui-même ici:
      
      https://github.com/JoshCheek/clisp/blob/master/doc/Why-CLISP-is-under-GPL#L360
      
      Mais je ne sais pas à quel point cela était toujours dans la culture de gcc par la suite. Il y avait déjà eu une "crise" à l'époque du passage de gcc2 à gcc3 avec le projet EGCS (c'est donc vers 1996-1998), un fork de gcc avec une gouvernance plus ouverte, qui a fini par devenir le gcc "officiel".
      
      Répondre
      - [^] # Re: Prix Turing et Grace Hopper
        
        Posté par Philippe F (site web personnel) le 22 octobre 2025 à 09:29. Évalué à 3 (+1/-0). Dernière modification le 22 octobre 2025 à 09:29.
        
        Je me souviens des deux évènements.
        
        Malgré tout le respect qu'on doit à GCC et à Stallman pour avoir démarré ce projet brillant, c'est un projet qui a aussi ses imperfections. M. Stallman n'est pas exempt crises d'égo notamment (arf).
        
        Quand on pense qu'en 2025, il n'a toujours pas digéré que Linux marche mieux que GNU Hurd…
        
        Répondre
        
        [^] # Re: Prix Turing et Grace Hopper
        
        Posté par Faya le 22 octobre 2025 à 14:32. Évalué à 3 (+1/-0).
        
        Quand on pense qu'en 2025, il n'a toujours pas digéré que Linux marche mieux que GNU Hurd…
        
        Digéré je ne sais pas, mais même lui a conscience que Linux marche mieux vu que c'est ce qu'il utilise : « As of 2022 I use a Thinkpad x200 computer, which has a free initialization program (Libreboot) and a free operating system (Trisquel GNU/Linux). »
        
        Répondre