Je programme depuis l’âge de sept ans et au cours de ma vie, j’ai eu
l’occasion et la curiosité d’essayer et d’utiliser de nombreux langages de
programmation. Mais parmi les langages que je connais, le Lisp est celui qui a
de loin le plus bousculé ma vision de la discipline.
J’ai découvert le Lisp de manière complètement fortuite il y a deux ans. Je
cherchais en fait un outil de mind-mapping et j’étais alors tombé sur Org mode
couplé à Spacemacs, lui-même une surcouche pour GNU Emacs.
De fil en aiguille, Emacs m’a fait découvrir Emacs Lisp. À partir de là, j’ai
fini par adopter Common Lisp et dans une moindre mesure Clojure, en essayant au
passage Haskell (qui n’est certes pas un Lisp, mais semble faire partie de la
famille en tant que membre d’honneur). Mais ma dernière découverte, et de loin
la plus étonnante, est le langage Racket, que j’étudie actuellement.
Au cours de ces différents essais de langages, ma bien-aimée a essayé et adopté
Common Lisp plutôt que le C pour une idée de jeu qu’elle avait depuis plus de
dix ans et j’ai aussi fait des prototypes de générateurs de texte à base de
chaînes de Markov et un solveur de picross.
La famille Lisp
Le Lisp d’origine date de la fin des années 1950, ce qui fait de la famille
des Lisp une des plus anciennes qui existent.
Il est difficile d’illustrer ce qui m’attire dans les Lisp sans donner au
moins un exemple de code. En voici un, exprimé en Common Lisp, qui calcule
la factorielle d’un nombre n en utilisant une fonction auxiliaire f et
une récursion terminale :
(defun factorial (n)
"Calcule la factorielle du nombre N."
(flet ((f (acc n)
(if (<= n 1)
acc
(f (* acc n) (1- n)))))
(f 1 n)))
Je déclare ici une fonction factorial, acceptant un seul paramètre nommé
n, accompagné d’une petite description destinée à un système de génération
documentaire. J’y introduis une fonction auxiliaire f prenant en paramètre
un résultat pratiel acc (pour « accumulateur ») et le nombre dont on calcule
la factorielle, toujours appelée n.
Dans cette fonction auxiliaire, si n est inférieur ou égal à 1, le calcul
est terminé et on renvoie acc. Sinon, on appelle f récursivement. Avec
cette fonction auxiliaire définie, il ne reste plus qu’à l’appeler avec 1 et
n comme paramètres pour calculer le résultat.
Ce qui saute immédiatement aux yeux sont la quantité de parenthèses. Il s’agit
en fait de la représentation canonique de listes, qui sont délimitées par
des parenthèses et dont chaque élément est séparé par un blanc. On dit aussi
que ces listes sont représentées sous la forme de S-expressions.
Ainsi, (f (* acc n) (1- n)) est une liste dont les éléments sont, dans
l’ordre, le symbole f, la liste (* acc n) et la liste (1- n). Et puisque
chaque élément d’une liste peut aussi être une liste, on peut utiliser ces
listes pour construire un arbre syntaxique d’un programme.
Voilà donc une des différences fondamentales entre le Lisp et les autres
langages de programmation : en Lisp, le code source est une représentation
explicite de son arbre syntaxique, alors que dans les autres langages, cet
arbre, généralement construit et manipulé dans le compilateur
uniquement, est inaccessible de l'extérieur.
Voici un second exemple en Common Lisp qui affiche une liste de courses :
(defun courses (ingredients)
"Affiche une liste de courses."
(if (null ingredients)
(princ "Je n’ai rien à acheter")
(progn
(format t "J’ai ~D ~A à acheter : "
(length ingredients)
(if (> (length ingredients) 1) "choses" "chose"))
(labels ((p (ingredients)
(format t "~(~A~)" (first ingredients))
(case (length ingredients)
(1 (princ "."))
(2 (princ " et ") (p (rest ingredients)))
(otherwise (princ ", ") (p (rest ingredients))))))
(p ingredients))))
(fresh-line))
(Note aux connaisseurs : je sais que j’aurais pu me contenter d’un unique
appel à la fonction format pour afficher cette liste, mais la chaîne de
format deviendrait très vite absconse.)
Appeler cette fonction depuis du code nécessite cependant d’utiliser un
opérateur spécial, quote, pour indiquer une donnée à utiliser telle quelle :
un symbole qui ne désigne pas une variable ou une liste qui n’est pas un appel
de fonction. Ici, il faut que la liste de courses soit traitée comme une liste
au lieu d’un un appel de fonction (notez l’apostrophe devant chaque liste, qui
est la forme abrégée de quote), comme ceci :
* (courses '())
Je n’ai rien à acheter
* (courses '(œufs))
J’ai 1 chose à acheter : œufs.
* (courses '(œufs chocolat))
J’ai 2 choses à acheter : œufs et chocolat.
* (courses '(œufs chocolat sucre farine))
J’ai 4 choses à acheter : œufs, chocolat, sucre et farine.
Le fait qu’un programme Lisp soit représenté à l’aide de sa propre
représentation de listes et d’arbres est aussi appelé homoiconicité. Cette
propriété, partagée par très peu de langages de programmation, rend ainsi
trivial la génération de code. Par conséquent, Lisp bénéficie d’un système de
macros parmi les plus puissants de tous des langages de programmation.
Emacs et Emacs Lisp : ma première expérience de Lisp
J’avais déjà utilisé un peu Emacs quand j’étais en école d’ingénieurs, mais je
ne me voyais pas m’en servir autrement qu’après avoir tapé M-x viper-mode
car j’avais beaucoup trop l’habitude des touches de vi. Spacemacs me retirait
une grosse épine du pied en proposant un Emacs « vimifié » ; j’étais donc prêt
à me refaire une nouvelle première impression. Et j’allais avoir une semaine
de vacances devant moi pendant lesquelles j’aurais suffisamment de temps pour
explorer sérieusement Emacs.
Je me souviens donc bien comment je m’étais installé dehors, un après-midi,
avec mon PC portable sur les genoux, pour lire le manuel d’Emacs Lisp.
Les extensions d’Emacs, mais aussi une grosse partie de l’éditeur lui-même,
sont codés en Emacs Lisp. Ce langage est un dérivé d’un dialecte assez ancien
de Lisp, Maclisp, qui date des années 1960. Ce qui explique certains de ses
pièges, comme le fait que les variables aient par défaut une portée dynamique
plutôt que lexicale (ce qui est cependant en train de lentement changer). La
quantité de code Emacs Lisp qui circule de nos jours signifie que tout
changement majeur, comme une forme de programmation concurrente, doit être
introduite en procédant à tâtons pour éviter de casser le code existant.
Pour cette raison, les détracteurs disant qu’Emacs a davantage les
fonctionnalités d’un système d’exploitation que ceux d’un éditeur de texte ont
à mon avis partiellement raison. Emacs est en effet un interpréteur Lisp doté
de fonctions conçues pour éditer du texte, mais il est capable de bien plus
que ça. Autrement dit, Emacs est une machine Lisp moderne.
J’utilise maintenant énormément Org-mode au travail et je me suis fait
quelques petits scripts en Emacs Lisp pour automatiser certaines tâches
administratives fastidieuses. Étant contraint à Windows au bureau, système sur
lequel Emacs a été porté, j’apprécie beaucoup cet accès facile à un Lisp tout
à fait honorable. Et en parallèle, je suis devenu encore plus frustré par les
outils informatiques dépourvus du moindre mécanisme d’extension.
Toujours est-il que l’omniprésence d’Emacs Lisp dans Emacs font de cet éditeur
un des meilleurs outils pour programmer non seulement en Emacs Lisp, mais dans
n’importe quel Lisp de manière générale.
Common Lisp : l’héritier des Lisp traditionnels
Le Common Lisp a été l’étape suivante dans mon aventure. Mon tutoriel a été
le livre Practical Common Lisp de Peter Seibel, qu’on peut lire
gratuitement en ligne ou acheter en version papier. Et quand on code, le
Common Lisp HyperSpec est accessible en ligne et constitue le manuel de
référence du langage.
Ce langage est le fruit d’un effort de standardisation d’un Lisp remontant aux
années 1980. Ces efforts ont abouti à une norme ANSI publiée en 1994 et restée
inchangée depuis. Le but du jeu était de créer un Lisp couvrant les
fonctionnalités de plusieurs dialectes incompatibles entre eux. Par
conséquent, le langage n’est certes pas aussi « pur » qu’un Scheme et comporte
quelques petites incohérences et de petits défauts ; la syntaxe de la macro
loop et celle de la fonction format étant les aspects les plus
controversés. Néanmoins, il est tout à fait apte à être utilisé pour des
applications industrielles et j’ai même vu un livre de finance dont les
exemples de code sont en Common Lisp. Paul Graham explique par exemple
comment, dans les années 1990, il a monté une start-up d’hébergement de
boutiques en ligne, Viaweb, en Lisp, dans son article « Beating the
Averages ».
Son écosystème riche, son système de programmation orientée objet, CLOS, ainsi
que son système de gestion d’erreurs qui propose une approche intéressante aux
exceptions tels qu’on les trouve en C++, Java ou Python font de ce Lisp un
langage qui vaut le détour.
Clojure : un Lisp pour la JVM
Clojure, quant à lui, est un Lisp plus récent, conçu pour s’intégrer dans
l’écosystème Java. Il s’exécute en effet exclusivement dans la JVM et le
langage est bien entendu doté de primitives pour interagir avec des classes
Java. En résumé, c’est une façon de faire du Java sans subir la syntaxe
verbeuse ni l’orienté objet à outrance du Java.
Son Java interop m’a déjà bien servi : j’avais eu besoin un jour de déboguer
un document Word (au format docx), généré par un logiciel mais que Word
déclarait corrompu. Pour cela, j’ai utilisé la bibliothèque Java docx4j,
quelques fonctions en Clojure mais surtout le REPL de Clojure pour explorer la
structure du document et trouver le problème. In fine, il s’avérait juste
que deux éléments XML avaient le même identifiant.
Il existe aussi une variante de Clojure appelée ClojureScript, qui comme son
nom l’indique tourne non pas sur la JVM mais dans un environnement
JavaScript. Clojure et ClojureScript utilisés ensemble permettent donc de
partager du code entre les côtés serveur et client dans un projet Web, mais
je n’ai pas encore eu l’occasion de mettre cela en pratique. Cela étant, le
développement en ClojureScript pour cibler un navigateur est un peu plus
fastidieux car l’accès à un REPL est plus compliqué à mettre en place
qu’avec Clojure.
Parmi les aspects les plus intéressants du langage figurent les lazy seqs,
c’est-à-dire des séquences, pouvant être infinies, qui sont évalués de façon
paresseuse. On peut par exemple définir une fonction qui génère la suite
(infinie) de Fibonacci, puis n’en demander que le dixième terme ; ceci
provoque le calcul des dix premiers termes uniquement.
Mais il y a plusieurs aspects qui me rebutent dans ce langage et qui me font
hésiter à en faire mon outil de choix.
Premièrement, du fait de son adhérence forte à Java, certains des reproches
qu’on fait à Java s’appliquent aussi à Clojure. Lancer un REPL, par exemple,
devient vite lent et gourmand en RAM : dans un projet vierge, ça démarre en
une demi-seconde avec déjà 294 Mo de RAM occupés, mais dans un projet plus
avancé avec une quinzaine de bibliothèques en dépendances, ça monte à 678 Mo
de RAM après près de deux minutes de compilation. Et dans mon environnement
Emacs, il n’est pas rare de voir des sous-processus Java monter à plus de 2 Go
de RAM !
Clojure me semble plutôt marcher sur les plates-bandes traditionnelles de
Java, qui sont les gros logiciels (trop) complexes qu’on démarre et arrête
généralement en même temps que sa machine hôte. Je ne me vois pas faire de
scripts avec, simplement à cause du temps de démarrage de la JVM qui interdit
de fait ce type d’usages.
Deuxièmement, le fait qu’il soit distribué sous la licence Eclipse Public
License (EPL) 1.0 me semble être un choix malheureux, étant donné qu’il faut
nécessairement distribuer le binaire (.jar) du cœur de Clojure avec tout
programme Clojure. Or cette licence connue pour poser problème avec d’autres
licences libres comme la GPL.
Le langage est en lui-même intéressant et a peut-être permis d’introduire du
Lisp dans des environnements traditionnellement prompts à se ruer sur Java
pour tout projet. Mais ce ne sera pas le langage que je choisirai en premier
pour un nouveau projet car ça reste une « usine à gaz ».
Haskell, le parfait anti-Lisp dans sa syntaxe
Certains ouvrages sur Lisp que j’ai lus avant d’écrire ce billet mentionnaient
Haskell, presque comme s’il s’agissait d’un Lisp lui aussi. Il s’agit d’un
langage fonctionnel, une approche qui se prête bien au Lisp. Par curiosité,
j’ai voulu essayer.
Le tutoriel Web sur le site officiel, entièrement interactif, m’a
particulièrement impressionné. Une autre très bonne ressource qui m’a servi
pour essayer le Haskell est le livre Learn You a Haskell for Great Good! de
Miran Lipovača (disponible gratuitement en ligne).
Mais j’ai du mal avec sa syntaxe. La quasi-absence de parenthèses est très
déroutante car elle oblige le lecteur à se rappeler des règles
d’associativité. Les appels de fonction n’échappent pas à la règle ; le
langage doit donc prévoir un opérateur, $, pour appliquer une fonction avec
une associativité à droite plutôt qu’à gauche ; le tout est un obstacle à un
code intelligible. Ensuite, la nécessité d’indenter le code de façon très
précise, ce qui revient à donner une importance syntaxique aux blancs (comme
en Python), est un autre aspect avec lequel j’ai personnellement beaucoup de
mal. Le haskell-mode d’Emacs facilite un peu les choses, mais j’ai tout de
même le sentiment que ce langage n’est pas fait pour moi.
Néanmoins, je perçois l’influence du Lisp dans le fait que l’opérateur servant
à ajouter un élément au début d’une liste (:) s’appelle « cons », comme la
fonction du même nom en Lisp.
J’accorderai peut-être une seconde chance plus tard à ce langage, mais dans
l’immédiat, je préfère le confort et l’inambiguïté des S-expressions.
Retour à Common Lisp
En recherchant des ressources sur la programmation en Emacs Lisp, je suis
tombé sur un petit tutoriel ludique dans lequel on programme un petit jeu
d’aventure textuel en Lisp. Ce tutoriel est par ailleurs une bonne
démonstration de ce qu’il est possible de construire avec des macros Lisp.
L’auteur, Conrad Barski, a ensuite publié le très bon ouvrage Land of Lisp,
qui va dans le prolongement de ce petit tutoriel : tous les exemples sont des
jeux. Cette approche convient particulièrement bien à un public non
informaticien et permet d’aborder des thématiques que je ne ne vois pas
souvent dans des introductions à des langages de programmation, comme par
exemple la programmation d’intelligences artificielles pour des jeux de
plateau. Grâce à ce livre, Nausicaa a adopté le Common Lisp et est en train
d’écrire un jeu dans ce langage ; ce qui est de très bonne augure, car cela
nous fait un langage de programmation en commun que nous apprécions ensemble.
Peu avant de partir en vacances d’été, je me suis amusé, en guise de petit
défi, d’écrire un solveur de picross. J’avais choisi Common Lisp plutôt que
Clojure car Common Lisp ne dispose pas des lazy seqs de Clojure. C’est un
projet qui s’est avéré beaucoup plus intéressant qu’à première vue et dont je
parlerai sûrement dans un billet futur.
Par ailleurs, Common Lisp étant lui-même une spécification, il existe en fait
plusieurs environnements Lisp qui portent des noms différents : parmi eux, il
y a GNU CLISP, SBCL, Clozure CL (à ne pas confondre avec Clojure) et ABCL,
ce dernier ayant la particularité de tourner sur la JVM.
Racket ou la programmation orientée langages
Ma dernière destination dans mon voyage dans l’univers des Lisp est Racket.
Racket est en fait un langage dérivé de Scheme, qui est lui-même un Lisp qui a
vu le jour dans les années 1970 au MIT. Racket est conçu à la fois comme un
outil de recherche et comme un support pédagogique en théorie de langages de
programmation (d’où son nom d’origine, PLT Scheme – PLT pour Programming
Language Theory).
La principale caractéristique de Racket est d’offrir un cadre pour définir,
dans le compilateur Racket, n’importe quel langage dédié. Bien que les autres
Lisp se prêtent très bien à la création de tels langages dédiés, ces langages
sont la plupart du temps tenus à respecter la syntaxe des S-expressions.
Racket, quant à lui, permet de créer des langages qui s’affranchissent de
cette limitation : ainsi, on peut très bien créer des langages où on peut
exprimer le produit 7 × 191 par une notation infixe (7 * 191) plutôt que
préfixe ((* 7 191)).
Ainsi, Racket pousse la notion de programmation orientée langages le plus loin possible. Plutôt que d’exprimer une solution à un problème directement
dans un langage de programmation, on définit d’abord un langage plus concis
dans lequel on exprime le problème, on écrit un programme transformant les
expressions de ce nouveau langage en code Racket, puis on compile ce nouveau
langage.
La programmation orientée langages a lui-même de nombreuses applications. Il
existe par exemple un langage d’édition vidéo. Le studio Naughty Dog a
également utilisé des mini-langages créés dans Racket pour scripter l’intrigue
et l’intelligence artificielle dans certains de ses jeux (voir par exemple
cette présentation par le CTO de l’entreprise).
J’ajouterais aussi que même si personnellement, je préfère Emacs et son
racket-mode pour des raisons de confort, l’IDE de référence, DrRacket est
bien conçu et est un outil qu’on peut mettre entre toutes les mains, notamment
de débutants. En particulier, le livre How to Design Programs par Matthias
Felleisen et al. utilise Racket comme outil pédagogique.
Je n’ai pas encore eu l’occasion de me faire la main sur Racket avec un projet
sérieux, mais je vois énormément de potentiel dans un langage qui a l’air à la
fois très puissant et très accessible à des débutants.
Conclusion
Ma découverte fortuite d’Emacs m’a permis d’explorer en deux ans un univers
entier de langages de programmation que je n’aurais pas eu la curiosité
d’étudier sinon. Je suis conscient que je n’ai pas encore exploré Scheme, en
dépit de ma possession d’un exemplaire papier de Structure and
Interpretation of Computer Programs de Harold Abelson et Gerald J. Sussman
(consultable gratuitement en ligne), ni Guile, entre autres utilisé pour
scripter divers logiciels GNU. Mais je pense néanmoins avoir au moins fait le
tour des langages les plus représentatifs de ce qu’est la famille Lisp
aujourd’hui.
Ces nouveaux langages pour moi ont été l’occasion de me lancer dans certains
projets personnels dont je parlerai sûrement dans d’autres billets de blog :
par exemple, j’ai fait un robot générateur de texte à base de chaînes de
Markov ou un solveur de Picross assez efficacement ; dans les deux cas, mon
tout premier prototype était opérationnel en l’équivalent d’une ou deux
soirées.
Me voilà donc converti au Common Lisp, voire peut-être au langage Racket si
mes expériences dans ce langage-là sont concluants.
Pour terminer, je me permets de citer Eric S. Raymond, qui, dans son essai
intitulé « How To Become A Hacker », écrit :
LISP is worth learning for a different reason — the profound enlightenment
experience you will have when you finally get it. That experience will make
you a better programmer for the rest of your days, even if you never actually
use LISP itself a lot.
