Page suivante Page précédente Table des matières

8. Quelques enseignements supplémentaires tirés de fetchmail

Avant de retourner à des sujets plus généraux du génie logiciel, il nous reste à méditer sur quelques leçons supplémentaires tirées de l'expérience de fetchmail.

La syntaxe du fichier rc spécifie quelques mots clés ``parasites'' optionnels, complètement ignorés par l'analyseur syntaxique. Ils permettent l'utilisation d'une syntaxe proche de la langue anglaise, nettement plus lisible que les traditionnels, et spartiates, couples mot clé-valeur qu'on peut lire quand on ne garde que l'indispensable.

L'idée m'est venue tard un soir, alors que je remarquais combien ces déclarations du fichier rc commençaient à prendre l'allure d'un mini-langage impératif. (C'est aussi la raison pour laquelle j'ai remplacé le mot clé `server' (serveur), originalement présent dans popclient, par `poll' (vérification de la présence d'activité)).

Il m'a semblé que rendre ce mini-langage plus proche de l'anglais en rendrait l'utilisation plus aisée. Il me faut préciser que, bien que farouche partisan de l'école de conception ``faites-en un langage'', illustrée par des outils comme Emacs, HTML et de nombreux moteurs de bases de données, je ne suis pas, d'habitude, un admirateur des syntaxes ``à l'anglaise''.

De manière traditionnelle, les programmeurs ont eu tendance à favoriser des syntaxes de contrôle très précises et compactes, sans redondance. Il s'agit d'un héritage culturel du temps où les ressources informatiques coûtaient cher, et où il fallait donc rendre les étapes d'analyse syntaxique aussi courtes et simples que possible. La langue anglaise, pour moitié redondante, semblait alors un modèle très peu approprié.

Ce n'est pas la raison pour laquelle je dénonce la non utilisation de syntaxes naturelles; je n'en fais mention ici que pour mieux la démolir. Maintenant que les ressources informatiques sont pléthore, l'austérité ne doit pas être une fin en soi. De nos jours, il est plus important qu'un langage soit facilement compréhensible par les humains plutôt que par les ordinateurs.

Il existe, en revanche, de bonnes raisons pour se méfier. L'une d'entre elles est le coût en complexité de la phase d'analyse syntaxique -- vous n'avez certainement pas envie d'en faire une source non négligeable de bogues. Vous n'avez pas envie non plus que la complexité de votre langage déroute l'utilisateur. Une autre raison est que les tentatives de rendre la syntaxe d'un langage similaire à l'anglais, aboutissent le plus souvent à un telle déformation de cet ``anglais'' que cette ressemblance superficielle au langage naturel provoque autant de confusion que ne l'aurait fait une syntaxe traditionnelle. (C'est le cas de nombreux langages prétendument de quatrième génération et des langages de requêtes dans des bases de données commerciales.)

La syntaxe permettant de contrôler fetchmail évite ces deux écueils parce que le domaine du langage est très restreint. Il n'est en rien un langage généraliste; il se contente de dire des choses simples, de telle sorte qu'il est difficile de se tromper en transposant mentalement un minuscule sous-ensemble de l'anglais au langage de contrôle en lui-même. Je pense qu'il y a ici matière à une leçon plus générale:

16. Quand votre langage est loin d'être Turing équivalent

NdT c'est le cas par exemple des langages de programmation
, un peu de ``sucre syntaxique'' ne peut qu'aider.

Une autre leçon concerne la sécurité par hermétisme (utilisant par exemple des mots de passes secrets). Certains utilisateurs de fetchmail m'ont demandé de modifier le logiciel de manière à stocker des mots de passe chiffrés dans le fichier rc, de telle sorte que les petits malins ne puissent les lire directement.

Je ne l'ai pas fait, parce que cela n'apporte aucune protection supplémentaire. Quiconque a obtenu le droit de lire votre fichier rc pourra lancer fetchmail sous votre identité de toutes manières -- et s'il en a après votre mot de passe, il pourra toujours extraire du code de fetchmail le décodeur nécessaire pour le déchiffrer.

Tout ce qu'un chiffrement de mots de passe dans le fichier .fetchmailrc aurait apporté, c'est un sentiment de sécurité infondé à ceux qui connaissent mal les problèmes de sécurité. La règle générale est ici:

17. Un système de sécurité n'est pas plus sûr que le secret (la clé) qui le garde. Gare aux pseudo secrets !


Page suivante Page précédente Table des matières