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.

7mo núcleo: Alan turing y el juego de las mentiras

La verdad es que me ha gustado mucho la película del ‘Código Enigma’, todo el drama que presenta, así como el leitmotif de Turing visto como un incomprendido que puede ver el panorama general mientras los demás lo excluyen o molestan por su carácter, sexualidad o su intelecto. De veras genera emoción y tensión al momento en que el computólogo y matemático y el resto de su equipo descubren una nueva pista, intentan con un nuevo acercamiento o cuando le ocurre alguna tragedia a Turing, lo cual es bastante seguido durante la película. Dado mi carrera, ya había escuchado de Alan Turing varias veces en mi vida, aprendiendo algunos de sus datos personales y de sus logros. No sabía que había sido involucrado en la Segunda Guerra Mundial y que había sido responsable de descifrar los mensajes de los Nazis. 

Fue por eso que me puse a investigar más sobre su vida y su verdadera participación en estos eventos. Indagando un poco, descubrí que muchos sucesos que ocurren en el filme son exagerados para efectos de drama, mientras que otros igual o más interesantes  ni siquiera son mencionados. Un ejemplo muy claro, cómo lo menciona Anderson (2014) es el de su homosexualidad y sus acusaciones como espía. En realidad, Turing era muy abierto sobre sus preferencias sexuales, llegando incluso a confesar abiertamente cuando se la acusó en 1952. El doble agente que funge como uno de los criptólogos del equipo de Alan en realidad nunca lo conoció y mucho menos tenía idea de las relaciones que mantenía Turing. ‘Christopher’ la máquina que se acabaría convirtiendo en la madre de las computadoras ya había sido inventada por criptólogos polacos algunos años antes, Turing sólo mejoró su diseño e incorporó circuitos eléctricos a la misma. Sigue siendo un logro muy grande en la historia de nuestra área de estudio y creo que hubiera sido magnífico si lo hubieran mostrado como de verdad fue.

Referencias:

Anderson, L.V. (2014) How Accurate Is The Imitation Game? Slate. Recuperado el 28/02/2019 de: https://slate.com/culture/2014/12/the-imitation-game-fact-vs-fiction-how-true-the-new-movie-is-to-alan-turings-real-life-story.html

Grant, A. (2014) ‘The Imitation Game’ entertains at the expense of accuracy. ScienceNews. Recuperado el 28/02/2019 de: https://www.sciencenews.org/article/%E2%80%98-imitation-game%E2%80%99-entertains-expense-accuracy

6to núcleo: Paralelismo como futuro imperfecto

Los artículos anteriores a este punto se han dedicado principalmente a pronosticar cómo el paralelismo va a ser un factor constante al momento de diseñar y desarrollar software, mencionando el alza de las computadoras multinúcleo y de demás aparatos que usan más de un procesador. Un claro ejemplo de esto es la lectura de “Welcome to the Jungle” de Herb Sutter (2011), mencionando los diferentes tipos de paralelismo y manejo de memoria que nosotros como desarrolladores tendremos que trabajar, declarando: “…a single compute-intensive application will need to harness different kinds of cores, in immense numbers, to get its job done”.

Es curioso ver como todos estos análisis se comparan contra la realidad que ofrece el texto de UBM TechWeb. Pareciera que las profecías se cumplieron y ahora todo puede ser hecho de manera, al menos, concurrente. Sin embargo, el mundo de la industria del software y sus habitantes no parecen estar preparados, buscando incluso a ciegas como paralelizar código y aprovechar la enorme ventaja que representa esta clase de arquitecturas. Lo más interesante es como los productores de chips como Intel o AMD aprovecharon o más bien fueron forzados a aprovechar la arquitectura multinúcleo para seguir siendo vigentes en el mercado. Sin embargo, los creadores de IDEs y de demás herramientas en el mercado parecen estar atrasados y no seguir esta tendencia. Esta diferencia en las acciones de mercado muestra la falta de conocimiento sobre que necesitamos como programadores para poder trabajar de manera eficiente bajo estas condiciones.

Algo que menciona el artículo y que concuerdo con ello, es la importancia de tener herramientas para hacer un correcto análisis de memoria y de errores dentro del código paralelo. Los métodos de depuración como revisiones a mano de código o uso de prints se vuelven obsoletos. Creo que si queremos integrar estas técnicas de programación a nuestro desarrollo diario, es necesario que nuestros hábitos y herramientas cambien acordemente.

Referencias:

Sutter, H. (2011) Welcome to the Jungle Or, a Heterogeneous Supercomputer in Every Pocket. Sutter’s Mill. Recuperado el 21 de febrero de 2019 de: https://herbsutter.com/welcome-to-the-jungle/