DÉPASSER LES MOYENNES

Avril 2001, révisé en avril 2003

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

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

Bien sûr, beaucoup de gens auraient pu avoir cette idée en même temps, mais à ma connaissance, Viaweb a été la première application Web. L'idée nous a semblé tellement novatrice que nous avons donné à la société son nom : Viaweb, car notre logiciel fonctionnait via le Web, au lieu de s'exécuter sur votre ordinateur de bureau.

Une autre particularité de ce logiciel est qu'il a été écrit principalement dans un langage de programmation appelé Lisp. Il s'agit de l'une des premières grandes applications destinées aux utilisateurs finaux à être écrites en Lisp, qui jusqu'alors était 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 » dans lequel il explique, entre autres, aux hackers en herbe 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, afin de pirater Unix, et le Perl pour l'administration système et les scripts cgi. Enfin, le hacker vraiment sérieux devrait envisager d'apprendre le Lisp :

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

C'est le même argument que l'on entend souvent pour justifier l'apprentissage du latin. Cela ne vous permettra pas d'obtenir 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 va pas aussi loin. La raison pour laquelle le latin ne vous permettra pas d'obtenir 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 demandez de parler.

Donc si Lisp fait de vous un meilleur programmeur, comme il le dit, pourquoi ne voudriez-vous pas l'utiliser ? Si 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 ne cherche pas à me moquer d'Eric Raymond ici. Dans l'ensemble, ses conseils sont bons. Ce qu'il dit à propos de Lisp correspond à 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 ? Après tout, les langages de programmation ne sont que des outils. Si Lisp permet réellement d'obtenir de meilleurs programmes, vous devriez l'utiliser. Et si ce n'est pas le cas, 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 va, toutes choses égales par ailleurs, mettre ses concurrents en faillite. Et lorsque vous lancez une start-up, vous le ressentez très vivement. Les start-ups ont tendance à être une affaire de tout ou rien. Soit vous devenez riche, soit vous n’obtenez rien. Dans une start-up, si vous pariez sur la mauvaise technologie, vos concurrents vous écraseront.

Robert et moi connaissions tous les deux bien Lisp et nous ne voyions aucune raison de ne pas faire confiance à notre instinct et de choisir Lisp. Nous savions que tout le monde écrivait ses logiciels en C++ ou en Perl. Mais nous savions aussi que cela ne signifiait rien. Si vous choisissiez cette technologie, 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, on peut faire ce que font toutes les autres grandes entreprises. Mais une start-up ne peut pas faire ce que font toutes les autres start-up. Je ne pense pas que beaucoup de gens s'en rendent compte, même dans les start-up.

La croissance moyenne d'une grande entreprise est d'environ 10 % par an. Si vous dirigez une grande entreprise et que vous faites tout comme la moyenne des grandes entreprises, vous pouvez vous attendre à faire aussi bien que la moyenne des grandes entreprises, c'est-à-dire à croître d'environ 10 % par an.

La même chose se produira si vous dirigez une startup, bien sûr. Si vous faites tout comme le fait une startup moyenne, vous devez vous attendre à des performances moyennes. Le problème ici est que des performances moyennes signifient que vous ferez faillite. Le taux de survie des startups est bien inférieur à 50 %. Donc si vous dirigez une startup, vous ferez mieux de faire quelque chose d'étrange. Sinon, vous aurez des problèmes.

En 1995, nous savions quelque chose que nos concurrents ne comprenaient pas, je pense, et que peu d'entre eux comprennent encore aujourd'hui : lorsque vous écrivez un logiciel qui ne doit fonctionner que sur vos propres serveurs, vous pouvez utiliser le langage de votre choix. Lorsque vous écrivez un logiciel de bureau, il existe une forte tendance à é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, en particulier lorsque vous disposez du code source du langage et du système d'exploitation, vous pouvez utiliser le langage de votre choix.

Cette nouvelle liberté est toutefois une arme à double tranchant. Maintenant que vous pouvez utiliser n’importe quelle langue, vous devez réfléchir à laquelle vous adresser. Les entreprises qui essaient de faire comme si rien n’avait changé risquent de constater que leurs concurrents ne changent pas.

Si vous pouvez utiliser n'importe quel langage, lequel utiliseriez-vous ? Nous avons choisi Lisp. D'une part, il était évident qu'un développement rapide serait important sur ce marché. Nous partions tous de zéro, donc une entreprise capable de mettre au point 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 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 aurait pu 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, ni du recrutement, ni de la collecte de fonds, ni de la recherche de clients. Aucun de nous n’avait jamais eu ce que l’on pourrait appeler un vrai travail. La seule chose pour laquelle nous étions bons, c’était l’écriture de logiciels. Nous espérions que cela nous sauverait. Nous serions prêts à profiter de tout avantage que nous pourrions obtenir dans le domaine des logiciels.

On peut 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 capables de réaliser des fonctionnalités plus rapidement que nos concurrents, et aussi de réaliser des choses dans notre logiciel qu'ils ne pouvaient pas faire. Et comme Lisp était un langage de très haut niveau, nous n'aurions pas besoin d'une grosse équipe de développement, donc nos coûts seraient plus bas. Si tel était le cas, nous pourrions offrir un meilleur produit pour moins d'argent, tout en réalisant un bénéfice. Nous finirions par avoir tous les utilisateurs, et nos concurrents n'en auraient aucun, et finiraient par faire faillite. C'est ce que nous espérions, de toute façon.

Quels ont été les résultats de cette expérience ? Étonnamment, elle a fonctionné. Nous avons fini par avoir 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 boutique en ligne wysiwyg qui fonctionnait sur le serveur et qui ressemblait pourtant à une application de bureau. Nos concurrents avaient des scripts CGI. Et nous étions toujours loin devant eux en termes de fonctionnalités. Parfois, par désespoir, nos 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 les jours qui suivaient l'annonce d'un concurrent dans un communiqué de presse. Le temps que les journalistes qui couvraient le communiqué de presse nous appellent, nous avions également la nouvelle fonctionnalité.

Nos concurrents ont dû croire 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 communiquait leurs fonctionnalités. Nous étions simplement capables de développer des logiciels plus rapidement que quiconque ne l'aurait cru possible.

Quand j'avais neuf ans, j'ai eu par hasard un exemplaire du livre Le Jour du Chacal, de Frederick Forsyth. Le personnage principal est un assassin engagé pour tuer le président de la République française. L'assassin doit passer devant la police pour arriver dans un appartement qui donne sur la route du président. Il passe devant eux, déguisé en vieil homme avec des béquilles, et ils ne le soupçonnent pas.

Notre arme secrète était similaire. Nous avons écrit notre logiciel dans un étrange langage d'IA, 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 fonctionnait à notre avantage. Dans les affaires, rien n'a plus de valeur qu'un avantage technique que vos concurrents ne comprennent pas. Dans les 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 n'en avons jamais parlé à la presse, et si vous cherchiez Lisp sur notre site Web, vous ne trouviez que les titres de deux livres dans ma biographie. Ce n'était pas un hasard. Une start-up doit donner le moins d'informations possible à ses concurrents. S'ils ne savaient pas dans quelle langue 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. Peu leur importait la langue dans laquelle 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 seulement. Et donc, grâce au 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é, 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 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 parler, ils étaient environ 20 000.

Le paradoxe de Blub

Qu'est-ce qui fait la grandeur de Lisp ? Et si Lisp est si formidable, pourquoi tout le monde ne l'utilise-t-il pas ? Ces questions peuvent sembler rhétoriques, mais en réalité, elles ont des réponses simples. Lisp est si formidable non pas à cause d'une qualité magique visible uniquement pour les passionnés, mais simplement parce qu'il est 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 méritent d'être expliquées.

Je commencerai par une déclaration extrêmement controversée : les langages de programmation varient en puissance.

Rares sont ceux qui contesteraient que les langages de haut niveau sont plus puissants que les langages machine. La plupart des programmeurs d'aujourd'hui s'accordent à dire qu'il n'est pas souhaitable de programmer en langage machine. Il est préférable de programmer dans un langage de haut niveau et de laisser un compilateur traduire le tout en langage machine. Cette idée est même intégrée au matériel informatique : depuis les années 1980, les jeux d'instructions sont 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 que l'on comprend moins souvent, c'est qu'il existe un principe plus général : si vous avez le choix entre plusieurs langages, c'est une erreur, toutes choses égales par ailleurs, de programmer dans un autre langage que le plus puissant. [3]

Il existe de nombreuses exceptions à cette règle. Si vous écrivez un programme qui doit fonctionner en étroite collaboration 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 doit seulement faire quelque chose de très simple, comme du traitement de nombres ou de la manipulation de bits, vous pouvez tout 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 tout autre langage est une erreur, exactement du même genre, bien que peut-être à un degré moindre, que la programmation en langage machine.

Vous pouvez voir que le langage machine est de très bas niveau. Mais, au moins en tant que convention sociale, les langages de haut niveau sont souvent tous considérés comme équivalents. Ce n'est pas le cas. 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 entre les langages machine d'un côté et tous les langages de haut niveau de l'autre. Les langages s'inscrivent sur un continuum [4] d'abstraction, des plus puissants jusqu'aux langages machine, qui eux-mêmes varient en puissance.

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

Et que dire de Perl 4 ? Entre Perl 4 et Perl 5, des fermetures lexicales ont été ajoutées au langage. La plupart des hackers de 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 devez utiliser le plus puissant possible.

Cette idée est cependant rarement mise en pratique. Passé un certain âge, les programmeurs changent rarement de langage volontairement. Quel que soit le langage auquel ils sont habitués, ils ont tendance à le considérer comme étant juste assez bon.

Les programmeurs sont très attachés à leurs langages favoris, et je ne veux blesser personne, donc pour expliquer ce point je vais utiliser un langage hypothétique appelé Blub. Blub se situe exactement au milieu du continuum de l'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 x (la 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 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 se rend pas compte qu'il regarde vers le haut. Ce qu'il voit, ce sont simplement des langages étranges. Il les considère probablement comme équivalents en puissance à Blub, mais avec toutes ces autres choses bizarres en plus. Blub est assez bon pour lui, car il pense en Blub.

Mais si nous adoptons le point de vue d'un programmeur utilisant l'un des langages les plus avancés dans le continuum de puissance, nous constatons qu'il méprise Blub. Comment peut-on faire quoi que ce soit avec Blub ? Il n'y 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 d'entre eux. (C'est probablement ce qu'Eric Raymond voulait dire quand il disait que Lisp fait de vous un meilleur programmeur.) On ne peut pas faire confiance aux opinions des autres, à cause du paradoxe de Blub : ils se satisfont du langage qu'ils utilisent, quel qu'il soit, parce qu'il dicte leur façon de penser les 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 à l'époque, elle ne me manquait pas. Je pensais en Basic. Et j'étais un as dans ce domaine. Je maîtrisais parfaitement tout ce que j'avais étudié.

Les cinq langages recommandés par Eric Raymond aux hackers se situent à différents niveaux du continuum de puissance. Leur place les uns par rapport aux autres est un sujet sensible. Je dirai que je pense que Lisp est au sommet. Et pour appuyer cette affirmation, je vais vous parler d'une des choses qui me manquent lorsque je regarde les quatre autres langages. Comment peut-on y faire quoi que ce soit, je pense, sans macros ? [5]

De nombreux langages ont ce qu'on appelle 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 se différencier. 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 constitué d'objets de données Lisp. Et pas au sens trivial du terme, puisque les fichiers sources 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, une fois lu par l'analyseur, est constitué de structures de données que vous pouvez parcourir.

Si vous comprenez comment fonctionnent les compilateurs, ce qui se passe en réalité 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 qui sont générés dans le 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 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à ! 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 devez savoir pour comprendre ce que cela signifie. Dans Ansi Common Lisp, j'ai essayé de faire avancer les choses aussi vite que possible, et même ainsi je n'ai pas abordé les macros avant la page 160.

Mais je pense pouvoir donner un argument qui pourrait être convaincant. Le code source de l'éditeur Viaweb était probablement composé de 20 à 25 % de macros. Les macros sont plus difficiles à écrire que les fonctions Lisp ordinaires, et il est considéré comme de mauvais goût de les utiliser lorsqu'elles ne sont pas nécessaires. Ainsi, chaque macro de 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 faire facilement dans un autre langage. Aussi sceptique que puisse être le 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 méfiante pourrait commencer à se demander s'il y a 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 ce fil. Il y a peut-être plus dans ce vieil homme qui boitille sur ses béquilles qu'il n'y paraît.

Aïkido pour les startups

Mais je ne m'attends pas à convaincre quiconque ( plus de 25 ans ) de se lancer dans l'apprentissage de Lisp. Le but de cet article n'est pas de faire changer d'avis 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 le comprennent pas.

Si vous envisagez d'utiliser Lisp dans une start-up, ne vous inquiétez pas, car il n'est pas bien compris. Vous devez espérer qu'il le restera. Et c'est fort probable. La nature des langages de programmation est telle que la plupart des gens sont satisfaits de ce qu'ils utilisent actuellement. Le matériel informatique évolue 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, on écrivait 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 jusque dans les années 1980. Je parie que beaucoup de gens ont continué à écrire du code en langage machine jusqu'à ce que le processeur, tel un barman impatient de fermer et de rentrer chez lui, les mette enfin dehors en passant à un jeu d'instructions risc.

En temps normal, la technologie évolue rapidement. Mais les langages de programmation sont différents : les langages de programmation ne sont pas seulement une technologie, mais aussi ce que les programmeurs utilisent. Ils sont à moitié technologie et à moitié religion.[6] Ainsi, le langage médian, c'est-à-dire le langage utilisé par le programmeur médian, évolue aussi lentement qu'un iceberg. Le ramasse-miettes, introduit par Lisp vers 1960, est aujourd'hui largement considéré comme une bonne chose. Le typage à l'exécution, lui aussi, gagne en popularité. Les fermetures lexicales, introduites par Lisp au début des années 1970, sont désormais, à peine, sur l'écran radar. Les macros, introduites par Lisp au milieu des années 1960, sont toujours une terra incognita.

Il est évident que le langage médian a une énorme influence. Je ne prétends pas que vous puissiez combattre cette force puissante. Ce que je propose, c'est exactement le contraire : que, comme un pratiquant d'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 aux cheveux pointus de vous laisser créer 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 start-up qui n'a pas encore de patron 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 vous vous retrouvez un jour à travailler pour une start-up, voici un conseil pratique pour évaluer vos concurrents. Lisez leurs offres d'emploi. Tout le reste sur leur site peut être constitué de photos d'archives ou de l'équivalent en prose, mais les offres d'emploi doivent être précises sur ce qu'ils recherchent, sinon ils n'obtiendront pas les bons candidats.

Pendant les années où nous avons travaillé sur Viaweb, j'ai lu beaucoup de descriptions de poste. Un nouveau concurrent semblait sortir du bois tous les mois environ. La première chose que je faisais, après avoir vérifié s'ils avaient une démo en ligne, était de consulter leurs offres d'emploi. Après quelques années, je savais de quelles entreprises il fallait s'inquiéter et de quelles autres. Plus les descriptions de poste avaient une saveur informatique, 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, cela aurait été un peu effrayant - cela commence à ressembler à une entreprise où le côté technique, au 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.

Remarques

[1] Viaweb avait initialement 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, 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, 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 de rester 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 aussi puissants les uns que les autres dans le sens où ils sont équivalents à Turing, mais ce n'est pas le sens du mot qui importe aux programmeurs. (Personne ne veut programmer une machine de Turing.) Le type de puissance qui importe aux programmeurs n'est peut-être pas définissable formellement, 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 le moins puissant qu'en écrivant un interpréteur pour le langage le plus puissant qu'il contient. Si le langage A dispose d'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, par exemple, la récursivité, et que B ne le fait pas, il est peu probable que ce soit quelque chose que vous puissiez résoudre 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 existe au moins un ordre partiel.

[5] Il est un peu trompeur de considérer 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 de repos.

[6] En conséquence, les comparaisons entre langages de programmation prennent soit la forme de guerres de religion, soit celle de manuels de premier cycle si résolument neutres qu'ils sont en réalité des ouvrages 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 là quelque chose qui mérite d'être étudié, surtout si vous voulez concevoir de nouveaux langages.