Philosophie d'UNIX

La philosophie d'Unix est un ensemble de normes et une approche du développement de logiciels basée sur l'expérience des principaux developpeurs du système d'exploitation Unix.

Sommaire 1 McIlroy: Un Quart de siècle d'Unix 2 Pike: Un mot sur la programmation en C 3 Mike Gancarz: La Philosophie Unix 4 Pire c'est mieux 5 Raymond: L'Art de la Programmation Unix 6 Controverse 7 Citations 8 Voir aussi 8.1 Articles connexes 8.2 Liens externes

McIlroy: Un Quart de siècle d'Unix

Douglas McIlroy, l'inventeur des tuyaux Unix ("Unix pipes" en anglais) et l'un des fondateurs de la tradition d'Unix, résume la philosophie comme suit:

"Voici la philosophie d'Unix:

Ecrivez des programmes qui effectuent une seule chose et qui le font bien.

Ecrivez des programmes qui collaborent.

Ecrivez des programmes pour gérer des flux de texte, car c'est une interface universelle."

Ce qui est souvent résumé par : "Ne faire qu'une seule chose, et la faire bien."

De ces trois doctrines, seule la troisième est spécifique à Unix, bien que les programmeurs en Unix les soulignent toutes les trois plus que les autres programmeurs.

Pike: Un mot sur la programmation en C

Rob Pike propose les règles suivantes sur Notes on Programming in C en tant que maximes sur la programmation, même si elles peuvent être aisément considérées comme étant des éléments d'une philosophie Unix:

• Règle n^o 1: Vous ne pouvez pas prévoir quelle partie d'un programme consommera le plus de temps. Les goulots d'étranglements se produisent en des parties surprenantes, alors n'essayez pas de deviner à l'avance où, et n'essayez pas d'optimiser le temps d'exécution avant d'avoir prouvé que le goulot d'étranglement se trouve là.

• Règle n^o 2: Mesurez. N'optimisez pas la vitesse avant d'avoir mesuré, et quand bien même, abstenez-vous de le faire tant qu'une partie du code prédomine sur le reste.

• Règle n^o 3: Les algorithmes élégants sont lents si n est petit, et n est petit la plupart du temps. Les algorithmes élégants comportent de grandes constantes. À moins d'être certains que n sera grand la plupart du temps, n'essayez pas de faire de l'élégance. (Même si n devient réellement grand, utilisez d'abord la règle n^o 2.)

• Règle n^o 4: Les algorithmes élégants comportent plus d'erreurs que ceux qui sont plus simples, et ils sont plus difficiles à appliquer. Utilisez des algorithmes simples ainsi que des structures de données simples.

• Règle n^o 5: Les données prévalent sur le code. Si vous avez conçu la structure des données appropriée et bien organisé le tout, les algorithmes viendront d'eux-mêmes. La structure des données est le cœur de la programmation, et non pas les algorithmes.
• Règle n^o 6: Il n'y a pas de règle n^o 6.

Les règles 1 et 2 de Pike reformulent la fameuse maxime de Charles Antony Richard Hoare: "L'optimisation du code prématurée est la cause de tous les maux."

Kenneth Thompson a reformulé les règles de Pike n^o 3 et n^o 4 par la phrase "En cas d'hésitation, utilisez la recherche exhaustive" (Ndt: en anglais "brute force"; Le sens est "N'essayez pas d'être malins, essayez d'abord d'être forts").

Les règles n^o 3 and n^o 4 sont des instances de la philosophie de conception KISS.

La règle n^o 5 fut énoncée auparavant par Fred Brooks dans The Mythical Man-Month.

Les Programming Pearls de Jon Bentley comportent aussi un chapitre sur le même principe de conception.

La règle 5 est souvent résumée par "Ecrivez du code stupide qui utilise des données fûtées". Elle est aussi une instance de la recommandation "Si la structure de vos données est suffisamment bonne, l'algorithme pour les utiliser sera évident."

La règle 6 est simplement une référence humoristique au sketch Bruces sketch des Monty Python. En C, une chaîne de caractère se termine par un caractère nul (valeur zéro), indiquant ainsi la longueur de la chaîne. La dernière règle se doit donc d'être nulle.

Mike Gancarz: La Philosophie Unix

En 1994 en:Mike Gancarz (un membre de l'équipe qui conçut le système X Window), utilisa son expérience personnelle sur Unix, ainsi que les débats avec ses amis programmeurs et avec des personnes d'autres domaines qui dépendaient d'Unix, pour produire La Philosophie Unix qui se résume à ces 9 préceptes:

1. La concision est merveilleuse.
2. Écrivez des programmes qui font une seule chose mais qui le font bien.
3. Concevez un prototype dès que possible.
4. Préférez la portabilité à l'efficacité.
5. Stockez les données en ASCII.
6. Utilisez le levier du logiciel à votre avantage.
7. Utilisez les scripts shell pour améliorer l'effet de levier et la portabilité.
8. Évitez les interfaces utilisateur captives.
9. Faites de chaque programme un filtre.

Les 10 doctrines suivantes sont celles qui ne sont pas universellement reconnues comme appartenant à la Philosophie Unix, et dont certaines sont vivement débattues (Monolithic kernel vs. Microkernels):

1. Permettre à l'utilisateur de régler son environnement.
2. Bâtir des noyaux de système d'exploitation petits et légers.
3. Utiliser les minuscules, en mots courts.
4. Economiser les arbres.
5. Le silence est d'or.
6. Penser en parallèle.
7. La somme des parties est supérieure à l'ensemble.
8. Rechercher la loi des 80%-20%.
9. Pire c'est mieux.
10. Penser hiérarchiquement.

Pire c'est mieux

Extrait de l'article: Worse is Better

Richard P. Gabriel suggère que le point clé pour UNIX est qu'il incarne un concept philosophique qu'il désigna par "Pire c'est mieux". Selon le principe de conception "Pire c'est mieux", la simplicité à la fois de l'interface et à la fois de l'implantation compte plus que n'importe quelle autre caractéristique du système — y compris l'exactitude, la cohérence et la complétude. Gabriel explique que le style de la conception possède des avantages évolutifs clés, quoiqu'il mette en doute la qualité de certains résultats.

Par exemple, au début sous UNIX les processus utilisateur effectuaient les appels au système sur la pile de l'utilisateur. Si un signal était transmis à un processus pendant qu'il était bloqué par une Entrée/Sortie de longue durée, comme par exemple sleep(10*60). Que faut-il faire dans ce cas ?

Le signal devrait-il être retardé, peut-être pour une longue durée (même indéfiniment) pendant que l'Entrée/Sortie se termine? Le gestionnaire de signaux ne pourrait pas être exécuté pendant que le processus est en mode noyau, ayant des données importantes sur la pile. Le noyau devrait-il repousser l'appel au système, l'entreposer pour le rejouer et le re-déclencher plus tard, en supposant que le gestionnaire de signaux se termine avec succès?

Dans ces exemples Ken Thompson et Dennis Ritchie ont préféré la simplicité à la perfection. Le système UNIX pouvait parfois retourner rapidement d'un appel au système avec une erreur déclarant qu'il n'avait rien fait - "L'appel au système interrompu" - une erreur numéro 4 (EINTR) dans les systèmes actuels.

Bien sûr, l'appel a été abandonné afin d'appeler le gestionnaire de signaux. Cela pourrait arriver pour une poignée d'appels au système ayant une exécution longue, comme read(), write(), open(), select(), etc.

L'avantage de ceci était de rendre le système d'E/S de nombreuses fois plus simple à concevoir et à comprendre. La grande majorité des programmes d'utilisateurs ne furent jamais affectés parce qu'ils ne géraient pas d'autres signaux que SIGINT, et qu'ils mourraient immédiatement si ce signal était déclenché. Pour les quelques autres programmes - comme des shells ou des éditeurs de texte qui répondent aux touches de contrôle de processus - de petits emballages pouvaient être ajoutés aux appels au système de manière à ré-essayer l'appel immédiatement si cette erreur EINTR était déclenchée. Problème résolu de manière simple.

Raymond: L'Art de la Programmation Unix

Eric S. Raymond, dans son livre The Art of Unix Programming, résume la philosophie Unix par la philosophie largement utilisée en ingéniérie, le principe KISS "Keep it Simple, Stupid" ["Reste Simple, Crétin" ou "Sois Simple et Concis"], connu aussi sous le nom du Rasoir d'Occam. Puis il décrit sa vision selon laquelle cette philosophie globale s'applique en tant que norme culturelle Unix, bien qu'on trouve sans surprise de graves violations de la plupart des règles Unix suivantes:

• Règle de Modularité: Écrire des éléments simples reliés par de bonnes interfaces.
• Règle de Clarté: La Clarté vaut mieux que l'ingéniosité.
• Règle de Composition: Concevoir des programmes qui peuvent être reliés à d'autres programmes.
• Règle de Séparation: Séparer les règles du fonctionnement; Séparer les interfaces du mécanisme.
• Règle de Simplicité: Concevoir pour la simplicité; ajouter de la complexité seulement par obligation.
• Règle de Parcimonie: Écrire un gros programme seulement lorsqu'il est clairement démontrable que c'est l'unique solution.
• Règle de Transparence: Concevoir pour la visibilité de façon à faciliter la revue et le déverminage.
• Règle de Robustesse: La robustesse est l'enfant de la transparence et de la simplicité.
• Règle de Représentation: Inclure le savoir dans les données, de manière à ce que l'algorithme puisse être bête et robuste.
• Règle de La moindre surprise: Pour la conception d'interface, réaliser la chose la moins surprenante.
• Règle du Silence: Quand un programme n'a rien d'étonnant à dire, il doit se taire.
• Règle de Dépannage: Si le programme échoue, il faut le faire bruyamment et le plus tôt possible.
• Règle d'Économie: Le temps de programmation est cher, le préserver par rapport au temps de la machine.
• Règle de Génération: Éviter la programmation manuelle; Écrire des programmes qui écrivent des programmes autant que possible.
• Règle d'Optimisation: Prototyper avant de fignoler. Mettre au point avant d'optimiser.
• Règle de Diversité: Se méfier des affirmations de "Unique bonne solution".
• Règle d'Extensibilité: Concevoir pour le futur, car il arrivera plus vite que prévu.

De nombreuses de ces règles sont reconnues en dehors de la communauté Unix — Que ce soit avant qu'Unix les utilise pour la première fois, ou après. De même, de nombreuses règles ne sont pas une exclusivité d'Unix ou ne sont pas originales. Cependant, les adeptes de la programmation Unix ont tendance à considérer que le style Unix est basé sur une combinaison de ces idées.

Controverse

Il existe une controverse pour déterminer si les programmes GNU de la Free Software Foundation similaires au programmes Unix standards (tels que diff, find, etc) obéissent à la "philosophie d'Unix" ou pas. Assurément, quelques anciens d'Unix au moins sont d'avis négatif, car les outils GNU sont souvent significativement plus volumineux et comportent plus de fonctionnalités que leur équivalent UNIX.

Dès 1983, Rob Pike a écrit un article critiquant l'augmentation des fonctionnalités des programmes de base Unix version BSD tels que cat[1]. Cette tendance n'a fait que se confirmer avec l'avènement des variantes Unix GNU et des Unix commercialisés, et il n'est plus rare pour un programme de fournir de nombreuses fonctionnalités basées sur la manière dont il est appelé (par exemple, un programme qui compresse ou qui décompresse un fichier selon le nom par lequel il est appelé; un exemple extrême est l'application embarquée BusyBox, qui regroupe, dans un seul fichier binaire, la plupart des fonctions en lignes de commande les plus communes).

Citations

• "Unix est simple. Il faut juste être un génie pour comprendre sa simplicité." – Dennis Ritchie
• "Unix n'a pas été conçu pour empêcher ses utilisateurs de commettre des actes stupides, car cela les empêcherait aussi de réaliser des actes ingénieux." – Doug Gwyn
• "Unix ne dit jamais 's'il vous plaît'." – Rob Pike
• "Unix est convivial. Cependant Unix ne précise pas vraiment avec qui." – Steven King
• "Ceux qui ne comprennent pas Unix sont condamnés à le ré-inventer, lamentablement." – Henry Spencer

Voir aussi

Articles connexes

• (en)L'article "Unix Philosophy" dont est tirée cette traduction

Liens externes

• The Unix Philosophy: A Brief Introduction - by The Linux Information Project (LINFO)
• Joel on Software - Biculturalism

• Portail de l’informatique