alt=|miniaturadeimagen|Ken Thompson y Dennis Ritchie, defensores clave de la filosofía de Unix La filosofía de Unix, originada por Ken Thompson, es un conjunto de normas culturales y enfoques filosóficos para el desarrollo de software minimalista y modular. Se basa en la experiencia de los principales desarrolladores del sistema operativo Unix. Los primeros desarrolladores de Unix fueron importantes para llevar los conceptos de modularidad y reutilización a la práctica de la ingeniería de programas informáticos, lo que dio lugar a un movimiento de "herramientas de software". Con el tiempo, los principales desarrolladores de Unix (y de los programas que se ejecutaban en él) establecieron un conjunto de normas culturales para el desarrollo de programas informáticos; estas normas llegaron a ser tan importantes e influyentes como la propia tecnología de Unix; esto se ha denominado "filosofía Unix".
La filosofía de Unix hace hincapié en la construcción de código simple, corto, claro, modular y extensible que pueda ser fácilmente mantenido y reutilizado por otros desarrolladores que no sean sus creadores. La filosofía de Unix favorece la componibilidad en oposición al diseño monolítico.
Origen La filosofía de Unix está documentada por Douglas McIlroy en el Bell System Technical Journal de 1978:
Haz que cada programa haga una cosa bien. Para hacer un nuevo trabajo, construye de nuevo en lugar de complicar los viejos programas añadiendo nuevas "características". Espere que la salida de cada programa se convierta en la entrada de otro programa aún desconocido. No llene la salida con información extraña. Evite los formatos de entrada binarios o en columnas. No insista en la entrada interactiva. Diseña y construye software, incluso sistemas operativos, para ser probados temprano, idealmente en semanas. No duden en tirar las partes torpes y reconstruirlas. Usar herramientas en lugar de ayuda no especializada para aligerar una tarea de programación, incluso si tienes que desviarte para construir las herramientas y esperas tirar algunas de ellas después de haberlas usado.
Fue resumido más tarde por Peter H. Salus en A Quarter-Century of Unix (1994):
Escribe programas que hagan una cosa y la hagan bien. Escribe programas para trabajar juntos. Escribe programas para manejar flujos de texto, porque esa es una interfaz universal.
En su premiado trabajo de Unix de 1974, Ritchie y Thompson citan las siguientes consideraciones de diseño:
Facilita la escritura, la prueba y la 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 de Unix se mantiene bajo Unix.
El Entorno de Programación del UNIX miniaturadeimagen|Rob Pike, coautor del Entorno de Programación del 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 y la filosofía de Unix:Kernighan, Brian W. Pike, Rob. The UNIX Programming Environment. 1984. viii
Los autores escriben además que su objetivo para este libro es "comunicar la filosofía de programación de UNIX".
Diseño de programas en el entorno UNIX miniaturadeimagen|Brian Kernighan ha escrito extensamente sobre la filosofía de Unix En octubre de 1984, Brian Kernighan y Rob Pike publicaron un artículo llamado Diseño de Programas en el Entorno UNIX. En este documento, critican la acumulación de opciones y características de los programas que se encuentran en algunos sistemas Unix más recientes como el 4.2BSD y el System V, y explican la filosofía Unix de las herramientas de software, cada una de las cuales realiza una función general:
Los autores contrastan las herramientas de Unix, como cat, con las suites de programas más grandes utilizadas por otros sistemas.
Doug McIlroy sobre la programación de Unix miniaturadeimagen|Doug McIlroy (izquierda) con Dennis Ritchie McIlroy, entonces jefe del Centro de Investigación de Ciencias de la Computación de Bell Labs, e inventor del Unix pipe, resumió la filosofía de Unix de la siguiente manera:
Más allá de estas declaraciones, también ha enfatizado la simplicidad y el minimalismo en la programación de Unix:
Por el contrario, McIlroy ha criticado el Linux moderno por tener un software inflado, remarcando que, "los admiradores adoradores han alimentado a Linux con golosinas a un estado descorazonador de obesidad". Él contrasta esto con el enfoque anterior tomado en los laboratorios Bell al desarrollar y revisar Research Unix:
Haz una cosa y hazla bien Como dijo McIlroy, y generalmente aceptado por toda la comunidad Unix, siempre se ha esperado que los programas Unix sigan el concepto de DOTADIW, o "Haz una cosa y hazla bien". Hay fuentes limitadas para el acrónimo DOTADIW en Internet, pero se discute ampliamente durante el desarrollo y 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 del sistema, afirmando que, "intentar controlar servicios, enchufes, dispositivos, montajes, etc., todo dentro de un demonio va en contra del concepto de Unix de hacer una cosa y hacerla bien"
Las 17 Reglas de Unix de Eric Raymond En su libro El arte de la programación Unix, publicado por primera vez en 2003, Eric S. Raymond, un programador americano y defensor del código abierto, resume la filosofía Unix como el principio KISS de "Keep it Simple, Stupid". Él proporciona una serie de reglas de diseño:
Construye programas modulares Escribe programas legibles Usa la composición de uso Mecanismos separados de la política Escribe programas simples Escribe pequeños programas Escribe programas transparentes Escribe programas robustos Complicar los datos cuando sea necesario, no el programa Aprovechar los conocimientos esperados de los usuarios potenciales Evitar la salida innecesaria Escribe programas que fallan de una manera que es fácil de diagnosticar Valorar el tiempo del desarrollador sobre el tiempo de la máquina Escribe programas abstractos que generen código en lugar de escribir código a mano Prototipo de software antes de pulirlo Escribe programas flexibles y abiertos Hacer el programa y los protocolos extensibles.
Mike Gancarz: La Filosofía de UNIX En 1994, Mike Gancarz (miembro del equipo que diseñó el Sistema X Window), se basó en su propia experiencia con Unix, así como en discusiones con otros programadores y personas de otros campos que dependían de Unix, para producir La Filosofía de UNIX que la resume en nueve preceptos primordiales:
Lo pequeño es hermoso. Haz que cada programa haga una cosa bien. Construya un prototipo lo antes posible. Elija la portabilidad en lugar de la eficiencia. Almacenar los datos en archivos de texto plano. Utiliza el aprovechamiento del software a tu favor. Usar scripts de shell para aumentar el apalancamiento y la portabilidad. Evite las interfaces de usuario cautivas. Haz de cada programa un filtro.
"Peor es mejor" 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, incluyendo la corrección, la consistencia 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 llevaban a cabo llamadas del sistema del núcleo en la pila de usuarios). Si se entregaba una señal a un proceso mientras estaba bloqueado en una I/O a largo plazo en el núcleo, ¿qué se debía hacer? ¿Debería retrasarse la señal, posiblemente durante mucho tiempo (tal vez indefinidamente) mientras se completa la I/O? El manejador de señales no podría ser ejecutado cuando el proceso estuviera en modo kernel, con datos sensibles del kernel en la pila. ¿Debería el núcleo hacer una copia de seguridad de la llamada al sistema, y almacenarla, para su reproducción y reinicio posterior, asumiendo que el manejador de señales se complete con éxito?
En estos casos, Ken Thompson y Dennis Ritchie favorecieron la simplicidad sobre la perfección. El sistema Unix ocasionalmente regresaba antes de tiempo de una llamada al sistema con un error que indicaba que no había hecho nada - la "Llamada al Sistema Interrumpido", o un error número 4 (EINTR) en los sistemas actuales. Por supuesto que la llamada había sido abortada para llamar al manejador de la señal. Esto sólo podía suceder para un puñado de llamadas de sistema de larga duración como read(), write(), open() y select(). En el lado positivo, esto hizo que el sistema de I/O fuera mucho más simple de diseñar y entender. La gran mayoría de los programas de usuario nunca se vieron afectados porque no manejaban o experimentaban otras señales aparte de SIGINT y morían inmediatamente si uno se levantaba. Para los otros pocos programas, como los shells o los editores de texto que responden a las teclas de control de trabajo, se podían añadir pequeños envoltorios a las llamadas del sistema para reintentar la llamada de inmediato si se producía este error EINTR. De esta manera, el problema se resolvió de una manera simple.
Crítica En un artículo de 1981 titulado "La verdad sobre Unix: La interfaz de usuario es horrible" 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 entonces actual filosofía de la ingeniería cognitiva, se centró en cómo los usuarios finales comprenden y forman un modelo cognitivo personal de sistemas - o, en el caso de Unix, no lo entienden, con el resultado de que los errores desastrosos (como perder una hora de trabajo) son demasiado fáciles.
Véase también
Ingeniería cognitiva Arquitectura de Unix Minimalismo (informática) Ingeniería de software Hacker ético Lista de filosofías de desarrollo del software Todo es un archivo
Notas
Referencias
The Unix Programming Environment by Brian Kernighan and Rob Pike, 1984 Program Design in the UNIX Environment – The paper by Pike and Kernighan that preceded the book. Notes on Programming in C, Rob Pike, September 21, 1989 A Quarter Century of Unix, Peter H. Salus, Addison-Wesley, May 31, 1994 () Philosophy — from The Art of Unix Programming, Eric S. Raymond, Addison-Wesley, September 17, 2003 () Final Report of the Multics Kernel Design Project by M. D. Schroeder, D. D. Clark, J. H. Saltzer, and D. H. Wells, 1977. The UNIX Philosophy, Mike Gancarz,
Enlaces externos
Basics of the Unix Philosophy – by Catb.org The Unix Philosophy: A Brief Introduction – by The Linux Information Project (LINFO) The Unix Philosophy Why the Unix Philosophy still matters
Categoría:Unix Categoría:Metodologías de desarrollo de software