Cessez de concevoir des langages, écrivez plutôt des bibliothèques

• Le cœur de la productivité en programmation réside moins dans le langage lui-même que dans un riche écosystème de bibliothèques
• Des frameworks qui exploitent les fonctionnalités avancées du langage, comme Ruby on Rails, offrent une forte productivité même aux non-spécialistes
• Cependant, en raison des limites structurelles du langage, il est difficile d’implémenter un framework du niveau de Rails en Java ou en C
• La conception d’un langage détermine directement la forme et la complexité des bibliothèques qu’il est possible d’écrire, et c’est là l’objectif fondamental de l’évolution des langages
• Le langage Stanza illustre, sous cet angle, l’importance d’une conception de langage qui permette de créer des bibliothèques puissantes et faciles à utiliser

---

Relation entre langages de programmation et bibliothèques

• La plupart des langages de programmation partagent des éléments de base similaires, comme les variables, les tableaux, les boucles et les fonctions
  • Certains langages proposent des fonctionnalités avancées comme les fonctions de première classe ou les coroutines, mais les non-spécialistes les utilisent rarement
• Pour de nombreux développeurs, ce qui améliore la productivité, ce sont les bibliothèques plus que le langage
  • Par exemple, Ruby on Rails permet de construire facilement des applications web adossées à une base de données
  • Grâce à Rails, la préférence va davantage au framework qu’au langage Ruby lui-même

Interaction entre Ruby on Rails et les fonctionnalités du langage

• Rails exploite diverses fonctionnalités de Ruby, notamment la métaprogrammation, l’évaluation à l’exécution, les fonctions de première classe et le ramasse-miettes
  • Exemple : ActiveRecords utilise la métaprogrammation, tandis que le système de templates utilise l’évaluation à l’exécution
  • La gestion des événements est implémentée en transmettant des fonctions de première classe comme callbacks
• En Java ou en C, ces fonctionnalités font défaut, ce qui rend impossible l’implémentation d’un framework du niveau de Rails
  • La métaprogrammation de Java n’est pas assez puissante pour implémenter ActiveRecords
• Rails est donc possible grâce à la structure du langage Ruby, et la conception du langage détermine les possibilités offertes aux bibliothèques

La conception du langage détermine la forme des bibliothèques

• Le langage C ne prend en charge la réutilisation qu’au moyen de la déclaration et de l’appel de fonctions ; la plupart des bibliothèques C prennent donc la forme d’ensembles de fonctions
• Ruby prend en charge les fonctions de première classe, ce qui permet d’exprimer de façon concise « l’action à exécuter lors d’un clic sur un bouton »
  • En Java, à l’inverse, il faut définir une classe de gestionnaire, ce qui complexifie le code
• Le pouvoir d’expression d’un langage définit directement la structure et l’utilisabilité des bibliothèques

Logiciels interactifs et émergence de frameworks extensibles

• Dans l’informatique par lots des années 1970, des bibliothèques centrées sur les fonctions suffisaient
• Les logiciels interactifs modernes nécessitent des bibliothèques extensibles
  • Dans les GUI ou les systèmes orientés événements, il faut une structure du type « exécuter mon code quand l’utilisateur clique »
• Java et C++ prennent en charge l’extension via l’héritage et la redéfinition de méthodes, et cette structure a évolué en framework

Contexte de conception de Stanza et limites des langages

• La motivation de la conception de Stanza est née de la difficulté à écrire en Java une bibliothèque de programmation de jeux facile à utiliser
  • En Java, il fallait exprimer la concurrence sous forme de machine à états (state machine)
  • Scheme prend en charge les continuations, ce qui permet une implémentation plus intuitive
• Cependant, Scheme ne prend pas en charge la vérification statique des types, ce qui réduit l’efficacité du débogage
  • À l’heure actuelle, la plupart des langages ne permettent pas d’étendre leur système de types sous forme de bibliothèque
• Stanza propose un système de types optionnel, un ramasse-miettes et un système objet fondé sur les multiméthodes
  • Mais il n’est pas possible d’écrire de zéro un nouveau système objet défini par l’utilisateur

Finalité des langages et pistes de recherche

• L’objectif d’un langage de programmation généraliste est de permettre la création de bibliothèques puissantes et faciles à utiliser
  • Plus un langage est puissant, plus l’usage des bibliothèques devient concis
• Lorsqu’un code utilise une bibliothèque bien conçue, il possède un naturel qui donne l’impression de lire une phrase adressée à un collègue
• Racket, Shen et les recherches sur les protocoles méta-objets explorent des systèmes de types et d’objets extensibles
• En fin de compte, les langages se distinguent par « quelles bibliothèques ils permettent d’utiliser, et lesquelles ils ne permettent pas »
• Derrière les bibliothèques élégantes se trouvent des décennies de recherche et d’efforts de conception sur les langages

[GN⁺]

Commentaires sur Hacker News

• Le meilleur exemple, c’est Prolog. On le présente souvent comme le langage emblématique de la programmation logique, mais en réalité ce n’est guère plus qu’un ensemble d’algorithmes, qui pourraient être implémentés comme bibliothèque dans divers langages. Il suffirait, à mon avis, de fournir l’expression syntaxique de Prolog adaptée à la grammaire de chaque langage

  • Le cœur de Prolog, ce ne sont pas les algorithmes, mais la manière de déclarer des règles logiques de façon déclarative. Par exemple, si l’on définit la règle « un grand-parent est le parent d’un parent », on peut ensuite s’en servir pour trouver les grands-parents ou, à l’inverse, inférer des relations de parenté. Cette inférence bidirectionnelle fait tout l’intérêt de Prolog. Bien sûr, pour imiter ce genre de fonctionnalités dans un langage généraliste, il faut du code sans effets de bord et un DSL limité. Comme avec PyTorch ou TensorFlow qui exécutent CUDA depuis Python, les appels inter-langages sont aussi possibles, donc une architecture indépendante du langage me paraît tout à fait envisageable
  • La syntaxe de Prolog est un sous-ensemble de la logique du premier ordre (First Order Logic), où les variables ne reçoivent pas de valeur fixe mais sont explorées sur un ensemble de valeurs possibles jusqu’à satisfaire les contraintes. Le moteur Prolog fait bien plus qu’un simple appel de bibliothèque — par exemple représentation compressée de l’espace de recherche, exécution parallèle et élagage automatique. C’est pourquoi on l’intègre souvent sous forme de service backend ou par génération de code. Prolog est particulièrement puissant pour la planification, la résolution de contraintes, la démonstration de théorèmes, les tests combinatoires et la modélisation tarifaire. Du coup, le considérer comme un simple « langage qu’une bibliothèque suffit à remplacer » me paraît exagéré
  • En suivant la même logique, on pourrait dire que les fonctionnalités orientées objet sont elles aussi superflues dans un langage, puisqu’on peut les imiter avec des closures. Pourtant, il y a un vrai avantage à la puissance d’expression qu’apporte une syntaxe claire
  • Pour implémenter en bibliothèque une programmation relationnelle à la Prolog, il faut qu’un langage prenne en charge la manipulation des symboles et des variables comme objets de premier ordre. Les langages de la famille Lisp s’en approchent un peu, mais dans un langage généraliste l’ergonomie se dégrade fortement. Quand j’en ai parlé avec Bob Harper, il m’a répondu : « fais simplement un nouveau langage ». Et, honnêtement, c’était assez convaincant
  • J’aimerais apprendre Prolog, mais il est difficile de trouver des ressources de niveau intermédiaire entre les tutoriels d’introduction et les exemples avancés. J’essaie de résoudre des variantes de Sudoku en Prolog, mais les exemples existants sont tellement optimisés qu’il est difficile d’y apprendre à définir des relations généralisées. Je me demande surtout comment modéliser des situations où certaines règles peuvent être fausses. À titre de référence, je regarde l’exemple Sudoku de SWI-Prolog

• Il y a dix ans, j’étais fan de Scala. Le concept de « Scalable Language », qui permet de construire des DSL dans le système de types, me séduisait beaucoup. Mais j’ai perdu l’intérêt quand la communauté s’est mise à l’utiliser comme une sorte de Haskell sur la JVM. Aujourd’hui, j’attends avec intérêt des technologies comme WASM ou Graal, qui pourraient rendre le choix du langage plus flexible. Souvent, JS suffit, mais c’est bien d’avoir l’option d’un langage plus bas niveau comme Rust quand c’est nécessaire

  • Je pense aussi que le plus gros problème de Scala, c’est l’abus de DSL. Non seulement il faut apprendre le langage lui-même, mais on a parfois l’impression de devoir en apprendre un autre dans les frameworks de test et ailleurs. Certes, pouvoir exprimer un Hadoop MapReduce en une ligne est impressionnant, mais pour la plupart des usages c’est excessif. Et puis les développeurs Scala n’aiment pas écrire du « code ennuyeux ». J’ai souvent vu des gens partir en laissant derrière eux un enfer de maintenance à force d’avoir voulu être trop brillants
  • Toute la communauté Scala n’est pas orientée Haskell. Ce n’est qu’une partie des sorciers du typage qui a cette tendance. Scala reste excellent même utilisé simplement comme un « meilleur Java ». On peut profiter des atouts du fonctionnel sans trop de friction
  • Haskell est à l’origine souvent utilisé comme langage de création de DSL. Haxl chez Meta ou TidalCycles pour la musique en sont de bons exemples. En revanche, les bibliothèques basées sur des types d’ordre supérieur souffrent de fortes pertes de performance et d’une complexité souvent inutile
  • As-tu déjà essayé Clojure(Script) ? Fidèle à la tradition Lisp, il permet un bottom-up programming où l’on étend le langage en fonction du problème. Paul Graham insiste sur cette approche dans On Lisp. Je recommande aussi la conférence Bottom Up vs Top Down Design in Clojure
  • J’ai commencé à apprendre Scala récemment, et je l’apprécie vraiment aussi du point de vue de la programmation fonctionnelle. Je le trouve assez généraliste pour bien d’autres usages que la création de DSL. Je serais curieux de savoir ce qui te semble lui manquer

• J’aimerais bien pouvoir remplacer bash par un langage de script typé. J’ai écrit un petit parseur JSON en Elixir, et c’était plutôt agréable

  • Tu as essayé Nushell ? Il permet de faire en une ligne des choses pour lesquelles il fallait autrefois un « vrai langage ». Par exemple, on peut écrire très simplement un pipeline qui trie une liste de fichiers et la sort en JSON
  • En réalité, avec un shebang, on peut écrire des scripts dans plein de langages. C’est possible, par exemple, avec C#, Java et Go. Avec Scriptisto, on peut même faire des scripts shebang dans presque n’importe quel langage
  • OCaml peut aussi s’utiliser comme un langage de script. On peut l’exécuter directement avec #!/usr/bin/env ocaml. En revanche, il n’y a pas de mécanisme pour installer automatiquement les dépendances externes dans un fichier unique
  • Il existe aussi une astuce pour imiter un shebang en Go. Voir aussi la discussion ici
  • Pour le scripting quotidien, Python ou PowerShell sont aussi de bons choix

• Langages et bibliothèques ne sont pas mutuellement exclusifs. Certaines bibliothèques se comportent pratiquement comme des langages, et inversement certains langages sont conçus pour une bibliothèque précise. Julia, par exemple, illustre bien l’équilibre entre performance et ergonomie. On peut écrire directement du code haute performance en Julia et obtenir une exécution optimisée grâce à une compilation spécialisée par types au niveau JIT. Le modèle apparent reste un simple appel de fonctions, mais en interne c’est extrêmement sophistiqué

  • Oui, au fond l’idée centrale était bien que langages et bibliothèques sont tous deux nécessaires

• Raku est conçu comme une structure qui assemble plusieurs sous-langages (slangs). Par exemple, les expressions régulières, PEG, le quoting, etc., y sont traités comme des mini-langages distincts, et avec Slangify on peut facilement ajouter son propre DSL

  • Mais personnellement, je n’aime pas la syntaxe où le type vient après le nom de variable, donc je ne suis pas fan de Raku

• Un développeur senior m’avait dit un jour : « si je vois Rails sur un CV, je le jette directement ». Ça m’a rappelé à quel point juger les gens à partir d’un langage est absurde

  • La montée de Rails et le déclin de J2EE en même temps n’ont rien d’un hasard. Rails a montré ce que pouvait être un code backend simple et assumé, et cela a influencé l’apparition de frameworks Java comme DropWizard, Javalin ou Spring Boot
  • Je serais curieux de connaître la stack technique de ce senior
  • J’aimerais presque récupérer ce qu’un collègue comme ça jette à la poubelle. Les bons développeurs Rails sont difficiles à trouver. J’ai moi-même de l’expérience en RoR et j’aime toujours ça
  • Bien sûr, si l’on recrute des développeurs Java, filtrer les CV Rails peut aussi être efficace
  • Les critères d’évaluation dépendent au fond de la compatibilité culturelle avec l’organisation et du style de collaboration. Il n’existe pas de méthode de filtrage parfaite

• Langage ou bibliothèque, au fond ce sont surtout des moyens de communication avec la machine comme avec les humains. La machine comprend les bits et les tensions ; les humains, eux, comprennent des intentions et des concepts. Donc si un langage ou une bibliothèque offre aux humains un moyen clair et rapide d’exprimer cela, peu importe qu’on l’appelle langage ou bibliothèque. Rails ou Stanza, si c’est adapté au but et compréhensible pour l’équipe, alors c’est le bon choix

• Pour moi, « la bibliothèque est le langage final ». Ruby on Rails, par exemple, est un excellent langage de services web bâti sur Ruby. Ruby et Rails ont évolué l’un pour l’autre. Au fond, programmer n’est qu’un processus continu de traduction entre langages

  • C# et ASP.NET Core ont évolué de manière comparable, avec à la fois une syntaxe conviviale et des optimisations au niveau système

• L’idée selon laquelle « plus un langage est puissant, plus il est facile d’utiliser des bibliothèques » me paraît juste. Dans l’ancien Java, il était difficile de créer un framework du type Express

  • Je ne sais pas ce qu’est Express, mais je pense que Java s’est imposé comme langage d’entreprise grâce à sa capacité à exploiter les bibliothèques
  • Les minimal API d’ASP.NET Core sont presque une réplique d’Express. C’est le genre de chose qui n’est possible que lorsque langage et framework progressent ensemble
  • En Java aussi, il existe des frameworks proches d’Express comme Javalin. Le problème, c’est que la communauté ne veut pas de simplicité

• Si l’on cherche un framework web pour le langage C, il y a toujours PHP, non ? ;)

  • Là, on est dans une blague qui pousse un peu trop loin la notion de bibliothèque