BATTRE LES MOYENNES

April 2001, rev. April 2003

(Cet article est dérivé d'une conférence donnée au Symposium des Développeurs Franz en 2001.)

À l'été 1995, mon ami Robert Morris et moi avons lancé une startup 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 novateur à l'époque avec ce logiciel, c'est qu'il fonctionnait sur notre serveur, utilisant des pages Web ordinaires comme interface.

Beaucoup de gens auraient pu avoir cette idée en même temps, bien sûr, mais autant que je sache, Viaweb était la première application basée sur le Web. Cela nous semblait une idée si nouvelle que nous avons nommé l'entreprise d'après elle : Viaweb, parce que notre logiciel fonctionnait via le Web, au lieu de s'exécuter sur votre ordinateur de bureau.

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

L'Arme Secrète

Eric Raymond a écrit un essai intitulé "Comment Devenir un Hacker", et dans celui-ci, entre autres choses, il dit aux aspirants hackers quels langages ils devraient apprendre. Il suggère de commencer par Python et Java, car ils sont faciles à apprendre. Le hacker sérieux voudra également apprendre C, afin de pirater Unix, et Perl pour l'administration système et les scripts cgi. Enfin, le hacker 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 le comprendrez enfin ; cette expérience fera de vous un meilleur programmeur pour le reste de vos jours, même si vous n'utilisez jamais vraiment beaucoup Lisp.

C'est le même argument que vous entendez souvent pour apprendre le latin. Cela ne vous donnera pas un emploi, sauf peut-être en tant que professeur de lettres classiques, mais cela 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 va pas si loin. La raison pour laquelle le latin ne vous donnera pas 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 n'importe quel langage que vous, le programmeur, leur dites de parler.

Donc, si Lisp fait de vous un meilleur programmeur, comme il le dit, pourquoi ne voudriez-vous 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 fera de vous un meilleur programmeur, et pourtant vous ne l'utiliserez pas.

Pourquoi pas ? Les langages de programmation ne sont que des outils, après tout. Si Lisp produit vraiment de meilleurs programmes, vous devriez l'utiliser. Et s'il ne le fait pas, alors qui en a besoin ?

Ce n'est pas juste une question théorique. Le logiciel est un domaine très compétitif, sujet à des monopoles naturels. Une entreprise qui fait écrire des logiciels plus rapidement et mieux mettra, toutes choses étant égales par ailleurs, ses concurrents hors d'affaires. Et lorsque vous démarrez une startup, vous ressentez cela très intensément. Les startups ont tendance à être une proposition tout ou rien. Vous devenez riche, ou vous ne gagnez rien. Dans une startup, 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 à nos instincts et de choisir Lisp. Nous savions que tout le monde écrivait son logiciel en C++ ou en Perl. Mais nous savions aussi que cela ne signifiait rien. Si vous choisissiez la technologie de cette manière, vous utiliseriez Windows. Lorsque vous choisissez une technologie, vous devez ignorer ce que font les autres et considérer uniquement ce qui fonctionnera le mieux.

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

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

La même chose se produira si vous dirigez une startup, bien sûr. Si vous faites tout comme le fait la startup moyenne, vous devriez vous attendre à une performance moyenne. Le problème ici est que la performance moyenne signifie que vous allez faire faillite. Le taux de survie des startups est bien inférieur à cinquante pour cent. Donc, si vous dirigez une startup, 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 comprenaient, et peu de gens comprennent même maintenant : lorsque vous écrivez un logiciel qui n'a besoin de fonctionner 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 biais vers l'écriture d'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 à la fois du langage et du système d'exploitation, vous pouvez utiliser n'importe quel langage que vous voulez.

Cette nouvelle liberté est cependant une arme à double tranchant. Maintenant que vous pouvez utiliser n'importe quel langage, vous devez réfléchir à celui à utiliser. Les entreprises qui essaient de faire comme si rien n'avait changé risquent de découvrir 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 réaliser 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 le logiciel dès qu'il est terminé.

Si d'autres entreprises ne voulaient pas utiliser Lisp, tant mieux. Cela pourrait nous donner un avantage technologique, et nous avions besoin de toute l'aide possible. Lorsque nous avons commencé Viaweb, nous n'avions aucune expérience en affaires. Nous ne savions rien sur le marketing, l'embauche de personnes, la collecte de fonds ou l'acquisition de clients. Aucun de nous n'avait même jamais eu ce que vous appelleriez un vrai travail. La seule chose à laquelle nous étions bons était d'écrire des logiciels. Nous espérions que cela nous sauverait. Tout avantage que nous pouvions obtenir dans le domaine du logiciel, nous le prendrions.

Donc, on pourrait 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 réaliser 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 si haut niveau, nous n'aurions pas besoin d'une grande équipe de développement, donc nos coûts seraient plus bas. Si cela était vrai, nous pourrions offrir un meilleur produit pour moins d'argent, et tout en réalisant un profit. Nous finirions par obtenir tous les utilisateurs, et nos concurrents n'en obtiendraient aucun, et finiraient par faire faillite. C'était ce que nous espérions, de toute façon.

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

Il devait sembler à nos concurrents que nous avions une sorte d'arme secrète - que nous déchiffrions leur trafic Enigma ou quelque chose comme ça. En fait, nous avions une arme secrète, mais elle était plus simple qu'ils ne le réalisaient. Personne ne fuyait des nouvelles de leurs fonctionnalités vers nous. 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 l'occasion de mettre la main sur un exemplaire de Le Jour du Chacal, de Frederick Forsyth. Le personnage principal est un assassin engagé pour tuer le président de la France. L'assassin doit passer la police pour accéder à un appartement qui surplombe le parcours du président. Il passe juste à côté d'eux, déguisé en vieil homme avec des béquilles, et ils ne le soupçonnent jamais.

Notre arme secrète était similaire. Nous avons écrit notre logiciel dans un langage d'IA étrange, avec une syntaxe bizarre pleine de parenthèses. Pendant des années, cela m'a agacé d'entendre Lisp décrit de cette manière. 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 en guerre, la surprise vaut autant que la force.

Et donc, j'ai un peu honte de dire que je n'ai jamais dit quoi que ce soit 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 serait les titres de deux livres dans ma biographie. Ce n'était pas un accident. Une startup devrait donner à ses concurrents le moins d'informations possible. S'ils ne savaient pas dans quel langage notre logiciel était écrit, ou 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 des boutiques en ligne d'une apparence superbe en quelques minutes. Et donc, par le bouche-à-oreille principalement, 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 achetés, nous avions 1070 utilisateurs. Aujourd'hui, en tant que Yahoo Store, ce logiciel continue de dominer son marché. C'est l'un des éléments les plus rentables de Yahoo, et les boutiques construites avec lui sont la base 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, il y en avait environ 20 000.

Le Paradoxe Blub

Qu'est-ce qui est si génial avec Lisp ? Et si Lisp est si génial, pourquoi tout le monde ne l'utilise-t-il pas ? Cela semble être des questions rhétoriques, mais en réalité, elles ont des réponses simples. Lisp est si génial non pas à cause d'une qualité magique visible uniquement pour 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 de pensée, et rien ne change plus lentement. Bien sûr, ces deux réponses nécessitent des explications.

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 aujourd'hui conviendraient que vous ne voulez pas, ordinairement, programmer en langage machine. Au lieu de cela, vous devriez programmer dans un langage de haut niveau, et faire traduire cela en langage machine par un compilateur. 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 qu'il est une erreur d'écrire tout votre programme à la main en langage machine. Ce qui est moins souvent compris, c'est qu'il existe 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 n'a besoin de faire quelque chose de très simple, comme du traitement de nombres ou de la manipulation de bits, vous pouvez aussi bien utiliser un langage moins abstrait, surtout s'il peut être légèrement plus rapide. Et si vous écrivez un court programme jetable, vous pourriez être mieux loti en utilisant simplement le langage qui a les meilleures fonctions de bibliothèque pour la tâche. Mais en général, pour les logiciels d'application, vous voulez utiliser le langage le plus puissant (raisonnablement efficace) que vous puissiez obtenir, et utiliser autre chose est une erreur, du même type, bien que peut-être dans une moindre mesure, que de programmer 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. Ce n'est pas le cas. Techniquement, le terme "langage de haut niveau" ne signifie rien de très défini. 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 tombent le long d'un continuum [4] d'abstraction, du plus puissant jusqu'aux langages machine, qui eux-mêmes varient en puissance.

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

Ou que dire de Perl 4 ? Entre Perl 4 et Perl 5, des fermetures lexicales ont été ajoutées au langage. La plupart des hackers Perl conviendraient 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 inéluctablement que, sauf dans des cas particuliers, vous devriez utiliser le plus puissant que vous pouvez obtenir.

Cette idée n'est cependant que rarement suivie jusqu'à sa conclusion. Après un certain âge, les programmeurs changent rarement de langage volontairement. Quel que soit le langage auquel les gens sont habitués, ils ont tendance à le considérer comme juste assez 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 en ce qui concerne Cobol, il ne comprend pas comment quiconque peut accomplir quoi que ce soit avec. Il n'a même pas x (fonction Blub de votre choix).

Tant que notre programmeur Blub hypothétique regarde vers le bas du 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 direction, vers le haut du continuum de puissance, il ne réalise pas qu'il regarde vers le haut. Ce qu'il voit, ce sont simplement des langages étranges. Il les considère probablement comme à peu près équivalents en puissance à Blub, mais avec tout ce reste de trucs bizarres en plus. Blub est suffisant pour lui, car il pense en Blub.

Lorsque nous passons au point de vue d'un programmeur utilisant l'un des langages plus puissants, cependant, nous découvrons qu'il regarde à son tour Blub de haut. Comment pouvez-vous accomplir 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 que voulait dire Eric Raymond à propos de Lisp vous rendant meilleur programmeur.) Vous ne pouvez pas faire confiance aux opinions des autres, à cause du paradoxe Blub : ils sont satisfaits de n'importe quel langage qu'ils utilisent, car cela dicte la façon dont ils pensent aux programmes.

Je sais cela par ma propre expérience, en tant que lycéen écrivant des programmes en Basic. Ce langage ne supportait même pas la récursion. Il est difficile d'imaginer écrire des programmes sans utiliser la récursion, mais cela ne me manquait pas à 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 à divers points sur le continuum de puissance. Leur position relative est un sujet sensible. Ce que je dirai, c'est que je pense que Lisp est au sommet. Et pour soutenir cette affirmation, je vais vous parler de l'une des choses qui me manquent lorsque je regarde les quatre autres langages. Comment pouvez-vous accomplir quoi que ce soit en eux, je pense, 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 semble étrange. 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 composé d'objets de données Lisp. Et pas dans le sens trivial que les fichiers source contiennent des caractères, et que les chaînes sont l'un des types de données pris en charge par le langage. Le code Lisp, après avoir été lu par le parseur, est constitué 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 de syntaxe qui sont générés dans le compilateur lorsque d'autres langages sont analysés. Mais ces arbres de syntaxe sont entièrement accessibles à vos programmes. Vous pouvez écrire des programmes qui les manipulent. En Lisp, ces programmes s'appellent des macros. Ce sont des programmes qui écrivent des programmes.

Des programmes qui écrivent des programmes ? Quand voudriez-vous jamais faire cela ? Pas très souvent, si vous pensez en Cobol. Tout le temps, si vous pensez en Lisp. Il serait pratique ici que je puisse donner un exemple d'une macro puissante, et dire voilà ! que diriez-vous de ça ? Mais si je le faisais, cela semblerait juste être 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 signifiait. Dans Ansi Common Lisp, j'ai essayé d'avancer aussi vite que possible, et même ainsi, je n'ai pas atteint 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 était probablement composé d'environ 20 à 25 % de macros. Les macros sont plus difficiles à écrire que les fonctions Lisp ordinaires, et il est considéré comme un mauvais style 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 que cela signifie, c'est qu'au moins 20 à 25 % du code de ce programme fait des choses que vous ne pouvez pas facilement faire dans n'importe quel autre langage. Quel que soit le scepticisme que le programmeur Blub pourrait avoir à 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 startup, programmant aussi dur que nous le pouvions pour mettre des barrières techniques entre nous et nos concurrents.

Une personne méfiante pourrait commencer à se demander s'il y avait une certaine 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 y avait-il une sorte de connexion. Je vous encourage à suivre ce fil. Il pourrait y avoir plus à cet ancien homme boitant sur ses béquilles qu'il n'y paraît.

Aikido pour Startups

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 quiconque, mais de rassurer les personnes déjà intéressées par l'utilisation de Lisp - des personnes qui savent que Lisp est un langage puissant, mais s'inquiètent parce qu'il n'est pas largement utilisé. Dans une situation compétitive, c'est un avantage. La puissance de Lisp est multipliée par le fait que vos concurrents ne le comprennent pas.

Si vous envisagez d'utiliser Lisp dans une startup, vous ne devriez pas vous inquiéter qu'il ne soit pas largement compris. Vous devriez espérer que cela reste ainsi. Et c'est probablement le cas. 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 rapidement que les habitudes personnelles que la pratique de la programmation est généralement en retard de dix à vingt ans par rapport au processeur. Dans des endroits comme le MIT, ils écrivaient des programmes dans des langages de haut niveau au début des années 1960, mais de nombreuses entreprises ont continué à écrire du code en langage machine jusqu'à bien dans les années 1980. Je parie que beaucoup de gens ont continué à écrire en langage machine jusqu'à ce que le processeur, comme un barman désireux de fermer et de rentrer chez lui, les ait finalement expulsés en passant à un ensemble d'instructions RISC.

Ordinairement, la technologie change rapidement. Mais les langages de programmation sont différents : les langages de programmation ne sont pas seulement une technologie, mais ce dans quoi les programmeurs pensent. Ils sont à moitié technologie et à moitié religion. [6] Et donc, le langage médian, signifiant quel que soit le langage utilisé par le programmeur médian, se déplace aussi lentement qu'un iceberg. La collecte des déchets, introduite par Lisp vers 1960, est maintenant largement considérée comme une bonne chose. Le typage à l'exécution, de même, gagne en popularité. Les fermetures lexicales, introduites par Lisp au début des années 1970, sont maintenant, tout juste, sur le radar. Les macros, introduites par Lisp au milieu des années 1960, sont encore terra incognita.

Évidemment, le langage médian a un énorme élan. Je ne propose pas que vous puissiez lutter contre cette force puissante. Ce que je propose est exactement le contraire : que, comme un pratiquant d'Aikido, vous puissiez 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 prêt, comme Ada l'était il y a vingt ans, à conquérir le monde. Mais si vous travaillez pour une startup qui n'a pas encore de patrons aux cheveux pointus, vous pouvez, comme nous l'avons fait, tourner le paradoxe Blub à votre avantage : vous pouvez utiliser une technologie que vos concurrents, collés immuablement au langage médian, ne pourront jamais égaler.

Si jamais vous vous retrouvez à travailler pour une startup, voici un conseil pratique pour évaluer les concurrents. Lisez leurs offres d'emploi. Tout le reste sur leur site peut être des photos de stock 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.

Au cours des années où nous avons travaillé sur Viaweb, j'ai lu beaucoup de descriptions de postes. Un nouveau concurrent semblait émerger de nulle part tous les mois environ. La première chose que je faisais, après avoir vérifié s'ils avaient une démo en ligne active, était de regarder leurs offres d'emploi. Après quelques années de cela, je pouvais dire quelles entreprises devaient m'inquiéter et lesquelles ne devaient pas. Plus les descriptions de postes avaient une saveur informatique, moins l'entreprise était dangereuse. Le type le plus sûr était celui qui voulait de l'expérience Oracle. Vous n'aviez jamais à vous inquiéter de ceux-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 serait un peu inquiétant - cela commence à ressembler à une entreprise où le côté technique, du moins, est dirigé par de vrais hackers. Si j'avais jamais vu une offre d'emploi cherchant des hackers Lisp, j'aurais été vraiment inquiet.

Notes

[1] Viaweb avait d'abord 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 écrite en C++ et 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 source de tous les modèles de génération de pages sont toujours, autant que je sache, 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 si intelligents, ils programmeraient déjà en Lisp."

[3] Tous les langages sont également puissants dans le sens d'être équivalents de 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 peut ne pas être formellement définissable, mais une façon de l'expliquer serait de dire qu'il se réfère à des fonctionnalités que vous ne pourriez obtenir dans le langage moins puissant qu'en écrivant un interpréteur pour le langage plus puissant dans celui-ci. Si le langage A a un opérateur pour supprimer les espaces des chaînes et que le langage B n'en a pas, cela ne rend probablement pas A plus puissant, car vous pouvez probablement écrire une sous-routine pour le faire dans B. Mais si A prend en charge, disons, la récursion, et que B ne le fait pas, ce n'est pas quelque chose que vous pouvez corriger en écrivant des fonctions de bibliothèque.

[4] Note pour les nerds : ou peut-être un réseau, se rétrécissant vers le haut ; ce n'est pas la forme qui compte ici mais l'idée qu'il existe 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 améliorée par d'autres fonctionnalités de Lisp comme les fermetures lexicales et les paramètres restants.

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