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.
No hay comentarios.:
Publicar un comentario