El que no conozca mucho de computadoras tendrá que tenerme un poco de paciencia, pero prometo que la idea es hablar sobre cosas que se relacionan mucho a la labor de aprendizaje y estudio de un instrumento. El que conozca mucho de computadoras también tendrá que tenerme paciencia porque en este asunto yo “toco de oreja”, como se suele decir (y mal) de alguien que no conoce completamente el tema del que está hablando.
No existe un sistema más usado hoy en día que UNIX y sus sucesores y copias, y es realmente sorprendente el enterarse que ese sistema fue desarrollado a fines de la década del 60, cuando hasta la palabra “computadora” era todavía extraña.
Para los que conocen poco de computadoras: el sistema UNIX es un caso realmente maravilloso dentro de la computación, y dentro de la historia de la computación. UNIX es un sistema operativo, es decir, es el software (programa) que hace que una computadora (o cualquier dispositivo electrónico, como una tableta, o un teléfono móvil) sea utilizable. No existe un sistema más usado hoy en día que UNIX y sus sucesores y copias (clones), y es realmente sorprendente el enterarse que ese sistema fue desarrollado en los laboratorios Bell, básicamente por dos personas: Ben Thompson y Dennis Ritchie, a fines de la década del 60, cuando hasta la palabra “computadora” era todavía extraña. Yo mismo tendría que esperar casi 20 años a nacer, y bastante más para que mis padres compraran una computadora, en 1991 (en aquel pueblo de Chivilcoy, provincia de Buenos Aires, se parecía a comprar un batimóvil, o un módulo lunar. Así de extraña era la computación todavía más de veinte años después del nacimiento de UNIX).
Desde el smartphone de nuestras casas hasta la estación espacial internacional, la inmensa mayoría de las computadoras utilizan algún sistema basado en UNIX
Dennis Ritchie y Ken Thompson
Con el tiempo, UNIX tuvo a BSD (basado en su código original) como sucesor, y a Linux como su copia (clon) más famosa. Todos los sistemas operativos de Apple (tanto para sus computadoras como para tabletas y móviles, los famosos iPad e iPhone) se basan en BSD, es decir UNIX. Mientras tanto, Linux (que no es un sistema operativo, sino que es la base –kernel– que permite construir uno), desde su adopción en el Proyecto GNU permitió una verdadera revolución en la informática, la del llamado “software libre” (free software, en inglés). En Linux se basan los sistemas operativos de software libre, como el Lubuntu instalado en esta misma laptop desde donde escribí esta nota. Además de su uso en computadoras de escritorio, Linux está instalado en casi todos los servidores de internet, es decir, la internet casi en su totalidad funciona gracias a sistemas Linux (y muchos otros servidores, además, utilizan BSD). Linux es la base de los sistemas Android (el sistema operativo de todos los otros dispositivos móviles a excepción de los de Apple), por lo cual, casi la totalidad de la población que usa algún tipo de dispositivo electrónico utiliza al menos un sistema basado en UNIX. Desde el smartphone de nuestras casas (en el que, probablemente, muchos estén leyendo esta publicación) hasta la estación espacial internacional (cuyas computadoras utilizan Debian GNU/Linux), la inmensa mayoría de las computadoras utilizan algún sistema basado en UNIX. Sólo las computadoras de escritorio usan los sistemas de Microsoft (Windows), lo que, paradójicamente, haga que la colosal importancia de UNIX haya quedado eclipsada a los ojos del gran público.
En este video (en inglés) de los años 70, se explican usos del sistema UNIX, como en la excelente explicación de Brian Kernighan sobre el pipelining (la posibilidad de conducir una serie de datos a través de varios programas, usando la salida de datos de uno como la entrada de datos del siguiente, de pipe, tubo en inglés). Traduzco al español y selecciono alguna parte de lo que explica (con verdadera capacidad didáctica) Kernighan: “Se puede pensar en los programas del sistema UNIX básicamente como ladrillos con los que se pueden construir cosas. Lo que distingue al sistema UNIX es el grado en que estos ladrillos se pueden pegar entre sí y en una gran variedad de formas, no solamente las más obvias. En muchos casos, hay maneras muy poco obvias de hacer un trabajo. […] Creo que la noción de pipelining es una contribución fundamental. En el sistema podés tomar dos o más programas y ‘pegarlos’ en los extremos, de modo que los datos fluyen de un programa al siguiente y el sistema en sí se ocupa de la conexión entre ellos”. En el video, Kernighan muestra un ejemplo en el que crea un programa que se ocupa de la revisión ortográfica de un texto. En realidad, no crea un programa, si no que lo hace “pegando” otros programas ya existentes en UNIX. El primero divide un texto en palabras, ubicando una por línea. Luego, toma la salida de ese programa y la envía a otro programa que convierte todas las letras en minúsculas para poder compararlas contra las entradas del diccionario. También para compararlas contra las entradas del diccionario, necesita ordenar esas líneas alfabéticamente, por lo cual, el resultado del segundo programa se envía a otro programa que se ocupar de ordenar las líneas. Lo siguiente es eliminar las palabras duplicadas, de lo que se ocupará otro programa. Finalmente, un último programa se encarga de comparar la salida del anterior con el archivo de un diccionario, y de mostrar las que no coinciden. El resultado es el de cinco programas distintos cooperando para realizar una tarea. Todo ello, sin necesidad de escribir un programa nuevo. Además de la simplicidad y la potencia del diseño que describe, lo que impresiona es que cada explicación que da es relevante aún al día de hoy. Pienso que es un logro muy poco habitual en la computación, en donde cada novedad dura a lo sumo una década antes de volverse obsoleta. UNIX es un sistema operativo, pero además es una filosofía, así como sus propios creadores decidieron llamarla. Que incluye varios preceptos que también siguen vigentes al día de hoy. Yo supongo que gran parte de las razones por las cuales se pudo crear un producto tan duradero tienen que encontrarse en esta filosofía, y en el hecho de que esa filosofía siempre estuvo por encima de cualquier acercamiento meramente utilitarista.
Este artículo se editó en una terminal en Lubuntu
En el prefacio del libro El entorno de programación UNIX de 1984, escrito por Rob Pike y el propio Kernighan, se lee: “Aunque el sistema UNIX introduce muchos programas y técnicas innovadoras, ninguno de estos hace que funcionen bien. En cambio, lo que es efectivo es la manera de acercarse a la programación, una filosofía de uso de las computadoras. Si bien esta filosofía no puede reducirse a una sola oración, se centra en la idea de que la capacidad de un sistema depende más de la relación entre los programas, más que de los programas en sí. Muchos de los programas de UNIX hacen cosas bastante básicas en sí mismos. Pero, combinados con otros programas, se convierten en herramientas útiles y de uso general”. En otro artículo del mismo año de los mismos autores: “Gran parte de la potencia de UNIX viene de un estilo de programación que hace a los programas fácil de usar y, más importante, fácil de combinar con otros programas. Este estilo ha sido llamado el uso de programas como herramienta, y depende de cómo los programas encajan en el entorno de programación y cómo pueden ser usados con otros programas, más que de como están diseñados internamente.” Toda la lectura de la filosofía UNIX (explicada en este artículo de Wikipedia) me encantó, no solo por su aplicación en la informática, sino porque creo que en el fondo describen un modo de construir cualquier técnica. –Primero, esa técnica tiene que surgir de conceptos más profundos y abstractos (una “filosofía”, como la llamaron ellos) que permitan luego ir construyendo los siguientes, de orden más práctico. Si no se construyen primero esos conceptos (en rigor, esos conceptos también los va construyendo la práctica, pero se tienen que ir reacomodando como principios cuando corresponda), se le deja el lugar de importancia a lo utilitario solamente, y se termina con un adefecio de elementos sin coherencia. –Segundo, la idea de la construcción de herramientas: cada recurso tiene que funcionar como una herramienta que tiene que hacer un solo trabajo, y hacerlo bien. Es muy difícil lograr una herramienta que haga varias cosas bien: un martillo no sirve como destornillador. Acaso el destornillador podría funcionar como martillo, pero al agregarle el peso necesario para martillar, ya hará que sea un poco más difícil el atornillar con él. La idea de resolver un solo problema a la vez siempre me ha gustado mucho; al intentar resolver problemas grandes, casi siempre encontramos la frustración. Cierta mirada que suele prevalecer en la actualidad es que hay que trabajar en ejercicios de velocidad o resistencia (como el clásico de estudio de escalas con metrónomo a velocidad creciente, que desaconsejo enfáticamente), pensando que así resolveremos una generalidad de problemas. En cambio, siempre intento separar un problema de la totalidad y trabajarlo lo más extensamente que me sea posible (una modalidad que, con muchísimo placer, descubrí que comparto ni más ni menos que con Diego Maradona). Esto permite encontrar un problema que sí se puede solucionar, lo cual es muy alentador. En muchas situaciones, esa solución, además, aparece bastante rápido y, lo que es más importante: una vez hallada una solución, generalmente el problema se resuelve para siempre. A diferencia del ejemplo citado de las escalas: un estudiante empieza a estudiar la escala con el metrónomo en 60 BPM y, luego de una media hora de práctica, llega a, pongamos, 200 BPM. Pero al día siguiente, si quisiera tocar a 200 BPM probablemente no lo lograría. Es decir, no encontró una solución definitiva. Y perdió media hora de trabajo. ¿Cómo se resuelven problemas complejos? Resolviendo muchos problemas más simples que los componen, igual que en el maravilloso ejemplo del corrector ortográfico de Kernighan. Por eso, las herramientas que fabricamos tiene que ser muy simples, pero tienen que poder funcionar en conjunto con las demás, lo que me lleva al úlitmo punto: –Tercero, las herramientas tienen que funcionar bien en conjunto. Algo que siempre critiqué de algunos maestros es que la solución para una problemática no guardaba ninguna coherencia con la solución a otra problemática. El esfuerzo mental y físico para salvaguardar esa falta de coherencia genera, a la larga, un techo en nuestras posibilidades, si bien muchos de esos “recursos” puedan solucionar cosas a corto plazo. Doy un ejemplo: escuché varias veces decir que para hacer un mordente ligado con la mano izquierda conviene utilizar el movimiento de rotación de la muñeca o el brazo. Evidentemente, el alumno principiante lo prueba y funciona. La poca habilidad de su mano no le permite hacerlo utilizando el peso de la mano y el movimiento (que puede ser incluso muy corto) del dedo que tiene que pulsar. Para arribar a la solución “correcta” (según mi modo de ver, por supuesto) primero necesita trabajar varios otros problemas de la mano izquierda. Pero, luego de trabajarlos, notará que es realmente mucho más sencillo hacer un mordente moviendo un dedo que todo el brazo. Además de ello, las herramientas que habrá generado también le servirán (combinadas de otra manera) para otras situaciones. Y, si solo se trabaja el movimiento rotatorio, habrá una multitud de casos en los que ese movimiento no es posible (por ejemplo, en un mordente dentro de un acorde), y ese recurso, esa herramienta, no tendrá ninguna otra utilidad, es decir, no podrá funcionar en combinación con ninguna otra. Ahí es donde aparece ese techo. Es decir, es mucho más eficiente descomponer el problema y trabajar en formular una herramienta para cada componente, en lugar de juntar todo en un solo componente, cuya solución solo sirve para ese caso puntual. Por eso es necesario que nuestras herramientas guarden una coherencia que les permita funcionar juntas. ¿De donde viene esa coherencia cuando la hay? De un pensamiento, de una “filosofía” preexistente.
Volviendo al ejemplo de las escalas: ¿cómo se llega a tocar las escalas más rápido? Sin dudas es un problema complejo, que depende de la resolución de una multitud de dificultades. Es necesario identificarlas una a una. Y, de a poco, construir una técnica, ladrillo sobre ladrillo, que nos permita ejecutarlas con soltura. El uso de esas herramientas se irá modificando con nuestro crecimiento. Algunas se irán descartando en favor de otras nuevas que hayamos descubierto o generado. Por eso, es necesario un enfoque modular en donde las mismas herramientas produzcan un resultado distinto según cómo se combinan con otras. Cuando una dificultad nueva aparece, no me parece aconsejable intentar “emparcharla”. Se la separa y se trabaja aparte, tratando de construir una herramienta que sea coherente con el resto de nuestra técnica.
Doug McIlroy, quien inventó el concepto de piping descrito hace unos párrafos, cuenta una anécdota que es en sí misma una loa a la simplicidad que solo puede lograrse a través de la consistencia, acerca de los programas que ofrecen varios parámetros de uso: “Solíamos sentarnos en la sala de Unix y comentar: ‘¿Qué podemos eliminar? ¿Por qué el programa tiene esta opción?’ Frecuentemente es porque hay un defecto en el diseño básico – no llegaste al punto justo en el diseño. En lugar de agregar una opción, piensa qué es lo que te está forzando a agregar esa opción”. Cierro con esta frase de McIlroy: “Esta es la filosofía Unix: crear programas que hacen una sola cosa y la hacen bien. Crear programas para que trabajen juntos”
Si te gustó la nota, dejame tu comentario, y si querés recibir un newsletter mensual con todas las novedades del blog y de mi página, suscribite.
Si desde Argentina, me querés invitar un cafecito (o los que quieras), aquí está el enlace:
¡Gracias por llegar hasta acá!
Deja un comentario