Filosofía Unix

La filosofía Unix , originada por Ken Thompson , es un conjunto de normas culturales y enfoques filosóficos para el desarrollo de software modular y minimalista . Se basa en la experiencia de los principales desarrolladores del sistema operativo Unix . Los primeros desarrolladores de Unix fueron importantes a la hora de llevar los conceptos de modularidad y reutilización a la práctica de la ingeniería de software, lo que generó un movimiento de " herramientas de software ". Con el tiempo, los principales desarrolladores de Unix (y los programas que se ejecutaban en él) establecieron un conjunto de normas culturales para el desarrollo de software; estas normas se volvieron tan importantes e influyentes como la tecnología de Unix en sí, y se las ha denominado "filosofía Unix".

La filosofía Unix enfatiza la creación de código simple, compacto, claro, modular y extensible que pueda ser fácilmente mantenido y reutilizado por desarrolladores distintos de sus creadores. La filosofía Unix favorece la componibilidad en lugar del diseño monolítico .

La filosofía Unix está documentada por Doug McIlroy ^[1] en el Bell System Technical Journal de 1978: ^[2]

1. Haga que cada programa haga bien una cosa. Para hacer un trabajo nuevo, cree uno nuevo en lugar de complicar los programas antiguos agregando nuevas "funciones".
2. Espere que la salida de cada programa se convierta en la entrada de otro programa, aún desconocido. No sature la salida con información superflua. Evite formatos de entrada estrictamente binarios o en columnas. No insista en una entrada interactiva.
3. Diseñe y cree software, incluso sistemas operativos, para probarlos en una fase temprana, idealmente en cuestión de semanas. No dude en desechar las piezas defectuosas y reconstruirlas.
4. Utilice herramientas en lugar de ayuda no especializada para aligerar una tarea de programación, incluso si tiene que desviarse para construir las herramientas y espera tirar algunas de ellas después de haber terminado de usarlas.

Más tarde, Peter H. Salus lo resumió en Un cuarto de siglo de Unix (1994): ^[1]

• Escriba programas que hagan una cosa y la hagan bien.
• Escribe programas para que trabajen juntos.
• Escriba programas para manejar flujos de texto, porque esa es una interfaz universal.

En su artículo sobre Unix de 1974, Ritchie y Thompson citan las siguientes consideraciones de diseño: ^[3]

• Facilite la escritura, prueba y ejecución de programas.
• Uso interactivo en lugar de procesamiento por lotes .
• Economía y elegancia de diseño debido a las limitaciones de tamaño ("salvación a través del sufrimiento").
• Sistema autosuficiente : todo el software Unix se mantiene bajo Unix.

En su prefacio al libro de 1984, The UNIX Programming Environment , Brian Kernighan y Rob Pike , ambos de Bell Labs , dan una breve descripción del diseño de Unix y la filosofía de Unix: ^[4]

Aunque el sistema UNIX introduce una serie de programas y técnicas innovadores, no hay un programa o idea que lo haga funcionar bien. Lo que lo hace eficaz es el enfoque de la programación, una filosofía de uso de la computadora. Aunque esa filosofía no se puede resumir en una sola frase, en su núcleo está la idea de que el poder de un sistema proviene más de las relaciones entre los programas que de los programas en sí. Muchos programas UNIX hacen cosas bastante triviales de forma aislada, pero, combinados con otros programas, se convierten en herramientas generales y útiles.

Los autores escriben además que su objetivo con este libro es "comunicar la filosofía de programación UNIX". ^[4]

En octubre de 1984, Brian Kernighan y Rob Pike publicaron un artículo titulado Program Design in the UNIX Environment (Diseño de programas en el entorno UNIX ) . En este artículo, critican la acumulación de opciones y características de los programas que se encuentran en algunos sistemas Unix más nuevos, como 4.2BSD y System V , y explican la filosofía Unix de las herramientas de software, cada una de las cuales realiza una función general: ^[5]

Gran parte de la potencia del sistema operativo UNIX proviene de un estilo de diseño de programas que hace que los programas sean fáciles de usar y, lo que es más importante, fáciles de combinar con otros programas. Este estilo se ha denominado uso de herramientas de software y depende más de cómo los programas encajan en el entorno de programación y de cómo se pueden utilizar con otros programas que de cómo están diseñados internamente. [...] Este estilo se basaba en el uso de herramientas : utilizar programas por separado o en combinación para realizar un trabajo, en lugar de hacerlo a mano, mediante subsistemas monolíticos autosuficientes o mediante programas especiales de un solo uso.

Los autores contrastan herramientas Unix como cat con conjuntos de programas más grandes utilizados por otros sistemas. ^[5]

El diseño de cat es típico de la mayoría de los programas UNIX: implementa una función simple pero general que se puede utilizar en muchas aplicaciones diferentes (incluidas muchas que no fueron previstas por el autor original). Otros comandos se utilizan para otras funciones. Por ejemplo, hay comandos separados para tareas del sistema de archivos, como renombrar archivos, eliminarlos o indicar su tamaño. Otros sistemas, en cambio, agrupan todo esto en un solo comando de "sistema de archivos" con una estructura interna y un lenguaje de comandos propios. (El programa de copia de archivos PIP ^[6] que se encuentra en sistemas operativos como CP/M o RSX-11 es un ejemplo). Ese enfoque no es necesariamente mejor o peor, pero ciertamente va en contra de la filosofía UNIX.

McIlroy , entonces director del Centro de Investigación de Ciencias de la Computación de Bell Labs e inventor del Unix pipe , ^[7] resumió la filosofía Unix de la siguiente manera: ^[1]

Ésta es la filosofía de Unix: escribir programas que hagan una cosa y que la hagan bien. Escribir programas que funcionen juntos. Escribir programas que gestionen flujos de texto , porque esa es una interfaz universal.

Más allá de estas afirmaciones, también ha enfatizado la simplicidad y el minimalismo en la programación Unix: ^[1]

La noción de "complejidades intrincadas y hermosas" es casi un oxímoron. Los programadores de Unix compiten entre sí por el honor de ser "simples y hermosos", un punto que está implícito en estas reglas, pero que vale la pena dejar en claro.

Por el contrario, McIlroy ha criticado al Linux moderno por tener una hinchazón de software , señalando que "los admiradores adoradores han alimentado con las bondades de Linux hasta un estado desalentador de obesidad ". ^[8] Contrasta esto con el enfoque anterior adoptado en Bell Labs al desarrollar y revisar Research Unix : ^[9]

Todo era pequeño... y mi corazón se hunde por Linux cuando veo el tamaño. [...] La página del manual , que en realidad solía ser una página de manual , ahora es un pequeño volumen, con mil opciones... Solíamos sentarnos en la Sala Unix y decir: "¿Qué podemos descartar? ¿Por qué existe esta opción?". A menudo se debe a que hay alguna deficiencia en el diseño básico: no se ha dado con el punto de diseño correcto. En lugar de agregar una opción, piense en lo que lo obligó a agregar esa opción.

Como afirmó McIlroy y es generalmente aceptado en toda la comunidad Unix, siempre se ha esperado que los programas Unix sigan el concepto de DOTADIW, o "Do One Thing And Do It Well" (Hacer una cosa y hacerla bien). Existen fuentes limitadas para el acrónimo DOTADIW en Internet, pero se habla mucho de él durante el desarrollo y el empaquetado de nuevos sistemas operativos, especialmente en la comunidad Linux.

Patrick Volkerding , el líder del proyecto Slackware Linux , invocó este principio de diseño en una crítica a la arquitectura systemd , afirmando que "intentar controlar servicios, sockets, dispositivos, montajes, etc., todo dentro de un demonio va en contra del concepto Unix de hacer una cosa y hacerla bien". ^[10]

En su libro El arte de programar en Unix , publicado por primera vez en 2003, ^[11] Eric S. Raymond (defensor del código abierto y programador) resume la filosofía de Unix como el principio KISS de "Manténgalo simple, estúpido". ^[12] Proporciona una serie de reglas de diseño: ^[1]

• Construir programas modulares
• Escribe programas legibles
• Utilice la composición
• Mecanismos separados de la política
• Escribe programas sencillos
• Escribe pequeños programas
• Escribe programas transparentes
• Escribe programas robustos
• Complica los datos cuando es necesario, no el programa
• Aproveche los conocimientos esperados de los usuarios potenciales
• Evite salidas innecesarias
• Escriba programas que fallen de una manera que sea fácil de diagnosticar.
• Valore el tiempo del desarrollador sobre el tiempo de la máquina
• Escriba programas abstractos que generen código en lugar de escribir el código a mano.
• Prototipo de software antes de pulirlo
• Escribe programas flexibles y abiertos
• Hacer que el programa y los protocolos sean extensibles.

En 1994, Mike Gancarz, miembro del Grupo de Ingeniería Unix (UEG) de Digital Equipment Corporation , publicó The UNIX Philosophy basándose en su propio desarrollo de un puerto Unix ( Ultrix ) en DEC en la década de 1980 y en conversaciones con colegas. También es miembro del equipo de desarrollo del sistema X Window y autor de Ultrix Window Manager (uwm).

El libro se centra en la portabilidad de UNIX a diferentes computadoras durante las guerras Unix de la década de 1980 y describe su filosofía de que la portabilidad debería ser más importante que la eficiencia del uso de interfaces no estándar para hardware y dispositivos gráficos.

Los nueve "principios" básicos que él afirma que son importantes son:

1. Lo pequeño es hermoso.
2. Haga que cada programa haga una cosa bien.
3. Construya un prototipo lo antes posible.
4. Elija la portabilidad antes que la eficiencia.
5. Almacenar datos en archivos de texto planos .
6. Utilice las ventajas del software a su favor.
7. Utilice scripts de shell para aumentar el apalancamiento y la portabilidad.
8. Evite las interfaces de usuario cautivas.
9. Convierte cada programa en un filtro .

Esta sección no cita ninguna fuente . Por favor, ayude a mejorar esta sección añadiendo citas de fuentes fiables . El material sin fuentes puede ser cuestionado y eliminado . ( Febrero de 2024 ) ( Aprenda cómo y cuándo eliminar este mensaje )

Richard P. Gabriel sugiere que una ventaja clave de Unix era que encarnaba una filosofía de diseño que él denominó "lo peor es mejor", en la que la simplicidad tanto de la interfaz como de la implementación son más importantes que cualquier otro atributo del sistema, incluidas la corrección, la coherencia y la integridad. Gabriel sostiene que este estilo de diseño tiene ventajas evolutivas clave, aunque cuestiona la calidad de algunos resultados.

Por ejemplo, en los primeros tiempos, Unix utilizaba un núcleo monolítico (lo que significa que los procesos de usuario realizaban llamadas al sistema del núcleo, todas en la pila del usuario). Si se enviaba una señal a un proceso mientras estaba bloqueado en una E/S de largo plazo en el núcleo, el manejo de la situación no estaba claro. El manejador de la señal no podía ejecutarse cuando el proceso estaba en modo núcleo, con datos sensibles del núcleo en la pila.

En un artículo de 1981 titulado "La verdad sobre Unix: la interfaz de usuario es horrible " ^[13] publicado en Datamation , Don Norman criticó la filosofía de diseño de Unix por su falta de preocupación por la interfaz de usuario. Escribiendo desde su formación en ciencia cognitiva y desde la perspectiva de la filosofía entonces vigente de la ingeniería cognitiva , ^[14] se centró en cómo los usuarios finales comprenden y forman un modelo cognitivo personal de los sistemas (o, en el caso de Unix, no logran comprender, con el resultado de que es demasiado fácil cometer errores desastrosos (como perder una hora de trabajo).

En el podcast On the Metal, Jonathan Blow criticó la filosofía UNIX por considerarla obsoleta. ^[15] Sostuvo que unir herramientas modulares da como resultado programas muy ineficientes. Dice que la filosofía UNIX sufre problemas similares a los de los microservicios : sin una supervisión general, las grandes arquitecturas terminan siendo ineficaces e ineficientes.

• Ingeniería cognitiva
• Arquitectura Unix
• Minimalismo (informática)
• Ingeniería de software
• Principio KISS
• Ética del hacker
• Lista de filosofías de desarrollo de software
• Todo es un archivo
• Peor es mejor

• El entorno de programación Unix Archivado el 21 de octubre de 2011 en Wayback Machine por Brian Kernighan y Rob Pike , 1984
• Diseño de programas en el entorno UNIX : el artículo de Pike y Kernighan que precedió al libro.
• Notas sobre programación en C, Rob Pike, 21 de septiembre de 1989
• Un cuarto de siglo de Unix , Peter H. Salus, Addison-Wesley, 31 de mayo de 1994 ( ISBN 0-201-54777-5 ) 
• Filosofía Archivado el 12 de mayo de 2008 en Wayback Machine  — de The Art of Unix Programming, Eric S. Raymond, Addison-Wesley, 17 de septiembre de 2003 ( ISBN 0-13-142901-9 ) 
• Informe final del proyecto de diseño del núcleo Multics por MD Schroeder, DD Clark, JH Saltzer y DH Wells, 1977.
• La filosofía UNIX , Mike Gancarz, ISBN 1-55558-123-4 

• Fundamentos de la filosofía Unix – por Catb.org
• La filosofía Unix: una breve introducción – por The Linux Information Project (LINFO)
• Por qué la filosofía Unix sigue siendo importante