BATTRE LES MOYENNES

Avril 2001, rév. Avril 2003

(Cet article est dérivé d'un discours prononcé lors du Symposium des développeurs Franz de 2001.)

À l'été 1995, mon ami Robert Morris et moi avons démarré 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 dans ce logiciel, à l'époque, c'est qu'il s'exécutait 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 a été la première application Web. L'idée nous semblait tellement 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 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é 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 hacker", et dans celui-ci, entre autres choses, il indique aux futurs 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, pour 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 pas beaucoup Lisp lui-même par la suite.

C'est le même argument que l'on a tendance à entendre pour apprendre le latin. Cela ne vous procurera pas d'emploi, sauf peut-être en tant que professeur de lettres classiques, mais cela améliorera votre esprit et vous rendra un meilleur écrivain dans les langues que vous voulez utiliser, comme l'anglais.

Mais attendez une minute. Cette métaphore ne va pas aussi loin. La raison pour laquelle le latin ne vous procurera pas d'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 vous rend un meilleur programmeur, comme il le dit, pourquoi ne voudriez-vous pas l'utiliser ? Si un peintre se voyait offrir un pinceau qui le rendrait un meilleur peintre, il me semble qu'il voudrait l'utiliser dans tous ses tableaux, n'est-ce pas ? Je ne cherche pas à me moquer d'Eric Raymond ici. Dans l'ensemble, ses conseils sont bons. Ce qu'il dit sur Lisp est à peu près la sagesse conventionnelle. Mais il y a une contradiction dans la sagesse conventionnelle : Lisp vous rendra un meilleur programmeur, et pourtant vous ne l'utiliserez pas.

Pourquoi pas ? Après tout, les langages de programmation ne sont que des outils. Si Lisp produit vraiment de meilleurs programmes, vous devriez l'utiliser. Et s'il n'en est pas ainsi, alors qui en a besoin ?

Ce n'est pas seulement une question théorique. Le logiciel est un secteur très concurrentiel, sujet aux monopoles naturels. Une entreprise qui écrit des logiciels plus rapidement et mieux mettra, toutes choses égales par ailleurs, ses concurrents hors jeu. Et quand vous démarrez une startup, vous le ressentez très vivement. Les startups ont tendance à être une proposition tout ou rien. Vous devenez riche, ou vous n'obtenez rien. Dans une startup, si vous misez 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 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 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 s'en rendent compte, même dans les startups.

La moyenne des grandes entreprises croît d'environ dix pour cent par an. Donc si vous dirigez une grande entreprise et que vous faites tout comme la moyenne des grandes entreprises, vous pouvez vous attendre à aussi bien faire que la moyenne des grandes entreprises - 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 la moyenne des startups, vous devriez vous attendre à une performance moyenne. Le problème ici est que la performance moyenne signifie que vous irez hors entreprise. 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'étrange. Sinon, vous êtes dans le pétrin.

En 1995, nous savions quelque chose que je ne pense pas que nos concurrents aient compris, et peu comprennent même maintenant : lorsque vous écrivez un logiciel qui ne doit 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 une forte tendance à écrire des applications dans la même langue que le système d'exploitation. Il y a dix ans, écrire des applications signifiait écrire des applications en C. Mais avec les logiciels Web, surtout quand vous avez le code source du langage et du système d'exploitation, vous pouvez utiliser n'importe quel langage que vous voulez.

Cette nouvelle liberté est une épée à double tranchant, cependant. Maintenant que vous pouvez utiliser n'importe quel langage, vous devez réfléchir à celui à utiliser. Les entreprises qui essaient de faire croire que rien n'a 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. Pour commencer, il était évident que le développement rapide serait important sur ce marché. Nous partions tous de zéro, donc une entreprise qui pourrait faire de nouvelles fonctionnalités avant ses concurrents aurait un gros avantage. Nous savions que Lisp était un très bon langage pour écrire rapidement des logiciels, et les applications basées sur le serveur amplifient l'effet du développement rapide, car vous pouvez publier un 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. Quand nous avons démarré Viaweb, nous n'avions aucune expérience dans les affaires. Nous ne savions rien du marketing, de l'embauche de personnes, de la levée de fonds ou de l'acquisition de clients. Aucun de nous n'avait même eu ce qu'on appellerait un vrai emploi. La seule chose que nous savions faire était d'écrire des logiciels. Nous espérions que cela nous sauverait. Tout avantage que nous pourrions obtenir dans le domaine des logiciels, 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 en mesure de réaliser des fonctionnalités plus rapidement que nos concurrents, et aussi de faire des choses dans notre logiciel qu'ils ne pourraient pas faire. Et comme Lisp était tellement de haut niveau, nous n'aurions pas besoin d'une grande équipe de développement, donc nos coûts seraient plus faibles. Si c'était le cas, nous pourrions offrir un meilleur produit pour moins cher, tout en réalisant des bénéfices. Nous finirions par avoir tous les utilisateurs, et nos concurrents n'en auraient aucun, et finiraient par faire faillite. C'est ce qui devait se passer, en tout cas.

Quels ont été les résultats de cette expérience ? Assez é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 créateur de boutiques en ligne wysiwyg qui fonctionnait sur le serveur et pourtant avait l'air d'une application de bureau. Nos concurrents avaient des scripts cgi. Et nous étions toujours bien en avance sur eux en termes de fonctionnalités. Parfois, dans un élan de 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'ait annoncée dans un communiqué de presse. Au moment où les journalistes couvrant le communiqué de presse nous appelaient, nous avions aussi la nouvelle fonctionnalité.

Cela a dû sembler à nos concurrents que nous avions une sorte d'arme secrète - que nous décodions leur trafic Enigma ou quelque chose comme ça. En fait, nous avions bien une arme secrète, mais elle était plus simple qu'ils ne le pensaient. Personne ne nous divulguait les nouvelles de leurs fonctionnalités. Nous étions juste 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 me procurer 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 outre la police pour atteindre un appartement qui domine l'itinéraire 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 étrange langage d'IA, avec une syntaxe bizarre remplie de parenthèses. Pendant des années, cela m'a agacé d'entendre Lisp décrit de cette façon. Mais maintenant, cela jouait en notre faveur. Dans les 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, je suis un peu gêné de le dire, je n'ai jamais rien dit publiquement sur Lisp pendant que nous travaillions sur Viaweb. Nous n'en avons jamais parlé à la presse, et si vous aviez cherché Lisp sur notre site Web, tout ce que vous auriez trouvé, ce sont les titres de deux livres dans ma biographie. Ce n'était pas un accident. Une startup ne doit fournir à ses concurrents que le minimum d'informations possible. S'ils ne savaient pas dans quel langage notre logiciel était écrit, ou s'ils s'en fichaient, 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é qu'il fonctionnait vraiment bien. Cela leur permettait de construire de superbes boutiques en ligne en quelques minutes seulement. Et donc, principalement par le bouche-à-oreille, nous avons gagné de plus en plus d'utilisateurs. Fin 1996, nous avions environ 70 boutiques en ligne. Fin 1997, nous en avions 500. Six mois plus tard, quand Yahoo nous a rachetés, nous avions 1070 utilisateurs. Aujourd'hui, sous le nom de 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 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'en ai entendu parler, il y en avait environ 20 000.

Le paradoxe de Blub

Qu'est-ce qui est si génial dans Lisp ? Et si Lisp est si génial, pourquoi tout le monde ne l'utilise-t-il pas ? Ces questions semblent rhétoriques, mais en fait, elles ont des réponses simples. Lisp est si génial, non pas à cause d'une quelconque qualité magique visible seulement 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, c'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 commencerai par une déclaration choquante : les langages de programmation varient en puissance.

Peu de gens contesteraient, du moins, que les langages de haut niveau sont plus puissants que le langage machine. La plupart des programmeurs d'aujourd'hui conviendraient que vous ne voulez pas, en règle générale, programmer en langage machine. Au lieu de cela, vous devriez programmer dans un langage de haut niveau et faire traduire votre code 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 jeux 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 : si vous avez le choix entre plusieurs langages, c'est, toutes choses égales par ailleurs, une erreur de programmer dans autre chose que le plus puissant d'entre eux.[3]

Il y a 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 peut ê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 du calcul numérique 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 programme court et jetable, vous serez peut-être mieux servi en utilisant 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 pouvez obtenir, et utiliser autre chose est une erreur, exactement du même type, bien que peut-être à un moindre degré, que de programmer en langage machine.

Vous pouvez voir que le langage machine est très bas niveau. Mais, au moins en tant que sorte de convention sociale, les langages de haut niveau sont souvent tous considéré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 sur un continuum [4] d'abstraction, du plus puissant jusqu'aux langages machine, qui varient eux-mêmes en puissance.

Prenons le cas du Cobol. Le Cobol est un langage de haut niveau, dans le sens où il est compilé en langage machine. Quelqu'un soutiendrait-il sérieusement que le Cobol est équivalent en puissance au Python, par exemple ? Il est probablement plus proche du langage machine que le Python.

Ou que dire du Perl 4 ? Entre le Perl 4 et le Perl 5, les fermetures lexicales ont été ajoutées au langage. La plupart des hackers Perl conviendraient que le Perl 5 est plus puissant que le Perl 4. Mais une fois que vous l'avez admis, 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 volontairement de langage. Quel que soit le langage auquel les gens sont habitués, ils ont tendance à le considérer comme tout juste suffisant.

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 le 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 le rôle des compilateurs. Et quant au Cobol, il ne comprend pas comment on peut faire quoi que ce soit avec. Il n'a même pas la fonctionnalité x (fonctionnalité 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 quand 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 sont simplement des langages bizarres. Il les considère probablement à peu près équivalents en puissance à Blub, mais avec tout ce autre truc bizarre en plus. Blub lui convient, 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 peut-on faire quoi que ce soit en Blub ? Il n'a même pas la fonctionnalité 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 d'entre eux. (C'est probablement ce que voulait dire Eric Raymond sur 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 sais cela par ma propre expérience, en tant qu'adolescent é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 me suis pas senti manquer à l'époque. Je pensais en Basic. Et j'étais un as dans ce domaine. Maître de tout ce que je survolais.

Les cinq langages qu'Eric Raymond recommande aux hackers se situent à différents points du continuum de puissance. Où ils se situent les uns par rapport 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 vous parlerai d'une des choses que je trouve manquantes lorsque je regarde les quatre autres langages. Comment peut-on faire quoi que ce soit sans macros ? [5]

Beaucoup de 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 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 de caractères sont l'un des types de données pris en charge par le langage. Le code Lisp, après avoir été lu par l'analyseur, est composé de structures de données que vous pouvez parcourir.

Si vous comprenez comment fonctionnent les compilateurs, ce qui se passe vraiment, ce 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 à l'intérieur 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 s'appellent des 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. Il serait pratique ici si je pouvais donner un exemple de macro puissante, et dire là ! qu'est-ce que vous en pensez ? Mais si je le faisais, ça ressemblerait juste à du charabia pour quelqu'un qui ne connaît pas Lisp ; il n'y a pas assez de place ici pour expliquer tout ce que vous auriez besoin de savoir pour comprendre ce que ça signifie. Dans Ansi Common Lisp, j'ai essayé d'aller aussi vite que possible, et même ainsi, je n'en suis pas arrivé aux 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é à 20-25% de macros. Les macros sont plus difficiles à écrire que les fonctions Lisp ordinaires, et on considère que c'est un mauvais style de les utiliser quand elles ne sont pas nécessaires. Donc chaque macro de ce code est là parce qu'elle doit l'être. Cela signifie qu'au moins 20-25% de ce programme fait des choses qu'on ne peut pas facilement faire dans un autre langage. Quelque sceptique que puisse être le programmeur Blub sur mes affirmations concernant les pouvoirs mystérieux de Lisp, cela devrait le rendre curieux. Nous n'écrivions pas ce code pour notre propre amusement. Nous étions une toute petite startup, programmant aussi dur que possible afin de mettre des barrières techniques entre nous et nos concurrents.

Une personne suspicieuse 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 qui en résultait faisait des choses que le logiciel de nos concurrents ne pouvait pas faire. Peut-être qu'il y avait un lien. Je vous encourage à suivre ce fil. Il peut y avoir plus dans cet homme âgé qui boite sur ses béquilles que ce qui paraît.

Aikido pour les startups

Mais je ne m'attends pas à convaincre qui que ce soit (de plus de 25 ans) d'aller apprendre Lisp. Le but de cet article n'est pas de changer l'avis de quelqu'un, mais de rassurer les gens déjà intéressés par l'utilisation de Lisp - les gens 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 le comprennent pas.

Si vous pensez à utiliser Lisp dans une startup, vous ne devriez pas vous inquiéter qu'il ne soit pas largement compris. Vous devriez espérer que ça reste ainsi. Et c'est probablement le cas. C'est la nature des langages de programmation de satisfaire la plupart des gens avec ce qu'ils utilisent actuellement. Le matériel informatique évolue beaucoup plus rapidement que les habitudes personnelles, de sorte que la pratique de la programmation est généralement dix à vingt ans en retard sur le 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'au milieu des années 1980. Je parie qu'un bon nombre de gens ont continué à écrire du langage machine jusqu'à ce que le processeur, comme un barman pressé de fermer et de rentrer chez lui, les mette finalement à la porte en passant à un jeu d'instructions risc.

Normalement, la technologie évolue rapidement. Mais les langages de programmation sont différents : les langages de programmation ne sont pas seulement de la technologie, mais ce à quoi les programmeurs pensent. Ils sont à moitié technologie et à moitié religion.[6] Et donc la langue médiane, c'est-à-dire quelle que soit la langue 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 dynamique, pareil, gagne en popularité. Les fermetures lexicales, introduites par Lisp au début des années 1970, sont maintenant, tout juste, sur l'écran radar. Les macros, introduites par Lisp au milieu des années 1960, sont encore terra incognita.

Évidemment, la langue médiane a un énorme élan. Je ne propose pas que vous puissiez combattre cette force puissante. Ce que je propose est exactement l'inverse : que, comme un pratiquant de l'Aïkido, vous puissiez l'utiliser contre vos adversaires.

Si vous travaillez pour une grande entreprise, ce ne sera peut-être pas facile. Vous aurez du mal à convaincre le patron à tête pointue de vous laisser construire des choses en Lisp, quand il vient de lire dans le journal qu'une autre langue est sur le point, comme Ada il y a vingt ans, de conquérir le monde. Mais si vous travaillez pour une startup qui n'a pas encore de patrons à tête pointue, vous pouvez, comme nous l'avons fait, retourner le paradoxe de Blub à votre avantage : vous pouvez utiliser une technologie que vos concurrents, collés de manière immuable à la langue médiane, ne pourront jamais égaler.

Si vous vous retrouvez un jour à travailler pour une startup, voici un bon conseil pour évaluer vos 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.

Pendant les années où nous avons travaillé sur Viaweb, j'ai lu beaucoup d'annonces d'emploi. Un nouveau concurrent semblait émerger du bois tous les mois ou presque. 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 il fallait s'inquiéter et lesquelles non. Plus les descriptions de poste avaient une saveur de TI, 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 de 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 serait un peu effrayant - cela commence à ressembler à une entreprise où le côté technique, au moins, est dirigé par de vrais hackers. Si j'avais jamais vu une offre d'emploi à la recherche de hackers Lisp, j'aurais vraiment été 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 surtout 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 encore, à ma connaissance, du code Lisp. (Voir 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] Toutes les langues sont également puissantes dans le sens d'être équivalentes à 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 fait référence à des fonctionnalités que vous ne pourriez obtenir dans la langue la moins puissante qu'en écrivant un interpréteur de la langue la plus puissante en elle. Si le langage A a un opérateur pour supprimer les espaces des chaînes de caractères 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écursivité, et que B ne le fait pas, ce n'est probablement pas quelque chose que vous pouvez corriger en écrivant des fonctions de bibliothèque.

[4] Note aux geeks : ou éventuellement 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 améliorée par d'autres fonctionnalités Lisp comme les fermetures lexicales et les paramètres rest.

[6] En conséquence, les comparaisons de langages de programmation prennent soit la forme de guerres de religion, soit de manuels universitaires si résolument neutres qu'ils sont en réalité des œuvres d'anthropologie. Les gens qui apprécient leur paix ou qui veulent une permanence évitent le sujet. Mais la question n'est qu'à moitié religieuse ; il y a quelque chose là qui vaut la peine d'être étudié, surtout si vous voulez concevoir de nouveaux langages.