Pourquoi j’ai choisi Common Lisp

Au revoir, Clojure

• J’ai utilisé Clojure pendant environ 7 ans, mais je n’en étais plus satisfait à cause du problème de « démarrage lent » des applications CLI
• Il existait des projets comme babashka, mais il était difficile de résoudre ce problème de démarrage lent, même avec native-image de GraalVM
• Un « démarrage rapide d’un exécutable autonome » est devenu une exigence indispensable, et j’ai conclu que Clojure ne pouvait pas y répondre

À la recherche d’un nouveau Lisp

• J’ai étudié plusieurs langages pour trouver un nouveau langage Lisp, en cherchant une solution aux problèmes rencontrés dans mes projets précédents
• Il n’y avait pas d’« exigences explicites », mais j’ai fini par formaliser les critères suivants
  • Il devait être possible de générer des « exécutables autonomes qui démarrent rapidement » avec une toolchain raisonnable (pour résoudre mon principal grief avec Clojure)
  • Comme je ne peux pas utiliser Emacs, il fallait que cela fonctionne avec Vim
  • La prise en charge de Windows et Mac était indispensable ; le support limité à Linux/POSIX ne suffisait pas
  • La possibilité de s’intégrer à d’autres grands langages de communauté, comme Clojure et Java, était un plus
  • Les performances à l’exécution devaient être suffisamment rapides (idéalement au moins au niveau de Clojure)
  • Le support du multithreading devait être solide, et si possible sans GIL (Global Interpreter Lock)
  • Une communauté forte était indispensable
  • Il fallait un écosystème riche, avec au minimum les bibliothèques suivantes
    • Parsing et sérialisation JSON
    • Support de Sqlite3
    • Bibliothèque de requêtes HTTP
    • Support de structures de données fonctionnelles comme en Clojure (même si ce point était moins important)
• Langages étudiés
  • Scheme : entre r6rs et r7rs, la communauté semblait fragmentée par les questions de standardisation, ce qui ne m’attirait pas, et l’écosystème était trop limité pour répondre à mes besoins
  • Racket : je l’avais utilisé à l’époque de mes études, mais son runtime me paraissait lent et lourd, donc je ne le préférais pas
  • Common Lisp : découvert sur lisp-lang.org. La communauté et les ressources m’ont impressionné, et j’ai décidé d’essayer

Magic Happens Here

• Je passe sur toute l’histoire de mon apprentissage de Common Lisp, mais le parcours a été difficile
  • Le départ s’est mal passé. J’ai reçu le livre CLtLv2 à Noël et j’ai commencé en le lisant
  • Ensuite, j’ai découvert le HyperSpec, et l’apprentissage a pris une meilleure direction à partir de là
• Common Lisp avait des caractéristiques vraiment particulières
  • C’est un langage standardisé, plus proche de C que de Java sur ce point
  • Plusieurs compilateurs, interpréteurs et runtimes implémentent le standard
  • Il existe des outils comme Roswell pour installer et gérer différentes implémentations
  • Dans la communauté, SBCL est généralement considéré comme l’implémentation la plus populaire
• Et si j’avais connu Janet au moment où j’ai commencé mes recherches ?
  • Janet possède les caractéristiques suivantes, et il est possible qu’il m’aurait satisfait avant que j’apprenne Common Lisp
  • Syntaxe concise, exécutable rapide et léger, prise en charge du C FFI
  • Il existe un guide d’introduction amusant
  • Il répondait à toutes les exigences que je considérais importantes
• Mais pourquoi avoir choisi Common Lisp ?
  • J’aurais raté des fonctionnalités avancées comme CLOS et le Condition System, que je n’ai découvertes que plus tard
  • Common Lisp est un langage plus puissant

Exigences remplies

Après avoir confirmé que Common Lisp répondait à mes exigences, je l’ai choisi comme mon prochain langage Lisp et je l’utilise encore aujourd’hui. Voici les principaux constats :

• Exécutables autonomes :
  • Il existe plusieurs façons de créer des exécutables autonomes en Common Lisp
  • Selon qu’ils soient compressés ou non, leur temps de démarrage peut aller d’une fraction de seconde à un lancement presque instantané
  • Cette capacité n’est pas une option accessoire, mais une méthode centrale prévue pour déployer des programmes Lisp
• Workflow Vim :
  • Il existe plusieurs excellentes options, mais personnellement j’ai construit mon propre workflow Vim
  • J’ai également constaté que VS Code était tout à fait correct comme IDE Common Lisp
• Support Windows/Mac/Linux :
  • SBCL prend bien en charge les principaux systèmes d’exploitation
• Intégration avec de grands écosystèmes impératifs :
  • La plupart des implémentations prennent bien en charge l’intégration avec le langage C, exploitable via CFFI
• Performances à l’exécution :
  • SBCL est très rapide à l’exécution
• Multithreading :
  • Le standard Common Lisp n’inclut pas de support explicite du multithreading, mais les principales implémentations le prennent en charge
  • Une bibliothèque appelée Bordeaux-Threads réduit les différences entre implémentations
  • Des bibliothèques comme lparallel, cl-async et blackbird permettent le multithreading et la programmation asynchrone
• Communauté forte :
  • J’ai découvert l’activité de la communauté et j’y ai participé
  • Les résultats de l’enquête communautaire de 2024 et le European Lisp Symposium montrent l’activité soutenue de la communauté Common Lisp
  • Le réseau de blogs et le subreddit offrent également un fort soutien communautaire
• Écosystème :
  • La plupart utilisent Quicklisp, mais personnellement je gère mes paquets avec OCICL
  • On peut explorer les bibliothèques et les informations techniques via Common Lisp Cookbook, CLiki, Awesome CL, etc.
  • Prise en charge de bibliothèques spécifiques :
    • JSON : jzon
    • Sqlite3 : cl-sqlite
    • Requêtes HTTP : dexador
    • Structures de données fonctionnelles : FSet, cl-hamt

Quelques remarques pour les nouveaux venus

• Comme il y a de plus en plus de débutants sur le Discord Common Lisp, j’ai écrit ceci pour partager la manière dont j’ai choisi Common Lisp et m’y suis adapté
• J’espère que cet article aidera celles et ceux qui s’intéressent à Common Lisp

[GN⁺]

Avis Hacker News

• L’expérience de résolution d’un problème avec SBCL, même sans code source, a été marquante. Avec une autre stack technologique, il n’aurait probablement pas été possible de corriger aussi vite sans le code source

  • SBCL est un système très dynamique, et il a été possible de résoudre le problème via le REPL même sans code source

• Partage d’une expérience de transition de Common Lisp vers Clojure, en soulignant l’attrait des fonctionnalités de concurrence de Clojure

  • babashka a été utile pour écrire rapidement des scripts

• L’utilisation de vim-slime a fortement amélioré la productivité et la satisfaction du développeur

  • La possibilité d’utiliser un REPL avec divers langages est utile
  • doom-emacs, similaire à Vim, a également permis d’améliorer la productivité

• Sans vraiment comprendre la valeur de Lisp, quelqu’un dit se souvenir d’une chanson à son sujet

• Affirmation que Emacs/slime est un meilleur IDE Lisp que vim-slime

  • Il a été possible de résoudre des problèmes de RSI en modifiant les raccourcis clavier dans Emacs

• Quelqu’un utilise Common Lisp comme hobby et souhaite exécuter du code C# dans le REPL de SBCL

  • La boucle de feedback est très rapide, ce qui permet de résoudre les problèmes immédiatement

• Partage d’une expérience de développement d’applications CLI avec Clojure et babashka

  • La bibliothèque methodical a permis d’améliorer les performances

• Des problèmes ont été rencontrés avec native-image, mais Clojure est considéré comme un langage presque parfait

• Expression d’un intérêt pour le langage Janet, avec mention de l’utilité du README GitHub et de la FAQ du projet

• Partage d’une expérience qui a donné envie d’apprendre Lisp, en trouvant particulièrement attirant le fait que l’auteur soit fan de Vim

[gurugio]

Je n’ai pas compris la valeur de Lisp, mais je me souviens d’une chanson associée... Il y a beaucoup de chansons sur Lisp, et il y en a une sur YouTube qui s’appelle Land of Lisp ;-)