Dépasser les moyennes | Essais de Paul Graham

Envie de créer une startup ? Faites-vous financer par Y Combinator.

Avril 2001, rév. 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 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 nouveau avec ce logiciel, à l'époque, c'est qu'il fonctionnait 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 a semblé 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 particularité 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 grand public à ê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é « How to Become a Hacker », et il y explique, entre autres choses, 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 le C, pour hacker 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 maîtriserez enfin ; cette expérience fera de vous un meilleur programmeur pour le reste de vos jours, même si vous n'utilisez jamais beaucoup Lisp lui-même.

C'est le même argument que l'on entend souvent pour apprendre le latin. Cela ne vous donnera pas un emploi, sauf peut-être comme 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 s'étend pas aussi 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 la langue que vous, le programmeur, leur dites de parler.

Alors, si Lisp fait de vous un meilleur programmeur, comme il le dit, pourquoi ne voudriez-vous pas l'utiliser ? Si l'on offrait à un peintre 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 sur Lisp est à peu près la sagesse conventionnelle. Mais il y a une contradiction dans cette sagesse conventionnelle : Lisp fera de vous 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 produit 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 secteur très compétitif, sujet aux monopoles naturels. Une entreprise qui développe des logiciels plus rapidement et mieux, toutes choses égales par ailleurs, mettra ses concurrents hors d'état de nuire. Et lorsque vous lancez une startup, vous le ressentez très fortement. Les startups ont tendance à être une proposition tout ou rien. Soit vous devenez riche, soit 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 signifiait rien. 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 le réalisent, 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 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 la startup moyenne, vous devriez vous attendre à une performance moyenne. Le problème ici est que la performance moyenne signifie que vous ferez 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 nos concurrents ne comprenaient pas, et que peu comprennent encore aujourd'hui : lorsque vous écrivez un logiciel qui n'a qu'à fonctionner 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 les 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 cependant une arme à double tranchant. Maintenant que vous pouvez utiliser n'importe quel langage, vous devez réfléchir à celui à utiliser. Les entreprises qui tentent 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 pourrait implémenter 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 serveur 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 lancé Viaweb, nous n'avions aucune expérience en affaires. Nous ne savions rien du marketing, de l'embauche de personnel, de la levée de fonds ou de l'acquisition de clients. Aucun de nous n'avait même jamais eu ce que l'on appellerait un vrai travail. La seule chose pour laquelle nous étions bons était l'écriture de logiciels. Nous espérions que cela nous sauverait. Tout avantage que nous pourrions obtenir dans le domaine logiciel, nous le prendrions.

On pourrait donc 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 d'implémenter des fonctionnalités plus rapidement que nos concurrents, et aussi de faire des choses dans notre logiciel qu'ils ne pourraient 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 tel était le cas, nous pourrions offrir un meilleur produit pour moins cher, tout en réalisant un profit. Nous finirions par obtenir tous les utilisateurs, et nos concurrents n'en auraient aucun, et finiraient par faire faillite. C'est ce que nous espérions qu'il se produirait, en tout cas.

Quels ont été les résultats de cette expérience ? De manière assez surprenante, 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 donnait pourtant l'impression d'être une application de bureau. Nos concurrents avaient des scripts cgi. Et nous étions toujours loin devant eux en termes de fonctionnalités. Parfois, en désespoir de cause, les 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é 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 aurions aussi la nouvelle fonctionnalité.

Il 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 réalisaient. Personne ne nous divulguait les nouvelles de 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, je suis tombé sur un exemplaire de Le Chacal, de Frederick Forsyth. Le personnage principal est un assassin engagé pour tuer le président de la France. L'assassin doit passer devant la police pour atteindre un appartement qui surplombe le trajet 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'avait agacé d'entendre Lisp décrit de cette façon. Mais maintenant, cela jouait 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, 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 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 startup devrait donner le moins d'informations possible à ses concurrents. S'ils ne savaient pas dans quel langage notre logiciel était écrit, ou s'ils s'en moquaient, 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 très bien. Cela leur permettait de créer de superbes boutiques en ligne littéralement en quelques minutes. Et ainsi, principalement par le bouche-à-oreille, nous avons eu 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, 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 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 de Blub

Qu'est-ce qui rend Lisp si génial ? Et si Lisp est si génial, pourquoi tout le monde ne l'utilise-t-il pas ? Ces questions semblent rhétoriques, mais elles ont en fait des réponses simples. Lisp est si génial non pas à cause d'une qualité magique visible uniquement par les initiés, mais parce que c'est 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 commencerai par une affirmation étonnamment controversée : 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 aujourd'hui conviendraient 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 laisser un compilateur le traduire en langage machine pour vous. Cette idée est même intégrée au 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 son 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 égales par ailleurs, une erreur de programmer dans autre chose que le plus puissant. [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 pourrait être judicieux d'écrire le nouveau programme dans le même langage. Si vous écrivez un programme qui n'a qu'à faire 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, d'autant plus qu'il peut être légèrement plus rapide. Et si vous écrivez un programme court et jetable, il peut être préférable d'utiliser simplement le langage qui possède 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, du même genre, bien que peut-être à un degré moindre, que de programmer en langage machine.

Vous pouvez voir que le langage machine est de très bas niveau. Mais, au moins comme une sorte de 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.

Considérez Cobol. Cobol est un langage de haut niveau, dans le sens où il est compilé en langage machine. Quelqu'un soutiendrait-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 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 inexorablement que, sauf cas particuliers, vous devriez utiliser le plus puissant que vous puissiez obtenir.

Cette idée est cependant rarement poussée 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 suffisant.

Les programmeurs s'attachent beaucoup à leurs langages préférés, et je ne veux blesser personne, alors pour expliquer ce point, je vais utiliser un langage hypothétique appelé Blub. Blub se situe en plein 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 aucun des deux. 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 de 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 il leur manque une fonctionnalité à laquelle 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 sont simplement des langages étranges. Il les considère probablement comme à peu près équivalents en puissance à Blub, mais avec toutes ces autres choses compliquées en plus. Blub lui suffit, parce qu'il pense en Blub.

Lorsque nous passons au point de vue d'un programmeur utilisant l'un des langages plus haut sur 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 de 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 en affirmant 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 leur façon de penser les programmes.

Je le sais par ma propre expérience, en tant qu'adolescent é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. Maître de tout ce que je voyais.

Les cinq langages qu'Eric Raymond recommande aux hackers se situent à divers points du 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 étayer cette affirmation, je vais vous parler de l'une des choses qui me manquent lorsque je regarde les quatre autres langages. Comment peut-on faire quoi que ce soit avec 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 non pas dans le sens trivial où les fichiers source contiennent des caractères, et les chaînes de caractères sont l'un des types de données supportés par le langage. Le code Lisp, après avoir été lu par l'analyseur syntaxique, est composé de structures de données que vous pouvez parcourir.

Si vous comprenez comment fonctionnent les compilateurs, ce qui se passe réellement n'est pas tant que Lisp a une syntaxe étrange, mais plutôt que Lisp n'a pas de syntaxe. Vous écrivez des programmes dans les arbres d'analyse syntaxique qui sont générés au sein du compilateur lorsque d'autres langages sont analysés. Mais ces arbres d'analyse syntaxique 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 cela ? Pas très souvent, si vous pensez en Cobol. Tout le temps, si vous pensez en Lisp. Il serait pratique ici de pouvoir donner un exemple de macro puissante, et de dire : voilà ! qu'en pensez-vous ? Mais si je le faisais, cela ressemblerait juste à 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é d'avancer aussi vite que possible, et même ainsi, je n'ai abordé les macros qu'à la page 160.

Mais je pense pouvoir donner un 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 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. Cela 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. Aussi sceptique que le programmeur Blub puisse être quant à mes affirmations sur les pouvoirs mystérieux de Lisp, cela devrait le rendre curieux. Nous n'écrivions pas ce code pour notre propre plaisir. Nous étions une petite startup, programmant aussi dur que possible afin de créer des barrières techniques entre nous et nos concurrents.

Une personne suspicieuse pourrait commencer à se demander s'il n'y avait pas 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 les logiciels de nos concurrents ne pouvaient pas faire. Peut-être y avait-il une sorte de lien. Je vous encourage à suivre cette piste. Il y a peut-être plus à cet vieil homme boitant avec ses béquilles qu'il n'y paraît.

Aïkido pour 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 qui que ce soit, 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 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 startup, vous ne devriez pas vous inquiéter qu'il ne soit pas largement compris. Vous devriez espérer qu'il en reste ainsi. Et c'est probable. C'est la nature des langages de programmation de satisfaire la plupart des gens avec 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 jusque 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 pressé de fermer et de rentrer chez lui, les expulse finalement 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 en 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, avance aussi lentement qu'un iceberg. Le garbage collection (ramasse-miettes), introduit par Lisp vers 1960, est maintenant largement considéré comme une bonne chose. Le typage dynamique (runtime typing), idem, gagne en popularité. Les fermetures lexicales (lexical closures), introduites par Lisp au début des années 1970, sont maintenant, à peine, sur le radar. Les macros, introduites par Lisp au milieu des années 1960, sont encore terra incognita.

Évidemment, le langage médian a une inertie énorme. Je ne propose pas que vous puissiez combattre cette force puissante. Ce que je propose est exactement l'inverse : que, comme un pratiquant d'Aïkido, 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 à la chevelure pointue 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 conquérir le monde. Mais si vous travaillez pour une startup qui n'a pas encore de patrons à la chevelure pointue, vous pouvez, comme nous l'avons fait, tourner le paradoxe de Blub à votre avantage : vous pouvez utiliser une technologie que vos concurrents, collés de manière inamovible 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.

Pendant les années où nous avons travaillé sur Viaweb, j'ai lu beaucoup de descriptions de poste. Un nouveau concurrent semblait surgir 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 en direct, était de regarder leurs offres d'emploi. Après quelques années, je pouvais dire quelles entreprises étaient à craindre et lesquelles ne l'étaient pas. Plus les descriptions de poste avaient une saveur « IT », moins l'entreprise était dangereuse. Les plus sûres étaient celles qui recherchaient une expérience Oracle. Vous n'aviez jamais à vous en soucier. 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, ce serait un peu effrayant – cela commence à ressembler à une entreprise où le côté technique, du moins, est géré par de vrais hackers. Si j'avais déjà 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 modules supplémentaires, un générateur d'images écrit en C, et un gestionnaire de back-office principalement écrit 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 générant des 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 si intelligents, ils programmeraient déjà en Lisp. »

[3] Tous les langages sont également puissants dans le sens où ils sont équivalents à une machine 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 n'est peut-être pas 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 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 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 en B. Mais si A prend en charge, disons, la récursion, 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 nerds : 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 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 de religion, soit de manuels universitaires si résolument neutres qu'ils sont en réalité des œuvres d'anthropologie. Les personnes qui tiennent à leur tranquillité, ou qui veulent la titularisation, évitent le sujet. Mais la question n'est qu'à moitié religieuse ; il y a quelque chose là qui mérite d'être étudié, surtout si vous voulez concevoir de nouveaux langages.