Philosophie d'Unix - Définition

Introduction

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 développeurs du système d'exploitation Unix.

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 :

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

Écrivez des programmes qui collaborent.

Écrivez 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.

Mike Gancarz : La Philosophie Unix

En 1994, Mike Gancarz (en) (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 neuf 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 (en) pour améliorer l'effet de levier et la portabilité.
8. Évitez les interfaces utilisateur captives.
9. Faites de chaque programme un filtre.

Les dix 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. Économiser 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 (en).
10. Penser hiérarchiquement.

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 » ; 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 (en) de Jon Bentley comportent aussi un chapitre sur le même principe de conception.

La règle 5 est souvent résumée par « Écrivez du code stupide qui utilise des données futé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 (en) 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.