A l’été 1995, Paul Graham fonde avec un ami une startup nommée ViaWeb.
Son produit : un logiciel pour faire des sites de e-commerce. L’ancêtre de Shopify.
Et Paul fait 2 choix technologiques radicalement différents de ce qui faisait référence à l’époque :
- le logiciel est uniquement utilisable en ligne, au travers de pages Web, et sous la forme d’un abonnement. C’est le début des SaaS. C’est osé, et ça diffuse jusque dans le nom de la boite : ViaWeb = l’outil utilisable via le web.
- il est codé en Lisp.
Alors pour le choix du mode SaaS, on connaît les atouts de ce pari :
- pas de distribution via un support physique → le logiciel est constamment à jour,
- maîtrise de la plateforme matérielle du serveur → plus de contrainte liée au PC du client,
- c’est collaboratif, on travaille à plusieurs sur les mêmes données.
Mais pour le Lisp, ça ne saute pas aux yeux...
Un langage de chercheurs en IA
Lisp, c’est un langage de programmation inventé en 1958. Intellectuellement, c’est de toute beauté :
- le coeur du langage se réduit à 7 opérateurs
- un interpréteur Lisp peut être codé en 30 lignes de Lisp (vous suivez ?)
- on peut coder des fonctions Lisp qui génèrent du code Lisp (métaprogrammation : des programmes qui génèrent des programmes).
Mais à lire, c’est une horreur.
Mais Paul, il s’en fout.
Il trouve le langage hyper-puissant. Et il pense que ce qui compte, c’est que la machine comprenne le code, pas les autres. Sur ce point, il a probablement changé d’avis depuis…
Mais derrière ce choix baroque, il y a une idée brillante : créer un langage spécifique pour personnaliser à fond son site de e-commerce.
C’est le RTML.
Le langage de Robert.
RTML, ça signifie "Robert T. Morris Language”.
Robert, c’est l’associé de Paul. Il a donné son nom au langage inventé pour ViaWeb qui sert à générer les pages du site de e-commerce. Aujourd’hui, on parlerait peut-être de low-code pour désigner ça.
Il faut reconnaître que ce n'est pas non plus hyper lisible. Mais les utilisateurs ne sont pas obligés d’utiliser le RTML. Ils peuvent choisir des templates prédéfinis, prêts à l’emploi. Ces templates sont eux aussi “codés” en RTML par Paul et Robert.
Et là, on comprend mieux le choix de Lisp. Parce que ce langage excelle pour coder d’autres langages (y compris lui-même, mais je m’égare).
De bas en haut
Un logiciel complexe est découpé en morceaux imbriqués et de moindre complexité. C’est la base de la programmation. En général, les développeurs adoptent une démarche de conception descendante : on démarre avec le truc complexe, que l’on va découper petit à petit.
Si mon code doit enchaîner 7 traitements, alors je vais coder 7 fonctions pour ne pas tout bourrer dans une seule. Et comme la première fonction doit faire 4 choses, je vais la sous-découper en 4 fonctions élémentaires. Et ainsi de suite.
Mais les développeurs Lisp pensent différemment.
Ils vont se dire : si je disposais d’un langage spécifique pour écrire tout mon code en seulement quelques lignes, quels seraient les opérateurs de ce langage ?
Alors au lieu de coder le logiciel, on va coder les composants d’un langage ultra-adapté au métier.
Imaginez un assureur qui pourrait écrire ça :
SI assuré.est_jeune_conducteur()
ET assuré.sans_accident_depuis(2 ans)
ET assuré.a_fait_conduite_accompagnée()
ET assuré.parents.clients_depuis(10 ans)
ALORS assuré.assurance(auto).appliquer_réduction(10 %)
Un code tellement lisible qu’on comprend immédiatement ce qu’il fait. Pas besoin d’être développeur.
Pour fabriquer ce langage spécifique, il faut imaginer les opérateurs élémentaires nécessaires pour faire ce qu’on veut : "est_jeune_conducteur()", "clients_depuis()", etc...
On démarre donc par concevoir les briques de bases permettant de décrire n’importe quel traitement complexe, même celui qu’on ne connaît pas encore. C’est une démarche de conception ascendante.
Ce langage évolue avec le code : lorsqu’on rencontre un cas que l’on ne parvient pas à exprimer facilement, c’est qu’il manque un opérateur ou que le modèle n’est pas bon.
Plusieurs avantages avec cette démarche de conception :
- le code d’en haut (= langage spécifique) reste simple, compact et lisible. Donc plus facile à créer et à faire évoluer. Les similitudes sautent plus facilement aux yeux.
- le code d’en bas (= les briques de base) a davantage de potentiel de ré-utilisation. Par conception, les briques sont génériques.
- il y moins de couplage : seul le code d’en haut utilise les briques d’en bas. Il n’y a aucun couplage dans l’autre sens, et pas de couplage latéral. Moins de couplage = code plus simple à maîtriser.
Une arme secrète
Dans son blog de l’époque, Paul qualifie ces 2 choix techniques (SaaS+Lisp) d’arme secrète.
Il affirme que Lisp raccourcit les cycles de développement. Les nouvelles fonctionnalités sont rapides à coder, en particulier celles proposées par les concurrents (une vingtaine à l’époque).
L’architecture SaaS offre une distribution instantanée, ainsi qu’un service client bien meilleur : le support technique voit les données du client → il peut reproduire immédiatement son problème → les devs corrigent rapidement les bugs.
ViaWeb a été racheté en 1998 par Yahoo, en échange d’actions d’une valeur de 50M$. Elle propulsait environ un millier de sites de e-commerce. La solution rebaptisée Yahoo Store a atteint les 20,000 clients en 1999.
Même si rien d’officiel n’a été publié, Yahoo semble avoir ré-écrit le code Lisp en Perl et en C++. La raison invoquée était la pénurie de développeurs compétents en Lisp.
Reste qu’à ce jour, le SaaS s’est imposé comme le modèle dominant pour les logiciels. Et même si Lisp est retourné dans les limbes des langages de programmation, le développement guidé par le métier fait référence en ingénierie logicielle.
Références :
- Programming bottom-up (P. Graham) : http://www.paulgraham.com/progbot.html
- Le langage RTML : https://en.wikipedia.org/wiki/RTML
- Beating the average (P. Graham) : http://www.paulgraham.com/avg.html
- La 10ème loi de Greenspun : “tout programme suffisamment compliqué contient une implémentation spécifique, lente, spécifiée de manière informelle, et buggée de la moitié de Common Lisp. ” https://softwareengineering.stackexchange.com/questions/137043/greenspuns-tenth-rule-does-every-large-project-include-a-lisp-interpreter/137679
