Ruby.NET

A través de The server side (.NET) me entero de que hay un grupo en una universidad Australiana que está dispuesto a crear un compilador que convierta codigo Ruby a .NET CLR: Ruby.NET, incluyendo todas la posibilidades dinámicas de ruby, como closures, continuaciones, posibilidad de añadir métodos dinámicamente... Según comentan en la página del proyecto su idea es implementar el lenguaje y alguna parte de la librería estándar que sea 100% Ruby. El resto lo dejan en manos del interés de la comunidad.

Me ha parecido un proyecto francamente curioso, habrá que ver que sale de ahí.

La misma entrada en BP

Actualización: Esto ha sido publicado en la portada de barrapunto, así que podéis ir alli si queréis más información y más ruido: Ruby en .NET

¿Librerías o Frameworks?

Una entrada breve pero intensa Guido van Rossum (Library or Framework?) ha sacado a relucir el tema de Librerías contra Frameworks. Citraduzco :)

Un framework es solo una aplicación con hooks; puedes diseñar un framework ad hoc empezando con una aplicación que hace una sola cosa e intentando generalizarla en varias direcciones. Puedes parar en cualquier momento y llamarlo "un framework". Pero una buena librería requiere mucho más. Necesitas empezar por los requerimientos, abstracciones y el intento hacer una API mínima que cumpla al máximo con los requerimientos. Los frameworks no tienen el requerimiento de ser mínimos en tamaño sino máximos en cuanto a características.

Díría que es un poco provocador y radical, pero se acerca a la realidad. Últimamente se ha visto un crecimiento en las críticas a los frameworks, como respuesta, supongo, a su proliferación y aumento de popularidad. Una lista de críticas:

• Why I Hate Frameworks, discusión en los foros de joel on software
• Contra los fameworks, que cita al anterior
• Why Frameworks Suck

Buscando un poquito seguro que se pueden encontar más, pero creo que es suficiente...

La misma entrada en BP

Lecturas aleatorias

Como se que esto se publica en planeta código voy a hacer una advertencia. Lo que sigue es publicidad de un nuevo blog personal, así que si no te interesa puedes seguir leyendo las entradas de otros que son más ontopic...

El caso es que me he decidido a crear un blog en el que deje registro de los libros que leo y he pensado que quizás haya alguien al que le interese. Se llama Lecturas aleatorias y como su nombre indica no tiene un género definido. Si alguien se quiere hacer una idea, buscando en mi bitácora de BP se puede ver el tipo de intereses que puedo tener (formato rss, cortesía de slascode :()

Fin de la publicidad :)

Accesores, diseño orientado a objetos y la ley de Demeter

Acabo de leer una muy interesante entrada en el bliki de Martin Fowler (GetterEradicator) acerca de un tema muy controvertido: los accesores en programación orientada a objetos. La encapsulación, la ocultación de información, el diseño orientado al cambio, todo esto influye en la decisión de no usar get y set para todos los datos de una clase.

Tiene enlaces muy sabrosos a artículos que han ido hablando del tema, pero me gustaría destacar uno, Tell, Don't Ask en el que se habla de la "Ley de Deméter": Habla sólo con tus amigos inmediatos. Traduciendo el enunciado formal

Un método M de un objeto O solo debería invocar métodos:

• suyos
• de sus parámetros
• objetos que cree o instancie
• objetos miembros de la clase (atributos)

Así se consigue que la dependencia de la estructura entre las clases no vaya arrastrando más de un nivel. Eso si, provoca algún nivel de indirección más. Y como sabemos (Actualización:Ya decía yo que la cita la había leído hace poco... y era en Esos aparatos del demonio)

No hay ningún problema de computación que no se pueda solucionar con un nivel más de indirección (salvo si el problema es que existen demasiados niveles de indirección...)

Y claro, siempre teniendo en cuenta que toda ley o directriz de diseño debería ser eso una directriz. Siempre hay excepciones a estas reglas. El arte es saber cuando saltárselas :)

La misma entrada en BP

ACE y C++ como alternativa

A raíz de una noticia enviada a menéame, ACE contra JAVA y .NET, y que no ha pasado a portada me ha parecido necesario hacer apología de ACE. Se trata de un framework altamente portable y basado en patrones de diseño con el cual se pueden hacer aplicaciones con un uso muy facilitado de funcionalides del sistema, por ejemplo, sockets y threads, más compacto que las versiones nativas de C y por supuesto portable a un número realmente grande de plataformas.

Como todo lo bueno tiene desventajas, claro. La primera es que ocupa mucho como librería. La segunda es que no tiene GUI propio, aunque se puede usar wxWidgets, Qt, GTK+...

¿Por que no es tan conocido como otras soluciones? Mi explicación es sencilla :) No hay detrás una gran empresa con marketing, ni siquiera una fundación (creo) Su página web es fea y sin diseño y usan un lenguaje como C++ que no es lo que se lleva, aunque los apóstoles del lenguaje se empeñan, con algún éxito, de que se deje de ver a C++ como C con objetos para verlo como multiparadigma. Pero en mi opinión, y bueno, no solo en la mía, ACE da una flexibilidad y portabilidad difícilmente conseguible con otros lenguajes, frameworks o librerías

Por último nombrar alternativas en plain old C, que no he usado pero que por venir de donde vienen no deben estar mal. Serían Apache Portable Runtime y Netscape Portable Runtime usado y mantenido por Mozilla.

La misma entrada en BP

Objetos y bases de datos relacionales

Este tema da para mucho (seguro que para muchos libros y/o ríos de bytes) pero bueno, trataré de ser breve. Me he encontrado una noticia en The Server Side sobre Amber, un mapeador de objetos en bases de datos relacionales que, al contrario de el resto de estos sistemas, se centra más en las características de la base de datos, con lo que permite olvidarse de las configuraciones en XML y además dejar del lado de la base de datos, mediante procedimientos almacenados, la configuración de dicho mapeo. (Más información en Lightweight R/O Mapping y Java and the Empowered Database)

Como el tema me parece muy relevante (¿quién no programa hoy en día en un lenguaje que no soporte OO? ¿quién no usa bases de datos relacionales?) y sin embargo creo el tema no es un tema demasiado "popular" voy a tratar aportar lo que tengo a mano para aumentar la popularidad y con suerte algún lector será capaz de aportar algo más.

En la wikipedia hay una entrada acerca del mapeo O/R, que apunta a lo que me parecen dos artículos extensos y muy muy jugosos: Mapping Objects to Relational Databases: O/R Mapping In Detail y uno un poco más breve: The Object-Relational Impedance Mismatch, ambos de Scott W. Ambler. En este último se pone de relevancia algo que sospecha todo aquel que piensa detenidamente en ambos paradigmas, OO y relacional, y es que no son directamente "enchufables" y por ello se genera lo que llama impedance mismatch ("desajuste de impedancia", al parecer una analogía con la electrónica) De este desajuste se deduce que tenemos que pensar detenidamente en los mecanismos y herramientas de mapeo, no vaya a ser que nos encontremos con sutilezas desagradables en un punto más avanzado del desarrollo...

La misma entrada en BP

La ley de Dollo y los sistemas informáticos

Estaba yo leyendo un libro de ensayitos relacionados con la ciencia, "El filantrópico doctor Gullotin y otros ensayos sobre la ciencia y la vida" de Harold J. Morowitz cuando me he encontrado con una ley de la evolución que no conocía y con su aplicación a la evolución de programas y sistemas. Se trata de la ley de Dollo y el enunciado según el libro sería

"La evidencia indica que los principales pasos evolutivos, una vez dados, nunca se desandan"

Como casi todas las leyes de la evolución tiene excepciones que pueden ser las que confirman la regla. Además en el propio ensayo se hace una mención a su validez en evolución de sistemas informáticos:

"La longitud de los programas(*) y sus peculiaridades crean estructuras que no pueden revertirse sin que el programa(*) quede destruido y haya que empezar de cero"

(*)Creo que decir "programas y sistemas" en lugar de "programas" da una mejor visión de como funcionan estos mecanismos en la realidad...

Y claro, leyéndolo se me hay ocurrido ejemplos de su aplicación en la tecnología. El triunfo de sistemas edificados sobre el triunfo de otros sistemas: C++ encima de C, servicios web y AJAX sobre HTTP...

Es curioso como esto tembién se puede extrapolar (con menor potencia) a sistemas más pequeños, a los sistemas que vamos contruyendo cada día. En general unos se edifican sobre los anteriores, los nuevos sobre los que se usan. Yo lo resumiría en una frase: "serás esclavo de tus éxitos" (y tendrás que mantenerlos) :)

La misma entrada en BP

Cierra Tío Petros

Leo a través de pjorge que Tío Petros, un fantástico blog sobre matemáticas, cierra sus puertas. Alguna vez le he referenciado en mi bitácora de BP (en Ordenadores, paradojas y fundamentos de las matemáticas) y además me impulso a leer un muy buen libro "El tío Petros y la conjetura de Goldbach"

Se le va a echar de menos :(

"Un vistazo a C++0x" por Bjarne Stroustrup

Bjarne Stroustrup ha publicado un articulito para explicar como va a ser la siguiente versión de C++ (C++0x, porque no se sabe en que año saldrá, quizás en el 09) Se titula "A Brief Look at C++0x" y explica los principios de diseño que lo van a guiar y las características nuevas que va a tener tanto el lenguaje como la librería estándar (la mayor parte ya están disponibles con boost).
A mi me gusta particularmente lo de poder inicializar contenedores con una lista y el uso de auto para que el compilador deduzca el tipo.
Según el artículo C++0x tendría esta pinta:

template<class T> using Vec = vector<T,My_alloc<T>>;
Vec<double> v = { 2.3, 1.2, 6.7, 4.5  };
sort(v);
for(auto p = v.begin(); p!=v.end(); ++p)
    cout << *p << endl;

Para más iformación, por ejemplo "C++0X: The New Face of Standard C++" de Danny Kalev

Actualización: Más información: en la portada de BP Un vistazo a C++0x, por Bjarne Stroustrup, Slashdot y OSNews

La misma entrada en BP

Diseño de APIs (II)

En un weblog de Artima, Eamonn McManus ha publicado una interesante entrada sobre el diseño de APIs en Java mucho más completa que la de Martin Fowler (que referencié en su día) Para él una buena API debería ser correcta, fácil de usar, fácil de aprender, rápida y pequeña. Y el mejor consejo: sé minimalista. Muchas de las pautas aconsejadas son exportables a otros lenguajes OO.

La misma entrada en BP