CONCEPTION ET RECHERCHE

Janvier 2003

(Cet article est dérivé d'un discours principal lors de la réunion d'automne 2002 de NEPLS.)

Les visiteurs de ce pays sont souvent surpris de constater que les Américains aiment commencer une conversation en demandant "que faites-vous ?". Je n'ai jamais aimé cette question. J'ai rarement eu une réponse claire à cela. Mais je pense que j'ai enfin résolu le problème. Maintenant, quand quelqu'un me demande ce que je fais, je le regarde droit dans les yeux et je dis "Je conçois un nouveau dialecte de Lisp." Je recommande cette réponse à quiconque n'aime pas qu'on lui demande ce qu'il fait. La conversation se tournera immédiatement vers d'autres sujets.

Je ne considère pas que je fais de la recherche sur les langages de programmation. Je suis juste en train d'en concevoir un, de la même manière que quelqu'un pourrait concevoir un bâtiment, une chaise ou une nouvelle police de caractères. Je n'essaie pas de découvrir quoi que ce soit de nouveau. Je veux juste créer un langage qui sera agréable à programmer. À certains égards, cette hypothèse rend la vie beaucoup plus facile.

La différence entre la conception et la recherche semble être une question de nouveau contre bon. La conception n'a pas besoin d'être nouvelle, mais elle doit être bonne. La recherche n'a pas besoin d'être bonne, mais elle doit être nouvelle. Je pense que ces deux chemins convergent au sommet : la meilleure conception surpasse ses prédécesseurs en utilisant de nouvelles idées, et la meilleure recherche résout des problèmes qui ne sont pas seulement nouveaux, mais qui valent réellement la peine d'être résolus. Donc, en fin de compte, nous visons la même destination, juste en l'approchant sous des angles différents.

Ce dont je vais parler aujourd'hui, c'est de ce à quoi ressemble votre cible de l'arrière. Que faites-vous différemment lorsque vous traitez les langages de programmation comme un problème de conception plutôt que comme un sujet de recherche ?

La plus grande différence est que vous vous concentrez davantage sur l'utilisateur. La conception commence par demander, pour qui est-ce et de quoi ont-ils besoin ? Un bon architecte, par exemple, ne commence pas par créer un design qu'il impose ensuite aux utilisateurs, mais en étudiant les utilisateurs visés et en découvrant ce dont ils ont besoin.

Remarquez que j'ai dit "ce dont ils ont besoin", pas "ce qu'ils veulent". Je ne veux pas donner l'impression que travailler en tant que designer signifie travailler comme une sorte de cuisinier à la commande, faisant ce que le client vous dit de faire. Cela varie d'un domaine à l'autre dans les arts, mais je ne pense pas qu'il existe un domaine dans lequel le meilleur travail est réalisé par des personnes qui font exactement ce que les clients leur disent.

Le client a toujours raison dans le sens où la mesure d'une bonne conception est à quel point elle fonctionne bien pour l'utilisateur. Si vous créez un roman qui ennuie tout le monde, ou une chaise qui est horriblement inconfortable, alors vous avez fait un mauvais travail, point final. Ce n'est pas une défense de dire que le roman ou la chaise est conçu selon les principes théoriques les plus avancés.

Et pourtant, faire ce qui fonctionne pour l'utilisateur ne signifie pas simplement faire ce que l'utilisateur vous dit. Les utilisateurs ne savent pas quelles sont toutes les options, et se trompent souvent sur ce qu'ils veulent vraiment.

La réponse au paradoxe, je pense, est que vous devez concevoir pour l'utilisateur, mais vous devez concevoir ce dont l'utilisateur a besoin, pas simplement ce qu'il dit vouloir. C'est un peu comme être médecin. Vous ne pouvez pas simplement traiter les symptômes d'un patient. Quand un patient vous parle de ses symptômes, vous devez découvrir ce qui ne va pas réellement chez lui, et traiter cela.

Cette concentration sur l'utilisateur est une sorte d'axiome à partir duquel la plupart de la pratique d'une bonne conception peut être dérivée, et autour duquel la plupart des problèmes de conception se concentrent.

Si une bonne conception doit répondre aux besoins de l'utilisateur, qui est l'utilisateur ? Quand je dis que la conception doit être pour les utilisateurs, je ne veux pas dire que la bonne conception vise une sorte de plus petit dénominateur commun. Vous pouvez choisir n'importe quel groupe d'utilisateurs que vous voulez. Si vous concevez un outil, par exemple, vous pouvez le concevoir pour quiconque, des débutants aux experts, et ce qui est une bonne conception pour un groupe pourrait être mauvais pour un autre. L'essentiel est que vous devez choisir un groupe d'utilisateurs. Je ne pense pas que vous puissiez même parler de bonne ou de mauvaise conception sans référence à un utilisateur visé.

Vous êtes le plus susceptible d'obtenir une bonne conception si les utilisateurs visés incluent le designer lui-même. Lorsque vous concevez quelque chose pour un groupe qui ne vous inclut pas, cela tend à être pour des personnes que vous considérez comme moins sophistiquées que vous, pas plus sophistiquées.

C'est un problème, car regarder de haut l'utilisateur, aussi bienveillant soit-il, semble inévitablement corrompre le designer. Je soupçonne que très peu de projets de logement aux États-Unis ont été conçus par des architectes qui s'attendaient à y vivre. Vous pouvez voir la même chose dans les langages de programmation. C, Lisp et Smalltalk ont été créés pour que leurs propres concepteurs les utilisent. Cobol, Ada et Java ont été créés pour que d'autres les utilisent.

Si vous pensez que vous concevez quelque chose pour des idiots, il y a de fortes chances que vous ne conceviez pas quelque chose de bon, même pour des idiots.

Même si vous concevez quelque chose pour les utilisateurs les plus sophistiqués, vous concevez toujours pour des humains. C'est différent dans la recherche. En mathématiques, vous ne choisissez pas des abstractions parce qu'elles sont faciles à comprendre pour les humains ; vous choisissez celles qui rendent la preuve plus courte. Je pense que cela est vrai pour les sciences en général. Les idées scientifiques ne sont pas censées être ergonomiques.

Dans les arts, les choses sont très différentes. La conception concerne les gens. Le corps humain est une chose étrange, mais lorsque vous concevez une chaise, c'est pour cela que vous concevez, et il n'y a pas moyen d'y échapper. Tous les arts doivent flatter les intérêts et les limitations des humains. Dans la peinture, par exemple, toutes choses étant égales par ailleurs, une peinture avec des gens sera plus intéressante qu'une sans. Ce n'est pas simplement un accident de l'histoire que les grandes peintures de la Renaissance soient toutes pleines de gens. Si elles ne l'avaient pas été, la peinture en tant que médium n'aurait pas le prestige qu'elle a.

Que cela vous plaise ou non, les langages de programmation sont aussi pour les gens, et je soupçonne que le cerveau humain est tout aussi inégal et idiosyncratique que le corps humain. Certaines idées sont faciles à saisir pour les gens et d'autres ne le sont pas. Par exemple, nous semblons avoir une capacité très limitée à gérer les détails. C'est ce fait qui rend les langages de programmation une bonne idée en premier lieu ; si nous pouvions gérer les détails, nous pourrions simplement programmer en langage machine.

Rappelez-vous aussi que les langages ne sont pas principalement une forme pour des programmes finis, mais quelque chose dans lequel les programmes doivent être développés. Quiconque dans les arts pourrait vous dire que vous pourriez vouloir différents médiums pour les deux situations. Le marbre, par exemple, est un beau médium durable pour des idées finies, mais un médium désespérément inflexible pour développer de nouvelles idées.

Un programme, comme une preuve, est une version élaguée d'un arbre qui, dans le passé, a eu de faux départs se ramifiant partout. Donc, le test d'un langage n'est pas simplement à quel point le programme fini a l'air propre, mais à quel point le chemin vers le programme fini était propre. Un choix de conception qui vous donne des programmes finis élégants peut ne pas vous donner un processus de conception élégant. Par exemple, j'ai écrit quelques macros définissant des macros pleines de backquotes imbriquées qui ressemblent maintenant à de petits joyaux, mais les écrire a pris des heures de la plus laide des tentatives et erreurs, et franchement, je ne suis toujours pas entièrement sûr qu'elles soient correctes.

Nous agissons souvent comme si le test d'un langage était à quel point les programmes finis ont l'air bons dedans. Cela semble si convaincant lorsque vous voyez le même programme écrit dans deux langages, et qu'une version est beaucoup plus courte. Lorsque vous abordez le problème du côté des arts, vous êtes moins susceptible de dépendre de ce genre de test. Vous ne voulez pas finir avec un langage de programmation comme le marbre.

Par exemple, il est extrêmement avantageux dans le développement de logiciels d'avoir un niveau supérieur interactif, ce que l'on appelle en Lisp une boucle de lecture-évaluation-impression. Et lorsque vous en avez un, cela a de réels effets sur la conception du langage. Cela ne fonctionnerait pas bien pour un langage où vous devez déclarer des variables avant de les utiliser, par exemple. Lorsque vous tapez simplement des expressions dans le niveau supérieur, vous voulez pouvoir définir x à une certaine valeur et ensuite commencer à faire des choses avec x. Vous ne voulez pas avoir à déclarer d'abord le type de x. Vous pouvez contester l'une ou l'autre des prémisses, mais si un langage doit avoir un niveau supérieur pour être pratique, et que les déclarations de type obligatoires sont incompatibles avec un niveau supérieur, alors aucun langage qui rend les déclarations de type obligatoires ne pourrait être pratique à programmer.

En pratique, pour obtenir une bonne conception, vous devez vous rapprocher, et rester proche, de vos utilisateurs. Vous devez calibrer vos idées sur des utilisateurs réels en permanence, surtout au début. Une des raisons pour lesquelles les romans de Jane Austen sont si bons est qu'elle les lisait à voix haute à sa famille. C'est pourquoi elle ne sombre jamais dans des descriptions artistiques auto-indulgentes de paysages, ou dans un philosophage prétentieux. (La philosophie est là, mais elle est tissée dans l'histoire au lieu d'être collée dessus comme une étiquette.) Si vous ouvrez un roman "littéraire" moyen et imaginez le lire à voix haute à vos amis comme quelque chose que vous avez écrit, vous ressentirez trop vivement à quel point ce genre de chose est une imposition pour le lecteur.

Dans le monde du logiciel, cette idée est connue sous le nom de "Worse is Better". En fait, il y a plusieurs idées mélangées dans le concept de "Worse is Better", ce qui explique pourquoi les gens continuent à débattre de la question de savoir si le pire est réellement meilleur ou non. Mais l'une des idées principales dans ce mélange est que si vous construisez quelque chose de nouveau, vous devriez obtenir un prototype devant les utilisateurs le plus tôt possible.

L'approche alternative pourrait être appelée la stratégie du Hail Mary. Au lieu de sortir rapidement un prototype et de le peaufiner progressivement, vous essayez de créer le produit complet et fini en un seul long touchdown. Pour autant que je sache, c'est une recette pour le désastre. D'innombrables startups se sont détruites de cette manière pendant la bulle Internet. Je n'ai jamais entendu parler d'un cas où cela a fonctionné.

Ce que les gens en dehors du monde du logiciel ne réalisent peut-être pas, c'est que "Worse is Better" se retrouve dans tous les arts. Dans le dessin, par exemple, l'idée a été découverte pendant la Renaissance. Maintenant, presque tous les enseignants de dessin vous diront que la bonne façon d'obtenir un dessin précis n'est pas de travailler lentement autour du contour d'un objet, car les erreurs s'accumuleront et vous constaterez à la fin que les lignes ne se rejoignent pas. Au lieu de cela, vous devriez dessiner quelques lignes rapides à peu près au bon endroit, puis affiner progressivement ce croquis initial.

Dans la plupart des domaines, les prototypes ont traditionnellement été réalisés à partir de matériaux différents. Les polices de caractères à couper dans le métal étaient initialement conçues avec un pinceau sur papier. Les statues à couler dans le bronze étaient modélisées en cire. Les motifs à broder sur des tapisseries étaient dessinés sur papier avec de l'encre lavis. Les bâtiments à construire en pierre étaient testés à une échelle plus petite en bois.

Ce qui a rendu la peinture à l'huile si excitante, lorsqu'elle est devenue populaire au quinzième siècle, c'est que vous pouviez réellement faire l'œuvre finie à partir du prototype. Vous pouviez faire un dessin préliminaire si vous le souhaitiez, mais vous n'étiez pas tenu de le faire ; vous pouviez travailler tous les détails, et même apporter des changements majeurs, au fur et à mesure que vous finissiez la peinture.

Vous pouvez faire cela dans le logiciel aussi. Un prototype n'a pas à être juste un modèle ; vous pouvez le peaufiner en produit fini. Je pense que vous devriez toujours faire cela quand vous le pouvez. Cela vous permet de tirer parti de nouvelles idées que vous avez en cours de route. Mais peut-être encore plus important, c'est bon pour le moral.

Le moral est essentiel dans la conception. Je suis surpris que les gens n'en parlent pas plus. Un de mes premiers enseignants de dessin m'a dit : si vous vous ennuyez en dessinant quelque chose, le dessin aura l'air ennuyeux. Par exemple, supposons que vous devez dessiner un bâtiment, et que vous décidez de dessiner chaque brique individuellement. Vous pouvez le faire si vous le souhaitez, mais si vous vous ennuyez à mi-chemin et commencez à faire les briques mécaniquement au lieu d'observer chacune, le dessin aura l'air pire que si vous aviez simplement suggéré les briques.

Construire quelque chose en affinant progressivement un prototype est bon pour le moral car cela vous garde engagé. Dans le logiciel, ma règle est : ayez toujours du code fonctionnel. Si vous écrivez quelque chose que vous pourrez tester dans une heure, alors vous avez la perspective d'une récompense immédiate pour vous motiver. Il en va de même dans les arts, et particulièrement dans la peinture à l'huile. La plupart des peintres commencent par un croquis flou et l'affinent progressivement. Si vous travaillez de cette manière, alors en principe vous n'avez jamais à finir la journée avec quelque chose qui a réellement l'air inachevé. En effet, il y a même un dicton parmi les peintres : "Une peinture n'est jamais finie, vous arrêtez juste de travailler dessus." Cette idée sera familière à quiconque a travaillé sur un logiciel.

Le moral est une autre raison pour laquelle il est difficile de concevoir quelque chose pour un utilisateur peu sophistiqué. Il est difficile de rester intéressé par quelque chose que vous n'aimez pas vous-même. Pour faire quelque chose de bon, vous devez penser : "wow, c'est vraiment génial", pas "quel morceau de merde ; ces imbéciles vont adorer".

La conception signifie faire des choses pour les humains. Mais ce n'est pas seulement l'utilisateur qui est humain. Le designer est humain aussi.

Remarquez que tout ce temps, j'ai parlé de "le designer". La conception doit généralement être sous le contrôle d'une seule personne pour être de bonne qualité. Et pourtant, il semble possible que plusieurs personnes collaborent sur un projet de recherche. Cela me semble être l'une des différences les plus intéressantes entre la recherche et la conception.

Il y a eu des cas célèbres de collaboration dans les arts, mais la plupart semblent avoir été des cas de liaison moléculaire plutôt que de fusion nucléaire. Dans un opéra, il est courant qu'une personne écrive le livret et qu'une autre écrive la musique. Et pendant la Renaissance, des compagnons venus du nord de l'Europe étaient souvent employés pour faire les paysages dans les arrière-plans des peintures italiennes. Mais ce ne sont pas de vraies collaborations. Ce sont plus des exemples du "bon voisinage fait de bonnes clôtures" de Robert Frost. Vous pouvez coller des instances de bonne conception ensemble, mais au sein de chaque projet individuel, une personne doit être en contrôle.

Je ne dis pas que la bonne conception exige qu'une personne pense à tout. Il n'y a rien de plus précieux que le conseil de quelqu'un dont vous faites confiance au jugement. Mais après que la discussion soit terminée, la décision sur ce qu'il faut faire doit reposer sur une seule personne.

Pourquoi la recherche peut-elle être réalisée par des collaborateurs et la conception ne le peut-elle pas ? C'est une question intéressante. Je ne connais pas la réponse. Peut-être, si la conception et la recherche convergent, la meilleure recherche est aussi une bonne conception, et en fait ne peut pas être réalisée par des collaborateurs. Beaucoup des scientifiques les plus célèbres semblent avoir travaillé seuls. Mais je ne sais pas assez pour dire s'il y a un schéma ici. Cela pourrait simplement être que de nombreux scientifiques célèbres ont travaillé à une époque où la collaboration était moins courante.

Quoi qu'il en soit dans les sciences, la véritable collaboration semble être extrêmement rare dans les arts. La conception par comité est un synonyme de mauvaise conception. Pourquoi est-ce ainsi ? Y a-t-il un moyen de surmonter cette limitation ?

Je suis enclin à penser qu'il n'y en a pas - que la bonne conception nécessite un dictateur. Une raison est que la bonne conception doit être cohérente. La conception n'est pas seulement pour les humains, mais pour des humains individuels. Si une conception représente une idée qui tient dans la tête d'une personne, alors l'idée tiendra aussi dans la tête de l'utilisateur.