10mo núcleo: MapReduce

La herramienta de MapReduce mencionada en el artículo de esta semana nos muestra un poco más de los detalles técnicos que conlleva programar en paralelo, como el manejo de memoria, medios de comunicación, programación distribuida y la reacción a fallos, todo esto a través de un modelo que toma sus bases de dos de las funciones más usadas de los lenguajes funcionales. Aquí me he podido dar cuenta de cómo algunas cosas que nos mencionan en la escuela, tal como utilizar la menor memoria y tiempo posible no aplican igual en la industria de la programación con gigantes como Google.

El autor menciona en múltiples ocasiones lo fácil y accesible que es trabajar con esta implementación, escondiendo todos los detalles que implica trabajar de manera paralela, reduciendo el código resultante de manera sustancial. Es interesante como pueden existir esta clase de herramientas desde inicios de la década pasada y que aun así la generación de buenos programas concurrentes no sea ya el estándar en la educación de software. Esto además que muchas personas usen herramientas de bajo nivel cuando no sea ni lo necesario y el usuario preferiría usar formas más fáciles.

Es un poco extraño leer como usan una gran cantidad de computadoras que además de dividirse los datos y/o tareas, también se reúsan al final como garantía de que ningún fallo físico o de red va a interrumpir el progreso del programa. Esto nos habla de cómo hay veces que tenemos que pensar en muchas otras cosas diversas y no sólo en el SW cuando queremos realizar un proyecto poderoso con gran alcance o que cumpla con una gran cantidad de requerimientos funcionales y no funcionales.

Creo que sería muy interesante trabajar en esta clase de proyectos, puesto que no sólo se están resolviendo problemas que son difíciles, sino que estaría ampliando y dando a conocer las ventajas que lleva la programación concurrente sin traer también todo lo malo.

9no núcleo: ¡¿Erlang no es Ericsson Languague?!

Al leer este artículo y ver la intención del autor de usar Erlang como un claro ejemplo de la Programación Orientada a Concurrencia, me doy cuenta de los varios beneficios que ofrece Erlang como herramienta educativa, especialmente en la parte de la abstracción de los hilos y procesos que pueden hacer de estas prácticas un tanto pesado. El uso de una máquina virtual propia que se encargue de manejar los hilos con el Sistema Operativo lo vuelve una herramienta poderosa que permite concentrarse en lo que realmente importa al momento de diseñar un programa. 

Su estructura de envío de mensajes y su paradigma funcional ciertamente le funcionan para lograr un paralelismo más seguro que otros lenguajes, sin embargo, esto también genera un distanciamiento de lo que un programador, sin importar si es joven o viejo, puede llegar a estar acostumbrado. Esto es entendible, pero puede generar que muchas personas no lleguen a probar todo lo que puede ofrecer el lenguaje y dejar la ilusión de que hasta los lenguajes diseñados para concurrencia y paralelismo son difíciles de entender. Parece compartir este trato Erlang con el lenguaje Clojure, aunque Clojure se apega más al extraño y bizarro mundo conocido como “hijos de Lisp”. Ambos lenguajes son fuertes en concurrencia, hacen uso de funciones como armas principales y descansan sobre una máquina virtual.

Viendo estos lenguajes, me pregunto si no existirá otra forma de lograr una concurrencia fácil y sin mucho trabajo además del uso de funciones. Creo que la memoria inmutable es algo esencial, así que van por buen camino; las funciones permiten el uso de copias, sin embargo, tal vez falta algún elemento para lograr que las deficiencias de Erlang parezcan una cosa arcaica y se pueda usar este paradigma en más ámbitos de la industria del software. Uno no puede saber de dónde vendrá este milagro. Quien sabe, tal vez hasta venga de PHP.

8vo núcleo: Rompiendo nuevas fronteras

Erlang me ha parecido un lenguaje extraño y familiar a la vez, tomando cosas de tantos lugares que parecería como un lenguaje tipo monstruo de Frankenstein. Para este punto de mi vida he visto unos cuantos paradigmas de programación y diferentes lenguajes que los implementan. Sin embargo, no me deja de sorprender este curioso lenguaje. Hasta su origen es poco común. No pensé que la telecomunicación en esa época llevara a las empresas al límite de generar lenguajes  con propósitos tan específicos. Demuestra de cierta manera que esta rama se alimenta de sí misma, generando nuevas áreas de especialización que continúan cambiando el conocimiento y herramientas básicas que afectan a muchas más personas que las que se pensaba originalmente. Tampoco esperaba que su dieño haya empezado de Prolog.

Además de esto, muchos de sus características como el runtime, su otp e interpreta lo posiciona y se define como algo que un lenguaje, sino como toda una plataforma o forma de programar y resolver problemas. Creo que incluso puede ser un buen lenguaje para aprender a programar de manera secuencial de la misma manera que Java es para objetos. Ambos, al menos de lo que se de Erlang, parecerían que tienes que hacer uso de esas herramientas para las cosas más mínimas. De esta manera, se refuerza el por qué y cómo de estas prácticas e ideologías.

También es curioso como parecería que el lenguaje está resurgiendo por cuestiones técnicas de hardware. Es decir, por el alza en el uso de procesadores multinúcleo. Aunque obviamente la implementación y alcance del lenguaje ha cambiado y mejorado con los años, es interesante ver que el paradigma de esa época siga vigente, demostrando que no necesariamente hay que ver lo de vanguardia para encontrar cosas buenas para la programación actual. Me hace preguntarme si algunas de las técnicas o tecnologías de antaño guardan más secretos para avanzar en el futuro de las ciencias computacionales y en la industria de la programación.