dorianmarie.com | Paul Graham | Legal | Terms | Privacy
Chapitre 15
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 soignée. 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 lui 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 se tournera immédiatement vers d’autres sujets.
Je ne me considère pas comme faisant des recherches sur les langages de programmation. J’en conçois juste 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 faire un langage dans lequel il sera bon de programmer.
La différence entre le design et la recherche semble être une question de nouveau par rapport au bien. Le design n’a pas besoin d’être nouveau, mais il doit être bon. La recherche n’a pas besoin d’être bonne, mais elle doit être nouvelle. Je pense que ces deux voies convergent au sommet : le meilleur signe 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 la peine d’être résolus. Donc, en fin de compte, la conception et la recherche visent la même destination, en l’abordant simplement dans des directions différentes.
Que faites-vous différemment lorsque vous traitez les langages de programmation comme un problème de conception au lieu d’un sujet de recherche ?
La plus grande différence est que vous vous concentrez davantage sur l’utilisateur. Le design commence par demander à qui s’adresse-t-il et de quoi en 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éterminant ce dont ils ont besoin.
Notez ici 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 à court terme, en faisant tout 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 dans lequel le meilleur travail est fait par les gens qui font exactement ce que les clients leur disent.
Le client a toujours raison en ce sens que la mesure d’une bonne conception est de savoir à quel point elle fonctionne bien pour l’utilisateur. Si vous faites un roman qui ennuie tout le monde, ou une chaise dans laquelle il est horriblement inconfortable de s’asseoir, 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 savent pas quels sont tous les choix et se trompent souvent sur ce qu’ils veulent vraiment. C’est comme être médecin. Vous ne pouvez pas simplement traiter les symptômes d’un patient. Lorsqu’un patient vous dit ses symptômes, vous devez comprendre ce qui ne va pas chez lui et traiter cela.
Cet accent mis sur l’utilisateur est une sorte d’axiome à partir duquel la majeure partie de la pratique d’une bonne conception peut être dérivée, et autour duquel la plupart des problèmes de conception sont centrés.
Quand je dis que la conception doit être pour les utilisateurs, je ne veux pas laisser entendre qu’une 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 un bon design pour un groupe pourrait être mauvais pour un autre. Le fait est que vous devez choisir un groupe d’utilisateurs. Je ne pense même pas que vous puissiez parler de bon ou de mauvais design, sauf en référence à un utilisateur prévu.
Vous êtes plus susceptible d’obtenir un bon design si les utilisateurs prévus incluent le concepteur lui-même. Lorsque vous concevez quelque chose pour un groupe qui ne vous inclut pas, cela a tendance à être pour les personnes que vous considérez moins sophistiqué que vous, pas plus sophistiqué. Et regarder l’utilisateur, aussi bienveillant soit-il, semble toujours corrompre le concepteur. Je soupçonne que peu de projets de logements aux États-Unis ont été conçus par des architectes qui s’attendaient à y vivre. Vous voyez la même chose dans les langages de programmation. C, Lisp et Smalltalk ont été créés pour leurs propres concepteurs. Cobol, Ada et Java ont été créés pour que d’autres personnes les utilisent.
Si vous pensez que vous concevez quelque chose pour les idiots, il y a de fortes chances que vous ne conceviez pas quelque chose de bon, même pour les idiots.
Même si vous concevez quelque chose pour les utilisateurs les plus sophistiqués, vous concevez toujours pour les 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 celle qui rend 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.
Dans les arts, les choses sont différentes. Le design est une question de peuple. 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 aucun moyen de le contourner. Tous les arts doivent se plier aux intérêts et aux limites des humains. En peinture, par exemple, toutes les autres choses étant égales à une peinture avec des personnes dedans seront plus intéressantes qu’une sans. Ce n’est pas seulement un accident de l’histoire que les grandes peintures de la Renaissance soient toutes pleines de gens. S’ils ne l’avaient pas été, la peinture en tant que médium n’aurait pas le prestige qu’elle a.
Qu’on les aime ou non, les langages de programmation sont aussi pour les gens, et je soupçonne que le cerveau humain est tout aussi grumeleux et idiosyncrasique que le corps humain. Certaines idées sont faciles à saisir pour les gens et d’autres pas. Par exemple, nous semblons avoir une capacité très limitée pour traiter 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 le détail, nous pourrions simplement programmer en langage machine. Rappelez-vous également que les langages ne sont pas principalement une forme pour les programmes terminés, mais quelque chose dans lequel les programmes doivent être mis au point. N’importe qui dans les arts pourrait vous dire que vous pourriez vouloir différents moyens pour les deux situations. Le marbre, par exemple, est un moyen agréable et durable pour les idées finies, mais un moyen désespérément flexible 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 et s’est ramifié partout. Le test d’un langage n’est donc pas simplement la propreté du programme fini, mais la propreté du chemin vers le programme terminé. 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 qui définissent des macros qui ressemblent maintenant à de petits joyaux, mais les écrire a pris des heures d’essais et d’erreurs les plus laides, et franchement, je ne suis toujours pas tout à fait sûr qu’elles soient correctes.
Nous agissons souvent comme si le test d’une langue était la qualité des programmes finis. Cela semble tellement convaincant quand vous voyez le même programme écrit en deux langues, et qu’une version est beaucoup plus courte. Lorsque vous abordez le problème de la direction des arts, vous êtes moins susceptible de dépendre de ce type de test. Vous ne voulez pas vous retrouver avec un langage de programmation comme le marbre.
Par exemple, c’est une énorme victoire dans le développement de logiciels d’avoir un niveau supérieur interactif, ce que l’on appelle dans Lisp une boucle de lecture-eval-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. Lorsque vous ne faites que taper des expressions au niveau supérieur, vous voulez être en mesure de définir x sur une certaine valeur, puis de commencer à faire des choses sur x. Vous ne voulez pas avoir à déclarer le type de x en premier. Vous pouvez contester l’un ou l’autre des locaux, 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.
Pour obtenir un bon design, vous devez vous rapprocher, et rester proche, de vos utilisateurs. Vous devez constamment calibrer vos idées sur les utilisateurs réels. L’une des raisons pour lesquelles les romans de Jane Austen sont si bons est qu’elle les a lus à haute voix à sa famille. C’est pourquoi elle ne coule jamais dans des descriptions d’auto-indulgence et artistiques 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 que vous imaginez le lire à haute voix à vos amis comme quelque chose que vous aviez écrit, vous sentirez trop vivement à quel point ce genre de chose est imposé au lecteur.
Dans le monde des logiciels, 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, c’est pourquoi les gens se disputent toujours pour savoir si pire est en fait mieux ou non. Mais l’une des principales idées de 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 s’appeler la stratégie du Je vous salue Marie. Au lieu de sortir un prototype rapidement et de le réafiner progressivement, vous essayez de créer le produit complet et fini en une longue passe de touchdown. D’innombrables startups se sont détruites de cette façon pendant l’Internet Bubble. 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 trouve dans tous les arts. En dessin, par exemple, l’idée a été découverte à 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 vous frayer un chemin lentement autour du contour d’un objet, car les erreurs s’accumuleront et vous constaterez à la fin que les lignes ne se rencontrent 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é fabriqués à partir de différents matériaux. Les polices de caractères à couper en métal ont d’abord été conçues avec un pinceau sur papier. Les statues à couler en bronze ont été modelées à la cire. Les motifs à broder sur les tapisseries ont été dessinés sur du papier avec un lavage à l’encre. Les bâtiments à construire en pierre ont été testés à plus petite échelle en bois.
Ce qui a rendu la peinture à l’huile si excitante, lorsqu’elle est devenue populaire pour la première fois au XVe siècle, c’est que vous pouviez faire le travail fini à partir du prototype. Vous pourriez faire un dessin préliminaire si vous le vouliez, mais vous n’y étiez pas tenu ; vous pouviez régler tous les détails, et même apporter des changements majeurs, au fur et à mesure que vous aviez terminé la peinture. Vous pouvez également le faire dans un logiciel. Un prototype n’a pas besoin d’être un simple modèle ; vous pouvez l’affiner en produit fini. Je pense que vous devriez toujours le faire quand vous le pouvez. Il vous permet de tirer parti des nouvelles informations que vous avez en cours de route. Mais peut-être encore plus important, c’est bon pour le moral.
Le moral est la clé du design. 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 quand vous dessinez 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 voulez, mais si vous vous ennuyez à mi-chemin et que vous commencez à fabriquer les briques 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 affinant progressivement un prototype est bon pour le moral parce qu’il vous maintient engagé. Dans les logiciels, ma règle est : ayez toujours un code de travail. Si vous écrivez quelque chose que vous pourrez tester en une heure, 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 l’affinent progressivement. Si vous travaillez de cette façon, alors en principe, vous n’avez jamais à terminer la journée avec quelque chose qui semble inachevé. En effet, il y a même un dicton parmi les peintres : « Une peinture n’est jamais finie. Vous arrêtez simplement 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 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 bien, il faut penser : « waouh, c’est vraiment génial », pas « quelle merde ; ces imbéciles vont adorer ça ».
Le design signifie faire des choses pour les humains. Mais ce n’est pas seulement l’utilisateur qui est humain. Le designer est aussi humain.