BATTRE LES MOYENNES

Avril 2001, rev. Avril 2003

(Cet article est tiré d'une conférence donnée au Franz Developer Symposium 2001.)

À l'été 1995, mon ami Robert Morris et moi avons lancé une start-up appelée Viaweb. Notre plan était d'écrire un logiciel qui permettrait aux utilisateurs finaux de créer des boutiques en ligne. Ce qui était nouveau dans ce logiciel, à l'époque, c'était qu'il tournait sur notre serveur, en utilisant des pages Web ordinaires comme interface.

Beaucoup de gens auraient pu avoir cette idée en même temps, bien sûr, mais à ma connaissance, Viaweb était la première application Web. Cela nous a semblé tellement nouveau que nous avons nommé l'entreprise d'après : Viaweb, parce que notre logiciel fonctionnait via le Web, au lieu de tourner sur votre ordinateur de bureau.

Une autre chose inhabituelle à propos de ce logiciel était qu'il était écrit principalement dans un langage de programmation appelé Lisp. C'était l'une des premières grandes applications grand public à être écrite en Lisp, qui jusqu'alors avait été utilisé principalement dans les universités et les laboratoires de recherche. [1]

L'arme secrète

Eric Raymond a écrit un essai intitulé "Comment devenir un pirate informatique", et dans celui-ci, entre autres choses, il dit aux pirates en herbe quels langages ils devraient apprendre. Il suggère de commencer par Python et Java, car ils sont faciles à apprendre. Le pirate informatique sérieux voudra également apprendre le C, afin de pirater Unix, et Perl pour l'administration système et les scripts cgi. Enfin, le pirate informatique vraiment sérieux devrait envisager d'apprendre Lisp :

Lisp vaut la peine d'être appris pour l'expérience d'illumination profonde que vous aurez lorsque vous finirez par le comprendre ; cette expérience vous fera devenir un meilleur programmeur pour le reste de vos jours, même si vous n'utilisez jamais vraiment Lisp lui-même beaucoup.

C'est le même argument que vous entendez souvent pour apprendre le latin. Il ne vous fera pas décrocher un emploi, sauf peut-être en tant que professeur de lettres classiques, mais il améliorera votre esprit et fera de vous un meilleur écrivain dans les langues que vous souhaitez utiliser, comme l'anglais.

Mais attendez une minute. Cette métaphore ne s'étend pas aussi loin. La raison pour laquelle le latin ne vous fera pas décrocher un emploi est que personne ne le parle. Si vous écrivez en latin, personne ne peut vous comprendre. Mais Lisp est un langage informatique, et les ordinateurs parlent la langue que vous, le programmeur, leur dites de parler.

Donc, si Lisp fait de vous un meilleur programmeur, comme il le dit, pourquoi ne pas l'utiliser ? Si un peintre se voyait offrir un pinceau qui ferait de lui un meilleur peintre, il me semble qu'il voudrait l'utiliser dans toutes ses peintures, n'est-ce pas ? Je n'essaie pas de me moquer d'Eric Raymond ici. Dans l'ensemble, ses conseils sont bons. Ce qu'il dit à propos de Lisp est à peu près la sagesse conventionnelle. Mais il y a une contradiction dans la sagesse conventionnelle : Lisp vous fera devenir un meilleur programmeur, et pourtant vous ne l'utiliserez pas.

Pourquoi pas ? Les langages de programmation ne sont après tout que des outils. Si Lisp donne vraiment de meilleurs programmes, vous devriez l'utiliser. Et si ce n'est pas le cas, alors qui en a besoin ?

Ce n'est pas seulement une question théorique. Le logiciel est un marché très concurrentiel, sujet aux monopoles naturels. Une entreprise qui obtient un logiciel écrit plus rapidement et mieux, toutes choses étant égales par ailleurs, mettra ses concurrents en difficulté. Et lorsque vous lancez une start-up, vous ressentez cela très fortement. Les start-ups ont tendance à être une proposition tout ou rien. Vous devenez soit riche, soit vous ne gagnez rien. Dans une start-up, si vous pariez sur la mauvaise technologie, vos concurrents vous écraseront.

Robert et moi connaissions bien Lisp, et nous ne voyions aucune raison de ne pas faire confiance à notre instinct et d'opter pour Lisp. Nous savions que tout le monde écrivait son logiciel en C++ ou en Perl. Mais nous savions aussi que cela ne voulait rien dire. Si vous choisissiez la technologie de cette façon, vous utiliseriez Windows. Lorsque vous choisissez une technologie, vous devez ignorer ce que font les autres, et ne considérer que ce qui fonctionnera le mieux.

C'est particulièrement vrai dans une start-up. Dans une grande entreprise, vous pouvez faire ce que font toutes les autres grandes entreprises. Mais une start-up ne peut pas faire ce que font toutes les autres start-ups. Je ne pense pas que beaucoup de gens réalisent cela, même dans les start-ups.

L'entreprise moyenne grandit d'environ dix pour cent par an. Donc, si vous dirigez une grande entreprise et que vous faites tout comme l'entreprise moyenne, vous pouvez vous attendre à faire aussi bien que l'entreprise moyenne, c'est-à-dire à croître d'environ dix pour cent par an.

La même chose se produira si vous dirigez une start-up, bien sûr. Si vous faites tout comme la start-up moyenne, vous devriez vous attendre à des performances moyennes. Le problème ici est que les performances moyennes signifient que vous allez faire faillite. Le taux de survie des start-ups est bien inférieur à cinquante pour cent. Donc, si vous dirigez une start-up, vous feriez mieux de faire quelque chose d'inhabituel. Sinon, vous êtes en difficulté.

En 1995, nous savions quelque chose que je ne pense pas que nos concurrents aient compris, et que peu de gens comprennent même aujourd'hui : lorsque vous écrivez un logiciel qui ne doit tourner que sur vos propres serveurs, vous pouvez utiliser n'importe quel langage que vous voulez. Lorsque vous écrivez un logiciel de bureau, il y a un fort parti pris pour écrire des applications dans le même langage que le système d'exploitation. Il y a dix ans, écrire des applications signifiait écrire des applications en C. Mais avec les logiciels basés sur le Web, surtout lorsque vous avez le code source du langage et du système d'exploitation, vous pouvez utiliser le langage que vous voulez.

Cette nouvelle liberté est une arme à double tranchant, cependant. Maintenant que vous pouvez utiliser n'importe quel langage, vous devez réfléchir à celui que vous allez utiliser. Les entreprises qui essaient de faire comme si rien n'avait changé risquent de constater que leurs concurrents ne le font pas.

Si vous pouvez utiliser n'importe quel langage, lequel utilisez-vous ? Nous avons choisi Lisp. D'une part, il était évident que le développement rapide serait important sur ce marché. Nous partions tous de zéro, donc une entreprise qui pouvait mettre en œuvre de nouvelles fonctionnalités avant ses concurrents aurait un grand avantage. Nous savions que Lisp était un très bon langage pour écrire des logiciels rapidement, et les applications basées sur des serveurs amplifient l'effet du développement rapide, car vous pouvez publier des logiciels à la minute où ils sont terminés.

Si les autres entreprises ne voulaient pas utiliser Lisp, tant mieux. Cela pourrait nous donner un avantage technologique, et nous avions besoin de toute l'aide que nous pouvions obtenir. Lorsque nous avons lancé Viaweb, nous n'avions aucune expérience en affaires. Nous ne connaissions rien au marketing, au recrutement de personnel, à la levée de fonds ou à l'acquisition de clients. Aucun de nous n'avait même jamais eu ce que l'on pourrait appeler un vrai travail. La seule chose à laquelle nous étions bons, c'était écrire des logiciels. Nous espérions que cela nous sauverait. Tout avantage que nous pouvions obtenir dans le département logiciel, nous le prenions.

Donc, vous pourriez dire que l'utilisation de Lisp était une expérience. Notre hypothèse était que si nous écrivions notre logiciel en Lisp, nous serions capables de mettre en œuvre des fonctionnalités plus rapidement que nos concurrents, et aussi de faire des choses dans notre logiciel qu'ils ne pouvaient pas faire. Et parce que Lisp était tellement haut niveau, nous n'aurions pas besoin d'une grande équipe de développement, donc nos coûts seraient plus bas. Si c'était le cas, nous pourrions offrir un meilleur produit pour moins cher, et toujours faire des bénéfices. Nous finirions par obtenir tous les utilisateurs, et nos concurrents n'en obtiendraient aucun, et finiraient par faire faillite. C'est ce que nous espérions qu'il se produise, en tout cas.

Quels ont été les résultats de cette expérience ? Assez étonnamment, cela a fonctionné. Nous avons fini par avoir de nombreux concurrents, de l'ordre de vingt à trente d'entre eux, mais aucun de leurs logiciels n'a pu rivaliser avec le nôtre. Nous avions un générateur de boutiques en ligne wysiwyg qui tournait sur le serveur et qui donnait pourtant l'impression d'une application de bureau. Nos concurrents avaient des scripts cgi. Et nous étions toujours en avance sur eux en termes de fonctionnalités. Parfois, par désespoir, les concurrents essayaient d'introduire des fonctionnalités que nous n'avions pas. Mais avec Lisp, notre cycle de développement était tellement rapide que nous pouvions parfois dupliquer une nouvelle fonctionnalité en un jour ou deux après qu'un concurrent l'avait annoncée dans un communiqué de presse. Au moment où les journalistes couvrant le communiqué de presse nous appelaient, nous avions la nouvelle fonctionnalité aussi.

Il a dû sembler à nos concurrents que nous avions une sorte d' arme secrète, que nous décryptions leur trafic Enigma ou quelque chose du genre. En fait, nous avions une arme secrète, mais elle était plus simple qu'ils ne le pensaient. Personne ne nous faisait fuiter des informations sur leurs fonctionnalités. Nous étions simplement capables de développer des logiciels plus rapidement que quiconque ne le pensait possible.

Quand j'avais environ neuf ans, j'ai eu la chance de mettre la main sur un exemplaire de Le Jour du Chacal, de Frederick Forsyth. Le personnage principal est un assassin qui est engagé pour tuer le président de la France. L'assassin doit passer outre la police pour se rendre dans un appartement qui surplombe l'itinéraire du président. Il passe devant eux, déguisé en vieil homme sur des béquilles, et ils ne se doutent de rien.

Notre arme secrète était similaire. Nous avons écrit notre logiciel dans un langage d'IA bizarre, avec une syntaxe bizarre pleine de parenthèses. Pendant des années, cela m'a énervé d'entendre Lisp décrit de cette façon. Mais maintenant, cela a joué en notre faveur. En affaires, il n'y a rien de plus précieux qu'un avantage technique que vos concurrents ne comprennent pas. En affaires, comme à la guerre, la surprise vaut autant que la force.

Et donc, j'ai un peu honte de le dire, je n'ai jamais rien dit publiquement à propos de Lisp pendant que nous travaillions sur Viaweb. Nous ne l'avons jamais mentionné à la presse, et si vous cherchiez Lisp sur notre site Web, tout ce que vous trouveriez seraient les titres de deux livres dans ma biographie. Ce n'était pas un hasard. Une start-up doit donner à ses concurrents le moins d'informations possible. S'ils ne savaient pas dans quel langage notre logiciel était écrit, ou s'ils ne s'en souciaient pas, je voulais que cela reste ainsi. [2]

Les personnes qui comprenaient le mieux notre technologie étaient les clients. Ils ne se souciaient pas non plus du langage dans lequel Viaweb était écrit, mais ils ont remarqué que cela fonctionnait vraiment bien. Cela leur permettait de créer de superbes boutiques en ligne en quelques minutes. Et donc, principalement par le bouche à oreille, nous avons obtenu de plus en plus d'utilisateurs. À la fin de 1996, nous avions environ 70 boutiques en ligne. À la fin de 1997, nous en avions 500. Six mois plus tard, lorsque Yahoo nous a rachetés, nous avions 1070 utilisateurs. Aujourd'hui, en tant que Yahoo Store, ce logiciel continue de dominer son marché. C'est l'une des parties les plus rentables de Yahoo, et les boutiques construites avec lui sont le fondement de Yahoo Shopping. J'ai quitté Yahoo en 1999, donc je ne sais pas exactement combien d'utilisateurs ils ont maintenant, mais la dernière fois que j'ai entendu parler, il y en avait environ 20 000.

Le paradoxe de Blub

Qu'est-ce qu'il y a de si bien dans Lisp ? Et si Lisp est si bien, pourquoi tout le monde ne l'utilise pas ? Cela ressemble à des questions rhétoriques, mais en fait elles ont des réponses simples. Lisp est si bien, non pas à cause d'une qualité magique visible uniquement par les dévots, mais parce qu'il est tout simplement le langage le plus puissant disponible. Et la raison pour laquelle tout le monde ne l'utilise pas est que les langages de programmation ne sont pas seulement des technologies, mais aussi des habitudes d'esprit, et rien ne change plus lentement. Bien sûr, ces deux réponses ont besoin d'être expliquées.

Je vais commencer par une déclaration choquante et controversée : les langages de programmation varient en puissance.

Peu de gens contesteraient, au moins, que les langages de haut niveau sont plus puissants que le langage machine. La plupart des programmeurs d'aujourd'hui seraient d'accord pour dire que vous ne voulez pas, en général, programmer en langage machine. Au lieu de cela, vous devriez programmer dans un langage de haut niveau, et avoir un compilateur qui le traduira en langage machine pour vous. Cette idée est même intégrée dans le matériel maintenant : depuis les années 1980, les ensembles d'instructions ont été conçus pour les compilateurs plutôt que pour les programmeurs humains.

Tout le monde sait que c'est une erreur d'écrire tout votre programme à la main en langage machine. Ce qui est moins souvent compris, c'est qu'il y a un principe plus général ici : que si vous avez le choix entre plusieurs langages, c'est, toutes choses étant égales par ailleurs, une erreur de programmer dans autre chose que le plus puissant. [3]

Il existe de nombreuses exceptions à cette règle. Si vous écrivez un programme qui doit fonctionner très étroitement avec un programme écrit dans un certain langage, il pourrait être judicieux d'écrire le nouveau programme dans le même langage. Si vous écrivez un programme qui ne doit faire que quelque chose de très simple, comme le calcul numérique ou la manipulation de bits, vous pouvez aussi bien utiliser un langage moins abstrait, d'autant plus qu'il peut être légèrement plus rapide. Et si vous écrivez un programme court et jetable, vous feriez peut-être mieux d'utiliser simplement le langage qui a les meilleures fonctions de bibliothèque pour la tâche. Mais en général, pour les logiciels applicatifs, vous voulez utiliser le langage le plus puissant (raisonnablement efficace) que vous puissiez obtenir, et utiliser autre chose est une erreur, exactement du même type, bien que peut-être à un degré moindre, que la programmation en langage machine.

Vous pouvez voir que le langage machine est très bas niveau. Mais, au moins en tant que convention sociale, les langages de haut niveau sont souvent tous traités comme équivalents. Ils ne le sont pas. Techniquement, le terme "langage de haut niveau" ne signifie rien de très précis. Il n'y a pas de ligne de démarcation avec les langages machine d'un côté et tous les langages de haut niveau de l'autre. Les langages se situent le long d'un continuum [4] d'abstraction, du plus puissant jusqu'aux langages machine, qui eux-mêmes varient en puissance.

Prenons Cobol. Cobol est un langage de haut niveau, dans le sens où il est compilé en langage machine. Quelqu'un argumenterait-il sérieusement que Cobol est équivalent en puissance à, disons, Python ? Il est probablement plus proche du langage machine que Python.

Ou que diriez-vous de Perl 4 ? Entre Perl 4 et Perl 5, les fermetures lexicales ont été ajoutées au langage. La plupart des hackers Perl seraient d'accord pour dire que Perl 5 est plus puissant que Perl 4. Mais une fois que vous avez admis cela, vous avez admis qu'un langage de haut niveau peut être plus puissant qu'un autre. Et il s'ensuit inexorablement que, sauf dans des cas particuliers, vous devriez utiliser le plus puissant que vous puissiez obtenir.

Cette idée est rarement suivie jusqu'à sa conclusion, cependant. Après un certain âge, les programmeurs changent rarement de langage volontairement. Quel que soit le langage que les gens utilisent, ils ont tendance à le considérer comme suffisamment bon.

Les programmeurs s'attachent beaucoup à leurs langages préférés, et je ne veux blesser les sentiments de personne, donc pour expliquer ce point, je vais utiliser un langage hypothétique appelé Blub. Blub se situe juste au milieu du continuum d'abstraction. Ce n'est pas le langage le plus puissant, mais il est plus puissant que Cobol ou le langage machine.

Et en fait, notre programmeur Blub hypothétique n'utiliserait ni l'un ni l'autre. Bien sûr, il ne programmerait pas en langage machine. C'est à cela que servent les compilateurs. Et quant à Cobol, il ne sait pas comment on peut faire quoi que ce soit avec. Il n'a même pas x (fonctionnalité Blub de votre choix).

Tant que notre programmeur Blub hypothétique regarde vers le bas le continuum de puissance, il sait qu'il regarde vers le bas. Les langages moins puissants que Blub sont évidemment moins puissants, car ils manquent de certaines fonctionnalités auxquelles il est habitué. Mais lorsque notre programmeur Blub hypothétique regarde dans l'autre sens, vers le haut du continuum de puissance, il ne se rend pas compte qu'il regarde vers le haut. Ce qu'il voit ne sont que des langages étranges. Il les considère probablement comme étant à peu près équivalents en puissance à Blub, mais avec tout ce truc supplémentaire et compliqué en plus. Blub est suffisamment bon pour lui, car il pense en Blub.

Lorsque nous passons au point de vue d'un programmeur utilisant l'un des langages plus haut dans le continuum de puissance, cependant, nous constatons qu'il regarde à son tour Blub de haut. Comment pouvez-vous faire quoi que ce soit en Blub ? Il n'a même pas y.

Par induction, les seuls programmeurs en mesure de voir toutes les différences de puissance entre les différents langages sont ceux qui comprennent le plus puissant. (C'est probablement ce qu'Eric Raymond voulait dire par le fait que Lisp fait de vous un meilleur programmeur.) Vous ne pouvez pas faire confiance aux opinions des autres, à cause du paradoxe de Blub : ils sont satisfaits du langage qu'ils utilisent, car il dicte la façon dont ils pensent aux programmes.

Je le sais par ma propre expérience, en tant que lycéen écrivant des programmes en Basic. Ce langage ne supportait même pas la récursivité. Il est difficile d'imaginer écrire des programmes sans utiliser la récursivité, mais je ne l'ai pas manqué à l'époque. Je pensais en Basic. Et j'étais un as dans ce domaine. Maître de tout ce que je voyais.

Les cinq langages qu'Eric Raymond recommande aux hackers se situent à différents points sur le continuum de puissance. Où ils se situent par rapport les uns aux autres est un sujet sensible. Ce que je dirai, c'est que je pense que Lisp est au sommet. Et pour étayer cette affirmation, je vais vous parler de l'une des choses qui me manquent lorsque je regarde les quatre autres langages. Comment pouvez-vous faire quoi que ce soit avec eux, me dis-je, sans macros ? [5]

De nombreux langages ont quelque chose appelé une macro. Mais les macros Lisp sont uniques. Et croyez-le ou non, ce qu'elles font est lié aux parenthèses. Les concepteurs de Lisp n'ont pas mis toutes ces parenthèses dans le langage juste pour être différents. Pour le programmeur Blub, le code Lisp a l'air bizarre. Mais ces parenthèses sont là pour une raison. Elles sont la preuve extérieure d'une différence fondamentale entre Lisp et les autres langages.

Le code Lisp est fait d'objets de données Lisp. Et pas dans le sens trivial que les fichiers sources contiennent des caractères, et que les chaînes de caractères sont l'un des types de données pris en charge par le langage. Le code Lisp, après qu'il a été lu par l'analyseur, est fait de structures de données que vous pouvez parcourir.

Si vous comprenez comment fonctionnent les compilateurs, ce qui se passe vraiment n'est pas tant que Lisp a une syntaxe étrange que Lisp n'a pas de syntaxe. Vous écrivez des programmes dans les arbres d'analyse qui sont générés au sein du compilateur lorsque d'autres langages sont analysés. Mais ces arbres d'analyse sont entièrement accessibles à vos programmes. Vous pouvez écrire des programmes qui les manipulent. En Lisp, ces programmes sont appelés macros. Ce sont des programmes qui écrivent des programmes.

Des programmes qui écrivent des programmes ? Quand voudriez-vous faire ça ? Pas très souvent, si vous pensez en Cobol. Tout le temps, si vous pensez en Lisp. Ce serait pratique ici si je pouvais donner un exemple d'une macro puissante, et dire voilà ! qu'en pensez-vous ? Mais si je le faisais, cela ressemblerait à du charabia pour quelqu'un qui ne connaît pas Lisp ; il n'y a pas de place ici pour expliquer tout ce que vous auriez besoin de savoir pour comprendre ce que cela signifie. Dans Ansi Common Lisp j'ai essayé de faire avancer les choses le plus vite possible, et même ainsi, je n'ai pas abordé les macros avant la page 160.

Mais je pense que je peux donner une sorte d'argument qui pourrait être convaincant. Le code source de l'éditeur Viaweb faisait probablement environ 20-25 % de macros. Les macros sont plus difficiles à écrire que les fonctions Lisp ordinaires, et il est considéré comme une mauvaise pratique de les utiliser lorsqu'elles ne sont pas nécessaires. Donc, chaque macro dans ce code est là parce qu'elle doit l'être. Ce qui signifie qu'au moins 20-25 % du code de ce programme fait des choses que vous ne pouvez pas facilement faire dans un autre langage. Quel que soit le scepticisme du programmeur Blub à propos de mes affirmations sur les pouvoirs mystérieux de Lisp, cela devrait le rendre curieux. Nous n'écrivions pas ce code pour notre propre amusement. Nous étions une petite start-up, programmant aussi dur que possible afin de mettre des barrières techniques entre nous et nos concurrents.

Une personne suspecte pourrait commencer à se demander s'il y avait une corrélation ici. Une grande partie de notre code faisait des choses qui sont très difficiles à faire dans d'autres langages. Le logiciel résultant faisait des choses que le logiciel de nos concurrents ne pouvait pas faire. Peut-être qu'il y avait une sorte de lien. Je vous encourage à suivre cette piste. Il y a peut-être plus à ce vieil homme qui se traîne sur ses béquilles qu'il n'y paraît.

Aikido pour les start-ups

Mais je ne m'attends pas à convaincre qui que ce soit (plus de 25) d'aller apprendre Lisp. Le but de cet article n'est pas de changer l'avis de qui que ce soit, mais de rassurer les personnes déjà intéressées par l'utilisation de Lisp, les personnes qui savent que Lisp est un langage puissant, mais qui s'inquiètent parce qu'il n'est pas largement utilisé. Dans une situation concurrentielle, c'est un avantage. La puissance de Lisp est multipliée par le fait que vos concurrents ne la comprennent pas.

Si vous envisagez d'utiliser Lisp dans une start-up, vous ne devriez pas vous inquiéter qu'il ne soit pas largement compris. Vous devriez espérer qu'il reste ainsi. Et c'est probable. C'est la nature des langages de programmation de rendre la plupart des gens satisfaits de ce qu'ils utilisent actuellement. Le matériel informatique change tellement plus vite que les habitudes personnelles que la pratique de la programmation a généralement dix à vingt ans de retard sur le processeur. Dans des endroits comme le MIT, ils écrivaient des programmes en langages de haut niveau au début des années 1960, mais de nombreuses entreprises ont continué à écrire du code en langage machine jusqu'aux années 1980. Je parie que beaucoup de gens ont continué à écrire du langage machine jusqu'à ce que le processeur, comme un barman impatient de fermer et de rentrer chez lui, finisse par les mettre à la porte en passant à un ensemble d'instructions risc.

En général, la technologie change rapidement. Mais les langages de programmation sont différents : les langages de programmation ne sont pas seulement de la technologie, mais aussi ce à quoi les programmeurs pensent. Ils sont à moitié technologie et à moitié religion. [6] Et donc, le langage médian, c'est-à-dire le langage que le programmeur médian utilise, se déplace aussi lentement qu'un iceberg. La collecte des ordures, introduite par Lisp vers 1960, est maintenant largement considérée comme une bonne chose. Le typage à l'exécution, idem, gagne en popularité. Les fermetures lexicales, introduites par Lisp au début des années 1970, sont maintenant, à peine, sur l'écran radar. Les macros, introduites par Lisp au milieu des années 1960, sont encore terra incognita.

De toute évidence, le langage médian a une énorme inertie. Je ne propose pas que vous puissiez lutter contre cette force puissante. Ce que je propose est exactement le contraire : que, comme un pratiquant de l'Aikido, vous puissez l'utiliser contre vos adversaires.

Si vous travaillez pour une grande entreprise, cela peut ne pas être facile. Vous aurez du mal à convaincre le patron aux cheveux pointus de vous laisser construire des choses en Lisp, alors qu'il vient de lire dans le journal qu'un autre langage est sur le point, comme Ada il y a vingt ans, de prendre le contrôle du monde. Mais si vous travaillez pour une start-up qui n'a pas encore de patrons aux cheveux pointus, vous pouvez, comme nous l'avons fait, tourner le paradoxe de Blub à votre avantage : vous pouvez utiliser une technologie que vos concurrents, collés immobilisés au langage médian, ne seront jamais en mesure d'égaler.

Si vous vous retrouvez un jour à travailler pour une start-up, voici un conseil pratique pour évaluer les concurrents. Lisez leurs offres d'emploi. Tout le reste sur leur site peut être des photos d'archives ou l'équivalent en prose, mais les offres d'emploi doivent être spécifiques sur ce qu'ils veulent, sinon ils obtiendront les mauvais candidats.

Pendant les années où nous avons travaillé sur Viaweb, j'ai lu beaucoup de descriptions de postes. Un nouveau concurrent semblait émerger de nulle part chaque mois environ. La première chose que je faisais, après avoir vérifié s'ils avaient une démo en ligne, c'était de regarder leurs offres d'emploi. Après deux ans de cela, je pouvais dire quelles entreprises devaient m'inquiéter et lesquelles non. Plus les descriptions de postes avaient une saveur informatique, moins l'entreprise était dangereuse. Les plus sûres étaient celles qui voulaient de l'expérience Oracle. Vous n'aviez jamais à vous inquiéter pour celles-là. Vous étiez également en sécurité s'ils disaient qu'ils voulaient des développeurs C++ ou Java. S'ils voulaient des programmeurs Perl ou Python, cela commencerait à être un peu effrayant, cela ressemblait à une entreprise où le côté technique, au moins, était géré par de vrais hackers. Si j'avais jamais vu une offre d'emploi recherchant des hackers Lisp, j'aurais été vraiment inquiet.

Notes

[1] Viaweb avait au début deux parties : l'éditeur, écrit en Lisp, que les gens utilisaient pour construire leurs sites, et le système de commande, écrit en C, qui gérait les commandes. La première version était principalement en Lisp, car le système de commande était petit. Plus tard, nous avons ajouté deux autres modules, un générateur d'images écrit en C, et un gestionnaire de back-office écrit principalement en Perl.

En janvier 2003, Yahoo a publié une nouvelle version de l'éditeur écrit en C++ et en Perl. Il est difficile de dire si le programme n'est plus écrit en Lisp, cependant, car pour traduire ce programme en C++, ils ont littéralement dû écrire un interpréteur Lisp : les fichiers sources de tous les modèles de génération de pages sont toujours, à ma connaissance, du code Lisp. (Voir la dixième règle de Greenspun.)

[2] Robert Morris dit que je n'avais pas besoin d'être secret, car même si nos concurrents avaient su que nous utilisions Lisp, ils n'auraient pas compris pourquoi : "S'ils étaient aussi intelligents, ils programmeraient déjà en Lisp."

[3] Tous les langages sont également puissants dans le sens où ils sont équivalents à Turing, mais ce n'est pas le sens du mot qui intéresse les programmeurs. (Personne ne veut programmer une machine de Turing.) Le type de puissance qui intéresse les programmeurs n'est peut-être pas formellement définissable, mais une façon de l'expliquer serait de dire qu'il fait référence aux fonctionnalités que vous ne pourriez obtenir dans le langage moins puissant qu'en écrivant un interpréteur du langage plus puissant en lui. Si le langage A a un opérateur pour supprimer les espaces des chaînes de caractères et que le langage B ne l'a pas, cela ne rend probablement pas A plus puissant, car vous pouvez probablement écrire une sous-routine pour le faire en B. Mais si A prend en charge, disons, la récursivité, et que B ne le fait pas, il est peu probable que vous puissiez résoudre ce problème en écrivant des fonctions de bibliothèque.

[4] Note aux nerds : ou peut-être un treillis, se rétrécissant vers le haut ; ce n'est pas la forme qui compte ici, mais l'idée qu'il y a au moins un ordre partiel.

[5] Il est un peu trompeur de traiter les macros comme une fonctionnalité distincte. En pratique, leur utilité est grandement renforcée par d'autres fonctionnalités Lisp comme les fermetures lexicales et les paramètres de repos.

[6] En conséquence, les comparaisons de langages de programmation prennent soit la forme de guerres de religion, soit celle de manuels universitaires si déterminés à être neutres qu'ils sont en réalité des œuvres d'anthropologie. Les personnes qui tiennent à leur paix, ou qui veulent obtenir un poste de professeur, évitent le sujet. Mais la question n'est qu'à moitié religieuse ; il y a quelque chose à étudier, surtout si vous voulez concevoir de nouveaux langages.