Por qué las base de datos relacionales van a desaparecer

Si, si, es una predicción medio loca y hasta pareciera absurda dado el estado actual de tecnologías, pero hay mucho indicios que me llevan a pensar lo que puse en el título.
En realidad, son todos indicios tecnológicos y no de negocios, pero como nuestra profesión se basa en la tecnología creo que en algún momento se hará fuerte una tecnología que desplazará a las base de datos relacionales de la misma manera que ellas desplazaron a los archivos jerárquicos (como vsam, etc).
Lo que me llevó a pensar esto nuevamente es un proyecto en el cual estoy haciendo coaching en el cual estamos usando Java como lenguaje de programación y Hibernate para conectarnos a una base de datos relacional. Hubo dos "colaboraciones" que me hicieron recordar lo antiguo de esta tecnología:

1) Cada vez que se quiere persistir un objeto, hay que hacer: session.save(anObject)
2) Cada vez que se quiere borrar un objeto, hay que hacer: session.delete(anObject)

¿Qué tiene de malo tener que hacer esto? Simplemente que en otras tecnologías no es necesario hacerlo! por lo tanto son más simples desde el punto de vista de utilización lo que implica que son menos propensas a error.
Para el caso 1), en una tecnología como la que usa GemStone, no es necesario decirle a un objeto que quiero que se persista, simplemente si ese objeto es referenciado desde un objeto persistido, este se persiste. Simple, natural, lógico.
El caso 2) es quizá el más fuerte puesto que me hizo acordar al manejo de memoria manual, ¿recuerdan c++, tener que hacer "delete anObject" para desalocarlo y todos los problemas que ello conllevaba? Acá estamos en el mismo caso, utilizar base de datos relacionales es como utilizar un manejo de memoria manual algo que por suerte ya está abandonado (salvo para casos muy particulares). ¿Por qué tenemos que borrar un objeto explícitamente cuando el mismo puede desaparecer automáticamente, como cuando se realiza un garbage collect?. Por suerte ya hay tecnologías que hacen esto (de vuelta GemStone) y "borran" objetos cuando los mismos no están más referenciados. Simple, natural, lógico.
Creo que estos dos casos son indicios que muestran que trabajar con base de datos relacionales en algún momento tiene que cambiar. En algún momento nos tenemos que dar cuenta que trabajar con ellas es trabajar en un paradigma "viejo", similar al procedural donde se separan "datos" de "código", en vez de utilizar un paradigma que ya está probado ser más robusto y escalable para desarrollo de aplicaciones como el de objetos.
Claro está que la base de datos relacionales tienen sus ventajas. Por ahí la más fuerte desde el punto de vista tecnológico es el SQL, pero al mismo tiempo para mi es su cruz, es lo que no va a permitir que la tecnología evolucione, cambie paradigmáticamente. Y por supuesto no hay que dejar de ver la fuerza comercial que ellas tienen, pero como dije antes, en algún momento la comunidad estará preparada para algo nuevo, distinto, cuando se cansen de tener que hacer save y delete y se den cuenta que si en memoria no hay que hacer eso, ¿por qué hay que hacerlo con el disco?, en definitiva el disco es "memoria" y debería estar abstraído (salvo cuando hay que hacer aplicaciones que deben diferenciarlos :-) ).
Claro está que a los dos problemas que mencioné hay que agregar varios más, como el problemático mapeo, manejo de identidad, manejo de caching y unicidad, etc., problemas que en otras tecnologías no existen...
Para concluir, ¿cuándo pasará esto? No creo que rápidamente... de la misma manera que a las base de datos relacionales les costó desplazar a los archivos planos y jerárquicos, no será inmediato reemplazar a estas. Por ahí en 10 años se empiece a divisar y entender que hay una alternativa a ellas, no creo que antes, a menos que aparezca un player nuevo en la comunidad, un player que sea respetado y tenga fuerza y logre imponer el quiebre paradigmático... por ahí ese player puede ser VMWare si se da cuenta del productozo que compró (GemStone), pero habrá que ver si sus "gurús" logran salirse del paradigma actual y ver más allá... el tiempo dirá.

¿A quién le creo?

Este comentario no tiene nada que ver con objetos ni sistemas, sino más bien con la realidad que nos está golpeando a los argentinos respecto de los medios de comunicación.
El viernes mientras caminaba hacia un cliente para dar un coaching de TDD me encontré con un kiosko que tenía a los diarios Clarín y Tiempo Argentino juntos, motivo por el cual pude observar una contradicción impresionante sobre la misma noticia en la primera plana de ambos diarios.
Clarín decía: "Papaleo declaró que estaba libre cuando vendió Papel Prensa". (ver http://www.clarin.com/ediciones-anteriores/edicion-impresa/20100827)
Tiempo Argentino decía: "Papaleo ratificó que entregó Papel Prensa bajo presión" (ver http://tiempo.elargentino.com/ediciones/2010-08-27/notas)
¿Quién dice la verdad? Clarín? Tiempo Argentino? Ninguno? o los dos? ¿Qué contradicción no?.
Sinceramente no me inclino por Clarín, ya se han visto tantas manipulaciones que realizó que seguro esta es otra más. ¿Qué ha acerca de Tiempo Argentino? Es oficialista y nos han hecho creer que generalmente ser oficialista está mal y que los políticos siempre mienten, ah, pero claro, los que nos han metido en la cabeza eso fueron los periodistas (y también bastante los políticos con su actuar realmente)... ¿entonces?...
Finalmente me quedo con lo que me recordó mi viejo hoy por la mañana: "En una guerra la primero que pierde es la verdad"... creo que este es un ejemplo claro.

Tributo a Alan Kay en su cumpleaños 70

La gente de ViewPoints ha publicado un libro (que se puede bajar on-line) como tributo a Alan Kay en el cual personas que trabajaron con él escribieron un capítulo cada uno. Hay varios capítulos interesantes como por supuesto el de Adele Goldberg, con un poco de historia también... Por ejemplo no sabía que el primer "cliente" comercial de Smalltalk fue la CIA!!! jaja, increíble... menos mal que no lo siguieron usando o por lo menos no sabemos si lo siguen usado... o por ahí el motivo por el cual Smalltalk no creció más fue por que la CIA no quizo!! claro! por fin lo entiendo :-) y bue, la teoría conspirativa siempre tiene que estar presente :-)

Working effectively...

with legacy code... Ese es el nombre de un libro que estuve hojeando (últimamente me cuesta mucho leer libros técnicos, me aburren!! lo cual no es un buen sintoma...) que está interesante, es recomendable pero que muestra nuevamente la cantidad de problemas que surgen en el mantenimiento de sistemas desarrollados con lenguajes estáticamente tipados.
Básicamente, el mayor problema es el acoplamiento que produce tipar las variables lo cual impede al momento de tener que escribir tests para código existente utilizar objetos que simplemente sean polimórficos con los objetos reales pero solamente para el conjunto de mensajes que se le envían y no para todo el protocolo declarado en el tipo!
Si, ok, están los mock objects y sus librerías para hacer su uso más fácil, pero igual sigue siendo más laburo del necesario o por lo menos del que llevaría en un lenguaje dinámicamente tipado como Smalltalk...
Por último, el libro muestra muchos errores de diseño típicos muy interesantes que haciendo TDD desde el comienzo no se cometerían que nuevamente tienen que ver con lograr diseños más desacoplados, algo que venimos comentando en nuestro curso de TDD desde que empezamos.

Para los que aman la historia de nuestra profesión...

como yo, salió una entrevista a Edgar Dijkstra realizada en el 2001 en la última Computer. La verdad, muy recomendable para conocer un poco más sobre el principio de nuestra profesión con comentarios sobre Algol-60, Peter Naur, Hoare, N. Wirth (y su relación con el paper de GOTO Considered Harmfull)... y como no podía faltar, la comparación USA/Europa que propició el comentario de Alan Kay en su Turing Award Lecture.
La entrevista completa está online para todos en: http://www.cbi.umn.edu/oh/display.phtml?id=320