» 
allemand anglais arabe bulgare chinois coréen croate danois espagnol estonien finnois français grec hébreu hindi hongrois islandais indonésien italien japonais letton lituanien malgache néerlandais norvégien persan polonais portugais roumain russe serbe slovaque slovène suédois tchèque thai turc vietnamien
allemand anglais arabe bulgare chinois coréen croate danois espagnol estonien finnois français grec hébreu hindi hongrois islandais indonésien italien japonais letton lituanien malgache néerlandais norvégien persan polonais portugais roumain russe serbe slovaque slovène suédois tchèque thai turc vietnamien

définition - Philosophie d'Unix

voir la définition de Wikipedia

   Publicité ▼

dictionnaire collaboratif

Vous pouvez participer à l'enrichissement du dictionnaire et proposer vos propres définitions pour ce mot ou un autre.

Inscription possible avec votre compte Facebook

Wikipedia

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

Sommaire

  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. ».

  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 no 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 no 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 no 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 no 2.)
  • Règle no 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 no 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 no 6 : Il n'y a pas de règle no 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 no 3 et no 4 par la phrase « En cas d'hésitation, utilisez la recherche exhaustive »[1] ; le sens est « N'essayez pas d'être malins, essayez d'abord d'être forts.».

Les règles no 3 et no 4 sont des instances de la philosophie de conception KISS.

La règle no 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.

  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.

  Pire c'est mieux

Extrait de l'article: Worse is Better

Richard P. Gabriel (en) 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 ce principe de conception, 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énierie, 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. 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 (en).

  Notes et références

  1. Ndt: en anglais "brute force"

(en) Cet article est partiellement ou en totalité issu de l’article en anglais intitulé « Unix Philosophy » (voir la liste des auteurs)

  Voir aussi

  Articles connexes

  Liens externes

   
               

 

Toutes les traductions de Philosophie d'Unix


Contenu de sensagent

  • définitions
  • synonymes
  • antonymes
  • encyclopédie

Dictionnaire et traducteur pour mobile

⇨ Nouveau : sensagent est maintenant disponible sur votre mobile

   Publicité ▼

sensagent's office

Raccourcis et gadgets. Gratuit.

* Raccourci Windows : sensagent.

* Widget Vista : sensagent.

dictionnaire et traducteur pour sites web

Alexandria

Une fenêtre (pop-into) d'information (contenu principal de Sensagent) est invoquée un double-clic sur n'importe quel mot de votre page web. LA fenêtre fournit des explications et des traductions contextuelles, c'est-à-dire sans obliger votre visiteur à quitter votre page web !

Essayer ici, télécharger le code;

SensagentBox

Avec la boîte de recherches Sensagent, les visiteurs de votre site peuvent également accéder à une information de référence pertinente parmi plus de 5 millions de pages web indexées sur Sensagent.com. Vous pouvez Choisir la taille qui convient le mieux à votre site et adapter la charte graphique.

Solution commerce électronique

Augmenter le contenu de votre site

Ajouter de nouveaux contenus Add à votre site depuis Sensagent par XML.

Parcourir les produits et les annonces

Obtenir des informations en XML pour filtrer le meilleur contenu.

Indexer des images et définir des méta-données

Fixer la signification de chaque méta-donnée (multilingue).


Renseignements suite à un email de description de votre projet.

Jeux de lettres

Les jeux de lettre français sont :
○   Anagrammes
○   jokers, mots-croisés
○   Lettris
○   Boggle.

Lettris

Lettris est un jeu de lettres gravitationnelles proche de Tetris. Chaque lettre qui apparaît descend ; il faut placer les lettres de telle manière que des mots se forment (gauche, droit, haut et bas) et que de la place soit libérée.

boggle

Il s'agit en 3 minutes de trouver le plus grand nombre de mots possibles de trois lettres et plus dans une grille de 16 lettres. Il est aussi possible de jouer avec la grille de 25 cases. Les lettres doivent être adjacentes et les mots les plus longs sont les meilleurs. Participer au concours et enregistrer votre nom dans la liste de meilleurs joueurs ! Jouer

Dictionnaire de la langue française
Principales Références

La plupart des définitions du français sont proposées par SenseGates et comportent un approfondissement avec Littré et plusieurs auteurs techniques spécialisés.
Le dictionnaire des synonymes est surtout dérivé du dictionnaire intégral (TID).
L'encyclopédie française bénéficie de la licence Wikipedia (GNU).

Copyright

Les jeux de lettres anagramme, mot-croisé, joker, Lettris et Boggle sont proposés par Memodata.
Le service web Alexandria est motorisé par Memodata pour faciliter les recherches sur Ebay.
La SensagentBox est offerte par sensAgent.

Traduction

Changer la langue cible pour obtenir des traductions.
Astuce: parcourir les champs sémantiques du dictionnaire analogique en plusieurs langues pour mieux apprendre avec sensagent.

Dernières recherches dans le dictionnaire :

2631 visiteurs en ligne

calculé en 0,031s

Je voudrais signaler :
section :
une faute d'orthographe ou de grammaire
un contenu abusif (raciste, pornographique, diffamatoire)
une violation de copyright
une erreur
un manque
autre
merci de préciser :

Mon compte

connexion

inscription

   Publicité ▼