CONCEPTION ET RECHERCHE

Janvier 2003

(Cet article est tiré d'un discours prononcé 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. Je n'ai jamais eu de réponse simple à cette question. Mais je pense avoir 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 à tous ceux qui n'aiment pas qu'on leur demande ce qu'ils font. La conversation tournera immédiatement vers d'autres sujets.

Je ne me considère pas comme faisant 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 quelque chose de nouveau. Je veux juste créer un langage qui sera agréable à programmer. D'une certaine manière, cette hypothèse rend la vie beaucoup plus facile.

La différence entre la conception et la recherche semble être une question de nouveau versus 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 qui valent vraiment la peine d'être résolus. Donc, en fin de compte, nous visons la même destination, mais nous l'abordons de directions différentes.

Ce dont je vais parler aujourd'hui, c'est à 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 se demander à qui s'adresse-t-elle 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 cibles et en déterminant ce dont ils ont besoin.

Remarquez que j'ai dit "ce dont ils ont besoin", et non "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 demande, 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 y ait un domaine où le meilleur travail est fait par les gens qui font exactement ce que les clients leur disent de faire.

Le client est toujours juste dans le sens où la mesure d'une 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 à utiliser, 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 de faire. Les utilisateurs ne connaissent pas 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 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 décrit ses symptômes, vous devez déterminer ce qui ne va pas chez lui, et le traiter.

Cette focalisation sur l'utilisateur est une sorte d'axiome à partir duquel la plupart des pratiques de la bonne conception peuvent être dérivées, et autour duquel la plupart des problèmes de conception sont centrés.

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 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 n'importe qui, des débutants aux experts, et ce qui est une bonne conception pour un groupe peut être mauvais pour un autre. Le point 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, sauf en référence à un utilisateur cible.

Vous avez le plus de chances d'obtenir une bonne conception si les utilisateurs cibles 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 personnes que vous considérez comme moins sophistiquées que vous, et non plus sophistiquées.

C'est un problème, car regarder de haut l'utilisateur, aussi 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 y a de fortes chances que vous ne conceviez pas quelque chose de bien, même pour des idiots.

Même si vous concevez quelque chose pour les utilisateurs les plus sophistiqués, cependant, 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 le 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.

Dans les arts, les choses sont très différentes. La conception est tout au sujet des 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 de l'éviter. Tous les arts doivent pander aux intérêts et aux limitations des humains. En peinture, par exemple, toutes choses étant égales par ailleurs, une peinture avec des gens sera plus intéressante qu'une peinture 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 bosselé et idiosyncrasique que le corps humain. Certaines idées sont faciles à saisir pour les gens et d'autres non. Par exemple, nous semblons avoir une capacité très limitée à gérer les détails. C'est ce fait qui fait des 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 les programmes finis, mais quelque chose dans lequel les programmes doivent être développés. N'importe qui dans les arts pourrait vous dire que vous pourriez vouloir des médiums différents pour le deux situations. Le marbre, par exemple, est un médium agréable et durable pour les idées finies, mais un médium terriblement 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 des faux départs qui se ramifient partout. Donc le test de un langage n'est pas simplement à quel point le programme fini est propre en lui, 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 de définition de macros pleines de backquotes imbriqués qui ressemblent maintenant à de petits joyaux, mais les écrire a pris des heures d'essais et d'erreurs les plus laids, et franchement, je suis toujours pas entièrement sûr qu'ils soient corrects.

Nous agissons souvent comme si le test d'un langage était à quel point les programmes finis sont beaux en lui. 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é de la arts, vous êtes moins susceptible de dépendre de ce genre de test. Vous ne voulez pas vous retrouver avec un langage de programmation comme le marbre.

Par exemple, c'est un énorme gain dans le développement de logiciels pour avoir un niveau supérieur 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 les variables avant de les utiliser, par exemple. Lorsque vous êtes juste en train de taper des expressions dans le niveau supérieur, vous voulez pouvoir affecter à x une certaine valeur et ensuite commencer à faire des choses à x. Vous ne voulez pas avoir à déclarer le type de x en premier. 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 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 constamment, surtout au début. L'une des raisons pour lesquelles les romans de Jane Austen sont si bons est qu'elle les lisait à haute voix à sa famille. C'est pourquoi elle ne sombre jamais dans des descriptions artistiques auto-indulgentes de paysages, ou de la philosophie prétentieuse. (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 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 se disputent toujours si le pire est vraiment mieux 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 dès que possible.

L'approche alternative pourrait être appelée la stratégie Hail Mary. Au lieu d'obtenir un prototype rapidement et de le peaufiner progressivement, vous essayez de créer le produit complet, fini, en une seule longue passe de touché. Pour autant que je sache, c'est un recette pour le désastre. D'innombrables startups se sont détruites de cette façon 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 peuvent ne pas réaliser, c'est que Worse is Better 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 vont s'accumuler 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 cette esquisse initiale.

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

Ce qui a rendu la peinture à l'huile si excitante, quand elle est devenue populaire au XVe 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 vouliez, mais vous n'y étiez pas tenu ; vous pouviez travailler tous les détails, et même apporter des changements majeurs, en finissant la peinture.

Vous pouvez le faire en logiciel aussi. Un prototype n'a pas besoin d'être juste un modèle ; vous pouvez le peaufiner pour en faire le produit fini. Je pense que vous devriez toujours le faire quand vous le pouvez. Cela vous permet de profiter des 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. L'un de mes premiers professeurs de dessin m'a dit : si vous vous ennuyez lorsque vous êtes en train de dessiner 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 voulez, mais si vous vous ennuyez à mi-chemin et que vous commencez à faire les briques mécaniquement au lieu d'observer chacune d'elles, le dessin aura l'air pire que si vous aviez simplement suggéré les briques.

Construire quelque chose en peaufinant progressivement un prototype est bon pour le moral car cela vous maintient engagé. En logiciel, mon règle est : avoir toujours du code qui fonctionne. 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 une esquisse floue et la peaufinent progressivement. Si vous travaillez de cette façon, alors en principe vous n'avez jamais à terminer la journée avec quelque chose qui a vraiment l'air inachevé. En effet, il y a même un dicton parmi les peintres : "Une peinture n'est jamais finie, on arrête juste de travailler dessus." Cette idée sera familière à tous ceux qui ont travaillé sur des logiciels.

Le moral est une autre raison pour laquelle il est difficile de concevoir quelque chose pour un utilisateur non sophistiqué. Il est difficile de rester intéressé par quelque chose que vous n'aimez pas vous-même. Pour faire quelque chose de bien, vous devez penser, "wow, c'est vraiment génial", et non "quelle 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 concepteur est aussi humain.

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 que plusieurs personnes collaborer à un projet de recherche. Cela me semble 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 d'entre eux 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 du nord de l'Europe étaient souvent employés pour faire les paysages dans le arrière-plans des peintures italiennes. Mais ce ne sont pas de vraies collaborations. Ce sont plutôt des exemples de "les bonnes clôtures font 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 au contrôle.

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 dont vous avez confiance en son jugement. Mais une fois que les discussions sont terminées, la décision sur ce qu'il faut faire doit reposer sur 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, 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 se pourrait simplement que de nombreux scientifiques célèbres aient travaillé à une époque où la collaboration était moins courante.

Quelle que soit l'histoire dans les sciences, la vraie collaboration semble être incroyablement rare dans les arts. La conception par comité est un synonyme de mauvaise conception. Pourquoi en est-il 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 exige un dictateur. L'une des raisons est que la bonne conception doit être d'un seul tenant. La conception n'est pas seulement pour les humains, mais pour les humains individuels. Si une conception représente une idée qui s'inscrit dans la tête d'une personne, alors l'idée s'inscrira aussi dans la tête de l'utilisateur.