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 nette à lui donner. Mais je pense avoir finalement 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 me considère pas comme faisant de la recherche sur les langages de programmation. Je conçois simplement l'un d'entre eux, 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 quelque chose de nouveau. Je veux juste créer un langage qui sera bon à 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 voies 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 vraiment dignes d'être résolus. Donc, en fin de compte, nous visons la même destination, en l'abordant simplement de directions différentes.

Ce dont je vais parler aujourd'hui, c'est à quoi ressemble votre cible vu de derriè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 se 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 prévus et en découvrant ce dont ils ont besoin.

Notez 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 concepteur signifie travailler comme une sorte de cuisinier à la demande, en faisant tout ce que le client vous dit de faire. Cela varie selon les domaines des arts, mais je ne pense pas qu'il y ait un domaine dans lequel les meilleurs travaux sont réalisés par les gens qui font simplement ce que les clients leur disent de faire.

Le client a toujours raison dans le sens où la mesure de la bonne conception est la façon dont elle fonctionne pour l'utilisateur. Si vous faites un roman qui ennuie tout le monde, ou une chaise qui est horriblement inconfortable à s'asseoir, alors vous avez fait un mauvais travail, point. 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 de faire. 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, et non pas simplement ce qu'il dit qu'il veut. C'est un peu comme être médecin. Vous ne pouvez pas simplement traiter les symptômes d'un patient. Quand un patient vous dit ses symptômes, vous devez découvrir ce qui ne va pas vraiment avec lui, et traiter cela.

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

Si la bonne conception doit faire ce dont l'utilisateur a besoin, 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 un genre 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 n'importe qui, des débutants aux experts, et ce qui est une bonne conception pour un groupe pourrait être mauvais pour un autre. Le point est, 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 prévu.

Vous avez le plus de chances d'obtenir une bonne conception si les utilisateurs prévus incluent le concepteur lui-même. Lorsque vous concevez quelque chose pour un groupe qui ne vous inclut pas, il a tendance à être pour des gens que vous considérez comme moins sophistiqués que vous, et non plus sophistiqués.

C'est un problème, car regarder de haut l'utilisateur, si bienveillant soit-il, semble inévitablement corrompre le concepteur. 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 personnes les utilisent.

Si vous pensez que vous concevez quelque chose pour des idiots, il est probable que vous ne concevez 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 les abstractions parce qu'elles sont faciles à comprendre pour les humains ; vous choisissez celles qui rendent la preuve plus courte. Je pense que c'est vrai pour les sciences en général. Les idées scientifiques ne sont pas censées être ergonomiques.

De l'autre côté, dans les arts, les choses sont très différentes. La conception est tout à propos des gens. Le corps humain est une chose étrange, mais lorsque vous concevez une chaise, c'est ce pour quoi vous la concevez, et il n'y a pas moyen de l'éviter. Tous les arts doivent se plier aux intérêts et aux limites des humains. En peinture, par exemple, toutes choses égales par ailleurs, une peinture avec des gens dedans sera plus intéressante qu'une sans. Ce n'est pas seulement un accident de l'histoire que les grandes peintures de la Renaissance soient toutes remplies de gens. S'il n'en avait pas été ainsi, la peinture en tant que médium n'aurait pas le prestige qu'elle a.

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

N'oubliez pas non plus que les langages ne sont pas principalement une forme pour les programmes finis, mais quelque chose dans lequel les programmes doivent être développés. Toute personne dans les arts pourrait vous dire que vous pourriez vouloir des médias différents pour les deux situations. Le marbre, par exemple, est un support agréable et durable pour les idées finies, mais un support affreusement inflexible pour développer de nouvelles idées.

Un programme, comme une preuve, est une version élagué 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 la propreté du programme fini en lui, mais la propreté du chemin vers le programme fini. 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 guillemets imbriqués qui ressemblent maintenant à de petits joyaux, mais les écrire a pris des heures du plus laid essai et erreur, et franchement, je ne suis pas encore tout à fait sûr qu'ils soient corrects.

Nous agissons souvent comme si le test d'un langage était la qualité des programmes finis en lui. Cela semble si convaincant quand vous voyez le même programme écrit dans deux langages, et qu'une version est beaucoup plus courte. Quand vous abordez le problème dans la direction 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, c'est un énorme avantage dans le développement de logiciels d'avoir un toplevel interactif, ce qu'on appelle en Lisp une boucle de lecture-évaluation-impression. Et quand vous en avez un, cela a des effets réels 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. Quand vous tapez juste des expressions dans le toplevel, vous voulez pouvoir attribuer une valeur à x et ensuite commencer à faire des choses avec x. Vous ne voulez pas avoir à déclarer le type de x d'abord. Vous pouvez contester l'un ou l'autre des prémisses, mais si un langage doit avoir un toplevel pour être pratique, et que les déclarations de type obligatoires sont incompatibles avec un toplevel, alors aucun langage qui impose des déclarations de type ne pourrait être pratique à programmer.

En pratique, pour obtenir une bonne conception, vous devez vous rapprocher de vos utilisateurs et rester proche d'eux. Vous devez constamment calibrer vos idées sur les utilisateurs réels, surtout au début. L'une des raisons pour lesquelles les romans de Jane Austen sont si bons, c'est qu'elle les lisait à haute voix à sa famille. C'est pourquoi elle ne sombre jamais dans des descriptions de paysages trop artistiques ou dans un philosophisme 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 à haute voix à vos amis comme quelque chose que vous avez écrit, vous sentirez à quel point ce genre de chose s'impose au lecteur.

Dans le monde du logiciel, cette idée est connue sous le nom de "Pire est mieux". En fait, il y a plusieurs idées mélangées dans le concept de "Pire est mieux", ce qui explique pourquoi les gens se disputent encore sur la question de savoir si "pire" est vraiment mieux ou non. Mais l'une des principales idées de ce mélange est que si vous construisez quelque chose de nouveau, vous devez mettre un prototype entre les mains des utilisateurs dès que possible.

L'approche alternative pourrait être appelée la stratégie du "Hail Mary". Au lieu d'obtenir rapidement un prototype et de le peaufiner progressivement, vous essayez de créer le produit complet et fini en une seule passe de touchdown. Pour autant que je sache, c'est une recette pour le désastre. De nombreuses start-ups 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 "Pire est mieux" se retrouve dans tous les arts. En dessin, par exemple, l'idée a été découverte pendant la Renaissance. Maintenant, presque tous les professeurs 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 à la bonne place, puis affiner progressivement ce croquis initial.

Dans la plupart des domaines, les prototypes ont traditionnellement été faits avec des matériaux différents. Les polices de caractères à graver dans le métal ont d'abord été conçues au pinceau sur du papier. Les statues à couler dans le bronze ont été modelées dans la cire. Les motifs à broder sur les tapisseries ont été dessinés à l'encre de Chine sur du papier. Les bâtiments à construire en pierre ont été testés à plus petite échelle en bois.

Ce qui a rendu la peinture à l'huile si passionnante, lorsqu'elle est devenue populaire au quinzième siècle, c'est que vous pouviez en fait faire l'œuvre finie à partir du prototype. Vous pouviez faire un dessin préliminaire si vous le vouliez, mais vous n'étiez pas tenu de vous y tenir ; vous pouviez travailler tous les détails, et même apporter des changements majeurs, tout en finissant le tableau.

Vous pouvez faire la même chose dans le logiciel. Un prototype ne doit pas être seulement un modèle ; vous pouvez le peaufiner pour en faire le produit final. Je pense que vous devriez toujours le faire quand vous le pouvez. Cela vous permet de tirer parti des nouvelles idées que vous avez en cours de route. Mais ce qui est peut-être encore plus important, c'est que c'est bon pour le moral.

Le moral est essentiel dans la conception. Je suis surpris que les gens n'en parlent pas davantage. L'un de mes premiers professeurs de dessin m'a dit : "Si vous vous ennuyez en dessinant quelque chose, le dessin aura l'air ennuyeux". Par exemple, supposons que vous deviez dessiner un bâtiment et que vous décidiez de dessiner chaque brique individuellement. Vous pouvez le faire si vous le voulez, mais si vous vous ennuyez à mi-chemin et que vous commencez à faire les briques de manière mécanique au lieu d'observer chacune d'entre elles, le dessin aura l'air pire que si vous vous étiez contenté de suggérer les briques.

Construire quelque chose en raffinant progressivement un prototype est bon pour le moral car cela vous tient engagé. Dans le logiciel, ma règle est : toujours avoir 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 en particulier dans la peinture à l'huile. La plupart des peintres commencent par un croquis flou et le peaufinent progressivement. Si vous travaillez de cette manière, en principe, vous n'avez jamais à terminer la journée avec quelque chose qui a vraiment l'air inachevé. En effet, il existe même un dicton chez les peintres : "Une peinture n'est jamais finie, vous arrêtez juste d'y travailler". Cette idée sera familière à quiconque a travaillé sur un logiciel.

La morale 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 l'on n'aime pas soi-même. Pour faire quelque chose de bien, il faut penser "wow, c'est vraiment génial", pas "quelle merde ; ces idiots vont adorer".

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

Remarquez que tout ce temps, j'ai parlé "du concepteur". La conception doit généralement être sous le contrôle d'une seule personne pour être bonne. Et pourtant, il semble possible pour plusieurs personnes de collaborer 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 une autre la musique. Et pendant la Renaissance, des compagnons d'Europe du Nord étaient souvent employés pour faire les paysages en arrière-plan des peintures italiennes. Mais ce ne sont pas de vraies collaborations. Ce sont plutôt des exemples de la "bonne clôture fait de bons voisins" de Robert Frost. Vous pouvez coller des instances de bonne conception ensemble, mais au sein de chaque projet individuel, une personne doit être aux commandes.

Je ne dis pas que la bonne conception exige qu'une seule personne pense à tout. Il n'y a rien de plus précieux que les conseils de quelqu'un en qui on a confiance. Mais après les discussions, la décision de ce qu'il faut faire doit revenir à une seule personne.

Pourquoi la recherche peut-elle être faite par des collaborateurs et la conception ne le peut pas ? C'est une question intéressante. Je ne connais pas la réponse. Peut-être que si la conception et la recherche convergent, la meilleure recherche est aussi une bonne conception, et en fait ne peut pas être faite par des collaborateurs. Beaucoup des scientifiques les plus célèbres semblent avoir travaillé seuls. Mais je n'en sais pas assez pour dire s'il y a un modèle ici. Il pourrait simplement s'agir du fait 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 vraie collaboration semble être extrêmement rare dans les arts. La conception par comité est un synonyme de mauvaise conception. Pourquoi en est-il ainsi ? Existe-t-il un moyen de surmonter cette limite ?

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 d'un seul tenant. 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.

Connexe :

[1]