"La revelación de nuestra condición es, asimismo creación de nostros mismos. Según se ha visto, esa revelación puede darse de muchas formas e incluso no recibir formulación verbal alguna. Pero aun entonces implica una creación de aquello mismo que revela: el hombre. Nuestra condición original es, por esencia, algo que siempre esta haciéndose a sí mismo"
Así comienza Octavio Paz el capítulo "Inspiración", en su libro el "Arco y La Lira", y acudo
precisamente a el, en busca del impulso necesario para saltar el abismo, para salir de la comodidad del túnel y ver si más allá de la luz de salida que me ofrece la pantalla en blanco, puedo reencontrarme con el afán creador y así dar vida a mi primer artículo para la Naturaleza del Software. Como punto de partida nada mejor que el propio título de este blog, "La Naturaleza del Software" y ver si las revelaciones de nuestra condición, no son sino creaciones nuestras. "La programación es un arte" plantea Donald Knuth, frase agradable a nuestro ego y que nos permite soñar con ser artistas, tomar la investidura del creador y volver a repetir la historia de Prometeo, Brian Kernighan rápidamente sentencia nuestra vuelta a tierra con su cita "Controlar la complejidad es la esencia del
software", ¿Somos eso, los controladores de la complejidad? Más aún tipos como Ken Thompson, nos recuerdan lo primitivo que puede llegar a ser el hacer del software, "En caso de duda, aplica fuerza bruta". Estas contradicciones aparentes, son las fuerzas que lucha por algo que siempre se esta haciendo así mismo, el software como creación del hombre y en definitiva el hombre mismo por medio del uso de la técnología.
El ver la programación como una creación, de manera inconsciente nos lleva al enfoque "creacionista" con respecto a la naturaleza del software, en un principio el caos, luego seis días de arduo trabajo y trasnoches, y al final del proyecto, obtenemos ese orden maravilloso denominado universo junto al merecido premio del descanso al séptimo día. Si el universo no resultó tan ordenado, culpar al creador es de poco respeto, mal que mal, antes solo estaba el caos. ¿Y después del séptimo día?. Bueno hacemos "Mantención de Software". Controlamos la complejidad, sin fuerza bruta, pero cada día más brutos. Instalamos la idea de que existe un orden permanente. El hombre de Neanderthal, de seguro pensaba igual.
A diferencia del artesano, que utiliza sus instrumentos y materiales para servirse, el artista busca trascender más allá del lenguaje que utiliza, es alguien que se pone al servicio del lenguaje o medio de expresión y busca que este recupere su naturaleza original y lo trascienda. Es en ese contexto donde la programación es un arte, porque la naturaleza del software, es la naturaleza del hombre que transforma su medio y trasciende en sus posibilidades. Este es el sentido que le doy a la cita de Donald Knuth y en ello va la naturaleza del software.
Solo agregaría que los verdaderos programadores no modelan la realidad, solo modelan las abstracciones ligadas a sus propias observaciones ...
La Orientación a Objetos es la peor tragedia del programador, ese que se autoengaña con distinciones que le hacen creer que su mapa es el territorio. Si las distinciones que establece son inadecuadas el software, que se genera a si mismo en cada momento, en un instante se hará insotenible y muere: ¡¡horror, es mejor partir de cero nuevamente!!!.
Solo un programador que entiende que modela su propia entelequia, descubrirá que detrás de las formas que devela, solo hay formas develadas y que por tanto las nuevas formas develadas necesariamente estarán contenidas en las formas anteriores.
IMHO el Eidox acuñado por ciempíricos chilenos a principios de este siglo, del griego Eidos: forma o idea, X: XML = formas en XML, es la única forma inmortal: se limita a registrar las observaciones de cualquier de observador sin pretender que estas formas representan la realidad: solo representan el registro de la reflexión de un observador de observadores, el programador, buen o mal observador como cualquier otro ;-).
Lo que pasa que la OOP tradicional hace mapas estáticos de las entidades que analiza.
Los modelos dinámicos (en UML o en modelamiento de procesos) asumen una estructura estatica del modelo, son orquestaciones y coreografias sobre actores que se asumen se quedan quietos.
La idea de Pepe es que los objetos/entidades tambien deben modelarse asumiendo que cambiarán, que sólo hemos modelado una visión inicial.
Las clases y su mapeo a tablas son rígidas.
En eso estoy de acuerdo con Pepe, la OOP y el modelo relacional son los grandes causantes de la complejidad del software.
Donde no estoy convencido es si el EIDOX es la solución (puede que el problema sea la implementación).
La definición que más me gusta de "software" es "comprensión congelada/solidificada de los actuares sobre un problema" (mejor en inglés, "frozen understanding of the actions upon a problem"). La comprensión es siempre relativa al programador/diseñador/ingeniero. Casi siempre es posible una mejor comprensión de un problema. Los problemas complejos nunca tienen una única solución (a veces ninguna).
No me parece que OO sea "la peor tragedia". Es un lente, una herramienta. Te puede hacer ciego a algunas cosas, pero es el precio que pagas por poder observar más lejos, más rápido o más cosas (o la misma cantidad de cosas por menos plata). Como todas las herramientas, tiene una curva de aprendizaje peculiar, y si no sabes cómo ocuparla hará tu trabajo más difícil que sin ella. Pero no por eso deberíamos desecharla definitivamente para buscar otras herramientas.
Supongo que con los años me he vuelto más mañoso con las definiciones de libro, pero no me gusta pensar en el software como un arte (imitación de la naturaleza, búsqueda de la belleza, etc., y por tanto fuertemente vinculada al sentido estético). Sí es una artesanía ("craft"). Se aprende en el taller transmitida de maestro a discípulo. Es un actuar esencialmente práctico. Es como andar en bicicleta: la sola idea de tener una clase teórica sobre aprender a andar en bicicleta suena absurda. Mejoras con la práctica y mirando hacer a otros.
¿Controlar la complejidad...? Para mí, más bien "comprender suficientemente la complejidad".
Efectivamente la OO no es la peor tragedia del software, porque en en el fondo el problema de las abstracciones es parte de nuestro proceso de conocimiento, es un problema humano.
Por eso lo del Pepe y lo del Edo, me parece un poco exagerado. A modo de ejemplo los modelos de bases de datos relacionales tienen el mismo problema. Incluso los modelos de procesos de negocio son visiones estáticas de comportamientos o de la dinámica de las interacciones.
Lo que pide Pepe es que uno sea conciente de ello, el para qué de esta conciencia me parece que es un tema de discusión, porque no queda claro ese para qué y su utilidad.
Ahora Tama plantea que el arte es un vínculo al sentido de lo estético, el arte trasciende, va más allá y una de las dimensiones es lo estético. Pero lo estético no es la esencia del arte.
De hecho el artículo pretende ir en la línea que la naturaleza del software es un arte en el sentido de trascender en las posibilidades del hombre: Conciencia, Medios, Posibilidades, Desarrollo, Capacidades, etc.
y el artículo va en la línea de darle otro sentido a la programación como arte, de sacar la visión del creador y ponerse en la posición de trascender.
En ese trascender me parece que si es clave lo que señala el pepe, las abstracciones válidas hoy, no lo serán mañana, o las que en definitiva creo que son la realidad presente, ni siquiera lo son.
Lo de controlar la complejidad coincido en que se debe comprender, pero esa comprensión es controlada en el sentido que para comprenderla creamos abstracciones. En definitiva acotamos la realidad, le quitamos complejidad. Pero coincido en que el controlar puede ser visto como una comprensión.
Hay que recordar que la matemática es el lenguaje mas estático que existe, de tal manera que cuando quieres expresar dinamismo aparecen las peligrosas ecuaciones diferenciales, que tratan de significar en una única abstracción la totalidad de posibilidades de un sistema.
Sin embargo, para construir modelos no está mal, es breve y compacta, y si se aplica una solucion de versiones en instantes de tiempo discreto, puede parecer que hasta se mueve...