El desastre del billón de dólares

Muchos consideran que la programación orientada a objetos es la joya de la corona informática, la solución definitiva para la organización del código, el fin de todos nuestros problemas, la única forma verdadera de escribir nuestros programas, otorgada a nosotros por el único dios verdadero de la programación misma. Hasta que ya no lo es. Así comienza un artículo escrito por Ilhasudan Nitscha en la publicación Better Programming de Medium bajo el título El desastre del billón de dólares. Y espera, no comiences aún a escribir ningún comentario porque en realidad el artículo tiene bastante trasfondo y quizás el título es una llamada de atención más que un dato real. Pero demos antes un poco de contexto: ¿de dónde viene la programación orientada a objetos? ¿Qué es? ¿Cuáles son sus beneficios? Y ¿por qué tantas críticas y desilusiones por el camino?

Antes de continuar, un inciso. ¿Te gustaría apoyar a nuestro canal? No olvides que puedes suscribirte y activar la campanita para no perderte futuro contenido. También se agradecen me gustas. Y además, si nos prefieres en formato podcast, podemos acompañarte desde Spotify. Ahora sí, continúa.

Alan Kay. Para empezar, tenemos que poner de relieve a una persona que ha sido fundamental para llegar al punto actual de la programación orientada a objetos: Alan Kay. La historia de Alan Kay está repleta de serendipias, una serie de casualidades enlazadas que le guiaron en su carrera comenzando por cuando era joven en 1961 y se alistó al ejército. Al principio Alan no tenía ni idea de computadoras, pero corría el rumor de que para poder entrar en la sección del ejército del aire donde había computadoras había una prueba de aptitud y nadie la había pasado en su base. Fue estímulo suficiente y tuvo la destreza y aptitudes necesarias para superarla. En ese momento fue enviado a Randolph Field en San Antonio, Texas y pasó una semana en la escuela de programación de IBM donde aprendería el lenguaje IBM Autocoder y RPG, de Report Program Generator o generador de programas de informes. Alan había estado estudiando biología en la universidad y matemática pura. Fue la carrera que continuó una vez se licenció del ejército. También trabajó como músico tocando en teatros y salas durante su último periodo universitario y para el NCAR, el National Center for Atmospheric Research. En Boulder, Colorado.

Una vez se graduó, estaba demasiado cansado y no quería un trabajo de verdad, así que decidió buscar una universidad que impartiera un máster en computación para relajarse un poco. Le gustaba el clima de Boulder, así que decidió buscar un sitio con una altitud similar que tuviese ese tipo de agrado, y encontró la Universidad de Utah, donde en esos momentos estaban en su punto álgido las investigaciones de ARPA.

Así, Alan se encontró a sí mismo en la comunidad ARPA, en los tiempos en los que se gestaba lo que más tarde todos conoceríamos como Internet. A esto, sumamos que Alan se encontró con Sketchpad, un lenguaje de programación con gráficos, y con Simula, el verdadero precursor de la programación orientada a objetos, tras lo que podemos entender cómo llegó a elaborar la idea que más tarde acuñaría con ese nombre.

La epifanía de los objetos.

Aunque inicialmente no tenía nombre, esta forma de programación tuvo dos motivaciones principales por las que surgió. Por una parte, a gran escala. Cuando los proyectos de software son muy grandes, esta consistía en encontrar un mejor esquema modular, una mejor organización del código para sistemas complejos y así reducir esta complejidad ocultando los detalles. Y por otra parte, a pequeña escala. Cuando el software a desarrollar no es tan grande, era encontrar una versión más flexible de la asignación cuando un valor debe ser asignado a una variable y luego tratar de eliminar la asignación por completo.

Pero comencemos con Sketchpad. Este sistema de comunicación gráfica hombre-máquina estaba definido en un documento que Dave Evans, el fundador del departamento de computación de la Universidad de Utah, daba a todos los que entraban a su oficina. Sketchpad inventó los gráficos interactivos por computador. El documento dejó perplejo a Alan y durante su estancia en el departamento En el departamento de computación tuvo que hacer frente a tareas bastante sucias, como arreglar errores en programas que otros ya habían intentado corregir.

En una de estas tareas se topó con un lenguaje llamado Simula, con una documentación horrible por una mala traducción del noruego al inglés. Habían empleado mal las palabras activity, de actividad, o process, de proceso, haciéndolas no coincidir con su definición en inglés.

Tras tomar una impresión en papel continuo del programa y colocarla en el suelo ocupando unos 24 metros en el pasillo, otro estudiante de posgrado junto con Alan iban leyendo y gritándose descubrimientos al mismo tiempo que hacían anotaciones. Lo primero que les llamó la atención es que este lenguaje, a diferencia del GOOL, que conocían mejor, no emplazaba en memoria elementos como si de una pila se tratase, sino más bien emplazaba estructuras de datos similares a las instancias de Sketchpad.

Ese gran éxito le impactó y cambió a partir de ese momento. Había visto esas mismas ideas en otras ocasiones las suficientes veces para reconocerlas y finalmente tener una epifanía.

Su especialidad matemática se había centrado en álgebras abstractas y sus pocas operaciones aplicables a muchas y diferentes estructuras. Su especialidad en biología se centró en el metabolismo celular y la morfogénesis a mayor escala. Con sus nociones de mecanismos simples que controlan procesos complejos y un tipo de bloque de construcción capaz de diferenciarse en todos los bloques de construcción necesarios.

Finalmente, todo lo aprendido con los computadores y en especial con Sketchpad, y finalmente con Simula, le sirvió para llegar al concepto ya que todos usaban la misma idea aunque para diferentes propósitos. Una frase de Bob Barton, principal diseñador del computador Burroughs B5000 y profesor en la Universidad de Utah, se le quedaría grabada a partir de ese momento: El principio básico del diseño recursivo es hacer que las partes tengan la misma potencia que su todo.

Por primera vez pensaba en todo ello como un todo, como una computadora al completo, y se preguntó: ¿Por qué alguien podría querer dividirlo todo en pequeñas y débiles estructuras de datos y procedimientos? ¿Por qué no dividirlo en pequeñas computadoras de tiempo compartido?

Smalltalk y la programación orientada a objetos.

Dicen que la necesidad incentiva la creatividad y los siguientes años, Alan los pasó trabajando en una computadora muy limitada llamada Flex. En principio, cualquier intento de emplear Simula quedó descartado porque la máquina no disponía de suficiente potencia para poder emplearlo. Evaluaron JOSS por su elegancia hacia el usuario final, pero era demasiado lento para computación seria. No tenía procedimientos reales, ámbito de variables, etc. Otro lenguaje que era similar a JOSS, pero con mucho más potencial, era EULER, de Niklaus Wirth, una generalización de ALGOL inicialmente, pero más parecido a Lisp en verdad.

EULER les sugirió que empleando las mismas técnicas a SIMULA podría ser simplificado. Tras hacer varias aproximaciones, crearon el lenguaje FLEX, para rendir tributo a la máquina que había propiciado su aparición.

Dave Evans no creía en las instituciones educativas y consideraba que dedicarse única y exclusivamente a ellas era un error E instaba a sus alumnos a buscar proyectos fuera de estas instituciones, por lo que Alan comenzó a trabajar en los años 70 para Xerox y refinó la idea de su computador KIDICOMP para crear el MINICOMP.

El lenguaje creado para el computador fue llamado Smalltalk.

El nombre iba en cierta forma contra la teoría indoeuropea de los dioses, donde los sistemas se llamaban Zeus, Odín, Thor y casi no hacían nada.

Si Smalltalk, que significa charla trivial, hacía algo, la gente quedaría gratamente sorprendida.

Pero el fundamento estuvo en que con Smalltalk se asentaban las bases de otros lenguajes como Flex, Planner, Logo o Meta II, que tenían muchos elementos de lo que Alan acuñara como la programación orientada a objetos. ¿En qué consiste la programación orientada a objetos? Bueno, creo que no nos daría tiempo en un solo programa de exponer en qué consiste, pero lo intentaremos a grandes rasgos. Extraído de los apuntes de Alan Kay, la programación orientada a objetos se basa en la encapsulación de unos datos y un comportamiento que definen la entidad. Esta entidad puede instanciarse siempre que sea necesario, pero lo más importante es la comunicación entre estas entidades que se realiza por intercambio de mensajes. Además, las entidades pueden heredar las estructuras de datos y el comportamiento de otras entidades extendiendo su conjunto de datos y su funcionalidad. Hasta aquí todo bien. La programación orientada a objetos se veía presente en Simula, Smalltalk y otros lenguajes de la época que comenzaron a influenciarse por los conceptos de la programación orientada a objetos. Pero algo pasó por el camino: la religión inflexible.

Las nuevas ideas pasan por diferentes etapas de aceptación, tanto desde dentro como desde fuera. Desde dentro, la secuencia pasa de apenas ver un patrón varias veces, luego notarlo pero sin terminar de percibir su significado, luego usarlo en varias áreas, luego el patrón se convierte en el centro de una nueva forma de pensar, Y finalmente se convierte en el mismo tipo de religión inflexible de la que se separó originalmente.

Desde fuera, como señaló Schopenhauer, la nueva idea es primero denunciada como obra de locos, en unos pocos años se considera obvia y mundana, y finalmente los denunciantes originales afirman haberla inventado. Bjarne Stroustrup, creador del lenguaje C++, dijo en una ocasión que C++ no es un lenguaje orientado a objetos, sino que C++ incorpora la programación orientada a objetos pero puedes emplear C++ sin necesidad de crear una sola clase. Esta diferenciación le confirió cierta licencia a la hora de implementar la orientación a objetos agregando los elementos que consideraban y de la forma en que mejor encajaban en el lenguaje.

Debido a la falta de seguridad y dificultad de C++, en Sun Microsystems, Java surgiría como un lenguaje orientado a objetos pero con la influencia de C++, que no era orientado a objetos. Este hecho le acarrearía el problema que Alan señalaría sobre las implementaciones de la programación orientada a objetos de los lenguajes basados en C++.

Alan lo sentía cuando acuñó el término objeto para el tema, porque esto da a la gente la idea de que el foco está en el objeto, y esta es la menor de las ideas. La gran idea de la programación orientada a objetos era la mensajería, los mensajes entre objetos.

La crítica. La programación orientada a objetos ha sido criticada por algunos ingenieros de software como un desastre de billones de dólares debido a su complejidad y excesiva dependencia de abstracciones y patrones de diseño como decíamos al inicio. Pero también hubo otras críticas con respecto a las implementaciones de la orientación a objetos en lenguajes como C++ o Java. Nuestro ya conocido en el canal Edsger Dijkstra dijo que los programas orientados a objetos eran una alternativa a los programas correctos.

Otro conocido personaje, Linus Torvalds, creador del núcleo Linux, dijo que el lenguaje C++ es horrible y limitar tu proyecto al lenguaje C hace que la gente no la cague con cualquier modelo idiota de objetos de mierda. Ya sabéis, el bueno de Linus.

Joe Armstrong, creador del lenguaje Erlang, señalaba que el problema de la orientación a objetos tal y como se practicaba es que cuando programas una banana, si quieres reutilizar este código, normalmente está tan al resto del programa que tendrás que tomar la banana con el mono que la sujeta y toda la jungla con ellos. La crítica de Joe viene del hecho de que la programación orientada a objetos proporciona a los desarrolladores demasiadas herramientas y opciones sin imponer los tipos correctos de limitaciones, y no cumple con sus promesas de modularidad y mejor reutilización.

El código orientado a objetos fomenta el uso de estado mutable compartido, que ha demostrado ser inseguro una y otra vez, y la encapsulación en ocasiones glorificada brilla por su ausencia. El código orientado a objetos típicamente requiere mucho código de plantilla, mucha burocracia, lo que puede provocar mucho ruido en la elaboración del código y que sea difícil de probar. Por su parte, Alan Kay no considera mala la idea de la programación orientada a objetos porque cree en los conceptos y en la implementación de esos primeros lenguajes más fieles a sus ideas, pero considera a lenguajes como Java lo más angustioso que le ha sucedido a la informática desde MS-DOS.

En una entrevista conjunta entre Joe Armstrong y Alan Kay, Alan confesó que tras ver los fundamentos en que se basa Erlang consideraba esa implementación más cercana a su idea de cómo debía ser la programación orientada a objetos.

Conclusiones.

Aunque el autor del ensayo inicial dijo que la orientación a objetos ha costado 1 billón de dólares, no deja de ser sino una cifra teórica y en verdad sin mucho fundamento. La crítica, como has podido escuchar, en su mayoría se basa en opiniones de personajes de renombre y en sus experiencias con esos lenguajes de programación.

Es cierto que la programación orientada a objetos implementada en lenguajes como C++, Java, PHP, Ruby o Python no se parecen a la idea original de Alan Kay sobre lo que debía ser la programación orientada a objetos donde cada elemento es un pequeño ordenador en sí que se comunica con el resto y mantiene su información. Sin embargo, y en verdad, esta visión se asemeja más a lo que conforma el Modelo Actor que a la programación orientada a objetos en sí.

En este tema siempre habrá amantes y detractores para la forma en que evolucionó la programación orientada a objetos tal y como la conocemos hoy en día. Así que ahora te toca a ti: ¿consideras que el autor del ensayo tiene razón y la orientación a objetos original es mejor y debería emplearse más?

¿Crees por el contrario que la gente se queja de los lenguajes que más se usan y por eso escuchamos de forma repetida siempre estas quejas?

Ve a nuestra sección de comunidad y deja tu voto sobre si prefieres programación espagueti, estructurada, funcional u orientada a objetos.

Todos.