PROGRAMMATION ASCENDANTE

Janvier 1993

(Cet essai est tiré de l'introduction deOn Lisp.)

C'est un principe bien établi du style de programmation que les éléments fonctionnels d'un programme ne doivent pas être trop volumineux. Si un composant d'un programme dépasse le stade où il est facilement compréhensible, il devient une masse de complexité qui cache les erreurs aussi facilement qu'une grande ville cache les fugitifs. Ce type de logiciel sera difficile à lire, à tester et à déboguer.

Conformément à ce principe, un grand programme doit être divisé en morceaux, et plus le programme est grand, plus il doit être divisé. Comment divise-t-on un programme ? L'approche traditionnelle s'appelle la conception descendante : on dit "l'objectif du programme est d'effectuer ces sept choses, donc je le divise en sept sous-routines principales. La première sous-routine doit faire ces quatre choses, donc elle aura à son tour quatre sous-routines", et ainsi de suite. Ce processus se poursuit jusqu'à ce que le programme ait le bon niveau de granularité - chaque partie suffisamment grande pour faire quelque chose de substantiel, mais suffisamment petite pour être comprise comme une seule unité.

Les programmeurs Lisp expérimentés divisent leurs programmes différemment. En plus de la conception descendante, ils suivent un principe qu'on pourrait appeler la conception ascendante - modifier le langage pour s'adapter au problème. En Lisp, vous n'écrivez pas simplement votre programme vers le bas du langage, vous construisez aussi le langage vers le haut de votre programme. Pendant que vous écrivez un programme, vous pouvez penser "J'aimerais que Lisp ait un opérateur comme celui-ci". Alors vous allez l'écrire. Ensuite, vous réalisez que l'utilisation du nouvel opérateur simplifierait la conception d'une autre partie du programme, et ainsi de suite. Le langage et le programme évoluent ensemble. Comme la frontière entre deux États en guerre, la limite entre le langage et le programme est tracée et retracée, jusqu'à ce qu'elle finisse par se fixer le long des montagnes et des rivières, les frontières naturelles de votre problème. À la fin, votre programme aura l'air d'avoir été conçu pour ce langage. Et lorsque le langage et le programme s'adaptent bien l'un à l'autre, vous obtenez un code clair, concis et efficace.

Il vaut la peine de souligner que la conception ascendante ne signifie pas simplement écrire le même programme dans un ordre différent. Quand vous travaillez de bas en haut, vous finissez généralement par obtenir un programme différent. Au lieu d'un programme monolithique unique, vous obtiendrez un langage plus vaste avec des opérateurs plus abstraits, et un programme plus petit écrit dans ce langage. Au lieu d'un linteau, vous obtiendrez une arche.

Dans un code typique, une fois que vous avez extrait les parties qui ne sont que de la comptabilité, ce qui reste est beaucoup plus court ; plus vous construisez le langage, moins vous aurez à parcourir la distance du haut vers le bas pour l'atteindre. Cela apporte plusieurs avantages :

En faisant faire plus de travail par le langage, la conception ascendante produit des programmes plus petits et plus agiles. Un programme plus court n'a pas besoin d'être divisé en autant de composants, et moins de composants signifie des programmes plus faciles à lire ou à modifier. Moins de composants signifie aussi moins de connexions entre les composants, et donc moins de risque d'erreurs à cet endroit. Comme les concepteurs industriels s'efforcent de réduire le nombre de pièces mobiles dans une machine, les programmeurs Lisp expérimentés utilisent la conception ascendante pour réduire la taille et la complexité de leurs programmes.

La conception ascendante favorise la réutilisation du code. Lorsque vous écrivez deux programmes ou plus, de nombreuses utilitaires que vous avez écrits pour le premier programme seront également utiles pour les suivants. Une fois que vous avez acquis un large substrat d'utilitaires, l'écriture d'un nouveau programme ne peut prendre qu'une fraction de l'effort qu'il faudrait si vous deviez partir de Lisp brut.

La conception ascendante rend les programmes plus faciles à lire.

Une instance de ce type d'abstraction demande au lecteur de comprendre un opérateur à usage général ; une instance d'abstraction fonctionnelle demande au lecteur de comprendre une sous-routine à usage spécial. [1]

Parce qu'elle vous amène toujours à être à l'affût des modèles dans votre code, la conception ascendante vous aide à clarifier vos idées sur la conception de votre programme. Si deux composants éloignés d'un programme ont une forme similaire, vous serez amené à remarquer cette similitude et peut-être à concevoir le programme d'une manière plus simple.

La conception ascendante est possible dans une certaine mesure dans des langages autres que Lisp. Chaque fois que vous voyez des fonctions de bibliothèque, la conception ascendante est en train de se produire. Cependant, Lisp vous donne des pouvoirs beaucoup plus larges dans ce domaine, et l'augmentation du langage joue un rôle proportionnellement plus important dans le style Lisp - à tel point que Lisp n'est pas seulement un langage différent, mais une façon complètement différente de programmer.

Il est vrai que ce style de développement convient mieux aux programmes qui peuvent être écrits par de petits groupes. Cependant, en même temps, il repousse les limites de ce qui peut être fait par un petit groupe. Dans The Mythical Man-Month, Frederick Brooks a proposé que la productivité d'un groupe de programmeurs n'augmente pas linéairement avec sa taille. Plus la taille du groupe augmente, plus la productivité des programmeurs individuels diminue. L'expérience de la programmation Lisp suggère une formulation plus optimiste de cette loi : plus la taille du groupe diminue, plus la productivité des programmeurs individuels augmente. Un petit groupe gagne, relativement parlant, simplement parce qu'il est plus petit. Lorsqu'un petit groupe tire également parti des techniques que Lisp rend possibles, il peut gagner tout court.

Nouveau : Téléchargez On Lisp gratuitement.

[1] "Mais personne ne peut lire le programme sans comprendre tous vos nouveaux utilitaires." Pour voir pourquoi de telles affirmations sont généralement erronées, voir la section 4.8.