Filosofia unix
La Filosofía Unix es un conjunto de normas culturales y enfoques filosóficos para el desarrollo de software basados en la experiencia de los principales desarrolladores del sistema operativo Unix .
McIlroy: Un cuarto de siglo de Unix
Doug McIlroy , el inventor de las tuberías Unix y uno de los fundadores de la tradición Unix, resumió la filosofía de la siguiente manera:
"La filosofía Unix dice:
Escriba
programas que hagan una cosa y la hagan bien.
Escribir programas que funcionen juntos.
Escriba programas que admitan
secuencias de texto porque es una interfaz genérica".
Por lo general, estas declaraciones se reducen a una sola cosa: "Haz una cosa, pero hazla bien".
De estos tres principios, solo el tercero es específico de Unix, aunque los desarrolladores de Unix son más propensos que otros a enfatizar los tres principios.
Mike Guntzarz: La Filosofía Unix
En 1994, Mike Gancarz combinó su experiencia con Unix (es miembro del equipo de desarrollo de X Window System ) con comentarios de discusiones que tuvo con colegas programadores y personas de otros campos, dependiendo de Unix de una forma u otra, para crear el Filosofía Unix , que se reduce a 9 principios básicos:
- Bellamente pequeño.
- Que cada programa haga una cosa, pero bueno.
- Cree un programa prototipo lo antes posible.
- Prefiere la portabilidad a la eficiencia.
- Almacenar datos en archivos de texto sin formato.
- Benefíciese de las soluciones de software existentes.
- Use lenguajes de secuencias de comandos para reducir los costos de mano de obra y mejorar la portabilidad.
- Evite las interfaces de usuario que limitan la capacidad del usuario para interactuar con el sistema.
- Haz de cada programa un "filtro".
Los 10 principios menos importantes no se han aceptado universalmente como parte de la filosofía de Unix y, en algunos casos, han sido objeto de un acalorado debate ( núcleo monolítico frente a micronúcleo ):
- Deje que el usuario personalice el entorno.
- Mantenga los núcleos del sistema operativo pequeños y livianos.
- Use minúsculas y mantenga los títulos cortos.
- No guarde los textos del programa en forma de copias impresas ("¡Salvemos los árboles!").
- No le digas al usuario lo obvio ("El silencio es oro").
- Divida las tareas complejas en tareas simples y paralelas ("Piense en paralelo").
- Las partes combinadas del todo son más que su suma.
- Buscando una solución del 90 por ciento .
- Si es posible no agregar nueva funcionalidad, no la agregue (" Cuanto peor, mejor ").
- Piensa jerárquicamente.
Raymond: El arte de la programación Unix
Eric Raymond ( ing. Eric S. Raymond ), en El arte de la programación de Unix, resumió la filosofía de Unix como la filosofía de ingeniería de uso común "Mantenlo simple, tonto" ( el principio KISS ). Luego describió cómo esta filosofía generalizada se aplica como normas culturales de Unix. Esto es a pesar del hecho de que es fácil encontrar varias violaciones en la siguiente filosofía actual de Unix:
- Regla de Modularidad: Escriba partes simples conectadas por interfaces comprensibles.
- Regla de la claridad: la claridad es mejor que la inteligencia.
- Regla de Composición: Diseñar programas para que puedan ser conectados a otros programas.
- Regla de separación: Separar las reglas ( política ) del mecanismo ( mecanismo ); separe la interfaz del motor .
- Regla de la simplicidad: apunte a la simplicidad; añadir complejidad sólo cuando sea necesario.
- Regla de parsimonia: escriba un programa grande solo cuando otros medios no logren realizar la tarea deseada.
- Regla de transparencia: Desarrollar programas transparentes para facilitar su posterior revisión y depuración.
- Regla de confiabilidad: la confiabilidad es hija de la transparencia y la simplicidad.
- Regla de representación: almacene conocimiento en datos para que la lógica del programa sea tonta y robusta.
- Regla de la menor sorpresa : al diseñar una interfaz, siempre haga que los elementos familiares de la interfaz realicen funciones familiares.
- Regla del silencio: si el programa no tiene nada que decir, es mejor guardar silencio.
- Regla de recuperación: si un programa debe bloquearse, hágalo de forma ruidosa y lo más rápido posible.
- Regla de economía: el tiempo de un programador es precioso; acortarlo usando tiempo de máquina.
- Regla de generación: Evite la codificación manual; siempre que sea posible, escriba programas que escriban programas.
- Regla de optimización: primero, un prototipo, luego, "peinar". Logre un funcionamiento estable, solo luego optimice.
- Regla de la diversidad: Rechazar todas las afirmaciones de "la única forma correcta".
- Regla de extensibilidad: Diseño para el futuro. Llegará más rápido de lo que piensas.
La mayoría de estas convenciones se aceptan fuera de la comunidad de Unix; incluso si no lo eran cuando se aplicaron por primera vez a Unix, ahora lo son. Además, muchas reglas no son exclusivas ni originales de la comunidad de Unix. Sin embargo, los seguidores de la programación Unix tienden a aceptar una combinación de estas ideas como base para el estilo Unix.
Cotizaciones
- Unix es simple. Pero tienes que ser un genio para entender su simplicidad " -Dennis Ritchie .
- " Unix no está diseñado para proteger a sus usuarios de cosas estúpidas, porque eso también los protegería de cosas inteligentes " - Doug Gwin .
- " Unix nunca dice por favor" - Rob Pike .
Crítica
El manual UNIX-HATERS
La filosofía UNIX fue criticada en The UNIX-HATERS Handbook , publicado a principios de la década de 1990.
- Según los editores del libro, el enfoque de Unix conduce a decisiones tomadas apresuradamente, sin la reflexión adecuada a través de la arquitectura, después de lo cual estas decisiones son canonizadas (consagradas), es decir, son declaradas clásicas eternas. Por ejemplo, en su opinión, dicha solución es bloquear archivos: archivos temporales sin contenido, creados como una marca del hecho de que algún programa está en proceso de ejecución.
- El sistema X Window ha sido criticado por separar el motor de la política, lo que ha llevado a la falta de un estándar UNIX para las políticas de control de la interfaz de usuario y a una gran dificultad para desarrollar aplicaciones que utilizan la GUI .
- NFS ha sido criticado por su enfoque intrínsecamente defectuoso de la arquitectura: un intento de crear un servidor de archivos sin estado, a pesar de que esto es fundamentalmente imposible. Cuando la imposibilidad de admitir algunas cosas importantes se hizo evidente, se atornilló a NFS una "muleta" llamada proceso lockd.
Pero, al mismo tiempo, los enfoques criticados en este libro, que comenzó en *NIX, se justifican sin problemas en Microsoft Windows y Apple Mac OS .
Notas
Enlaces