CMU, POO y Programación Paralela

Desde hace un par de días se ha venido esparciendo cierto revuelo por la noticia de que Carnegie Mellon University, entre muchos otros cambios, eliminó de su currículo introductorio de ciencias de la computación la enseñanza de la programación orientada a objetos.

Desde entonces, han salido de todos lados los fatalistas de siempre que pregonan el fin del paradigma de programación orientada a objetos. Y por cierto que pocos detallan el hecho de que CMU ha incluido un curso completo (opcional eso si) de diseño orientado a objetos a partir del segundo año.

Este tipo de “píldoras” las he visto ya antes, de distintas formas, en distintos colores y de distintos sabores: Oracle compró Sun: “¡es el fin de Java!”, Tom de Marco dice algo como “I’m gradually coming to the conclusion that software engineering is an idea whose time has come and gone” y entonces se dice que “la ingeniería del software ha muerto”, y sin embargo seguimos hablando el lenguaje de la IS y haciendo desarrollo ágil, que aunque no le guste a muchos en el fondo no es más que IS. Algo similar también ocurrió (aunque no lo viví) en los 80s con los sistemas de gestión de bases de datos relacionales (SGBDR) cuando comenzó a cristalizar la idea de los sistemas de gestión de bases de datos orientados a objetos (SGBDOO).

Hay un gráfico que me encanta y que describe estas situaciones y otras similares de una forma increíblemente explícita, en español se le conoce como el “ciclo de sobreexpectación”:

hype_cycle

A lo largo de toda mi carrera he visto muchas tecnologías y “palabras sonantes” subir y bajar esa curva, de hecho creo que eso se ha visto desde que los términos “computación” y “tecnología” existen. Estoy seguro que voy a seguir viendo tecnologías y “palabras sonantes” subir y bajar esa curva durante el resto de mi vida. Por ahí pasaron, como ya dije, los SGBDR, los SGBDOO, los Servicios Web, SOA, AJAX, los sistemas expertos, algunos paradigmas de programación, muchos (pero muchos) lenguajes de programación, y muchas otras “Buzz Words” adicionales, entre otras cosas. Todas subieron al pico y luego descendieron hasta encontrar su adecuado lugar en la industria del software.

Ahora el asunto viene por el paralelismo, y por el hecho de que el paradigma orientado a objetos es “aparentemente” no “modularizable” y no “paralelizable”, aunque en verdad creo que de esto se podrían decir muchas cosas, basta con leer muchos de los comentarios realizados sobre el post al cual hago referencia al inicio de este pequeño artículo para ver a que me refiero.

En mi opinión el auge que está viviendo la computación paralela es magnífico y significativo, sobre todo en este momento en el que hay una explosión de hardware barato capaz de ejecutar en paralelo pequeñas “porciones de software” (por llamarlas de alguna forma).

¿Van a venir cambios asociados a esto? Estoy seguro de que si: es seguro que una gran cantidad de algoritmos y aplicaciones se beneficiarán de esta tecnología, no puedo dejar de pensar en las posibilidades de mejoras en áreas como la computación gráfica (donde de hecho nació CUDA), el ámbito multimedia (codificación / decodificación / procesamiento de video y otros usos afines), sistemas de gestión de bases de datos, procesamiento de imágenes, entre otros.

Sin embargo, no puedo dejar de pensar en que definitivamente no todas las aplicaciones ni todo el código que anda dando vueltas por ahí se puede paralelizar, al menos no en la forma en la que tecnologías como CUDA y su respectiva sobreexpectación tecnológica pretenden hacer ver, y que por el contrario sólo una pequeña porción (significativa eso si) de las operaciones y algoritmos que corremos en el software que usamos día a día se pueden beneficiar en verdad del paralelismo.

Es decir, esto es algo que va a subir por la curva del ciclo de sobreexpectación y va a volver a bajar hasta ocupar su adecuado lugar en la industria, tal cual todo lo demás.

Volviendo a la programación orientada a objetos, pienso que no hay buenos ni malos paradigmas, así como tampoco hay buenos o malos lenguajes de programación. Decir algo semejante sería como tratar de decir que un alicate es definitivamente mejor herramienta que un destornillador, y que por lo tanto, si tuviera que priorizar una cosa sobre la otra seguramente decidiría llevar dos alicates en mi caja de herramientas en lugar de un alicate y un destornillador. Creo en general que sólo hay buenos o malos programadores, buenos o malos diseñadores / arquitectos de software (guías como los llama Martin Fowler), buenos o malos gerentes o líderes de proyecto.

En general, hay paradigmas y lenguajes más aplicables a unos contextos que otros, así como hay herramientas más aplicables a una situación que otras, y si no, traten de atornillar algo con un martillo (y no es que no se pueda, sino que debe ser bastante difícil). Eso si, de algo estoy seguro, y esto nos guste o no es una realidad ineludible: pobre de aquel egresado de alguna carrera de informática o computación que no maneje hoy en día el paradigma de programación orientada a objetos y pretenda tener un trabajo promedio de desarrollador de software en la industria, y cuidado que en esta última frase la palabra “promedio” es clave.