lunes, diciembre 18, 2006

Memoria transaccional y concurrencia

En ACM Queue han publicado un articulo que ilustra bastante bien por donde irán los tiros (seguramente) en esto de la programación concurrente. Se trata de Unlocking Concurrency: Multicore programming with transactional memory y describe un poco que es la memoria transaccional y como se programaría en un lenguaje de los de uso cotidiano.

Básicamente se trata de especificar en el lenguaje que secuencias de operaciones forman una transacción de memoria, en la cual, como su nombre indica, o bien se realiza la operación completamente o bien es como si no se hubiese operado con ella, evitando la sincronización manual por parte del programador. Como se encargan de subrayar en el artículo tampoco es la panacea, pero ayuda(ría) mucho a la gestión de la concurrencia.

Sólo falta ahora que se implemente en lenguajes de uso común y deje de ser sólo objeto de investigación académica...


La misma entrada en BP

jueves, diciembre 14, 2006

Una herramienta, no una religión

Entrada interesante en Adding Simplicity - An Engineering Mantra, It's a Tool, Not a Religion!. Traduciendo muy libremente:

Recientemente he estado asistiendo al debate de REST contra SOA. La última semana me vi envuelto en discusiones de C++ contra Java. Esta noche pasada me tropecé con algunos debates sobre Django contra Rails. Me parece que los ingenieros de software somos únicos en el mundo técnico: más que disfrutar con una caja de herramientas variada, discutimos contra su contenido, esperando descartar todas excepto el conjunto más pequeño posible.

[...]

¿Porque debemos trabajar tanto en reducir nuestro conjunto de herramientas hasta la herramienta definitiva? Hay una tendencia a buscar el lenguaje Navaja suiza apoyado por un framework que será la solución óptima para todos los problemas del mundo. La simple realidad es que ese lenguaje o framework no existe. ¿Por qué? Bueno, la solución de problemas informáticos es siempre acerca de adoptar compromisos que optimicen la solución en determinadas condiciones. Si tu problema cumple esas condiciones, perfecto. Si no, estarás usando una herramienta subóptima.

[...]

Es importante tener opciones para resolver los problemas de cada día. Entender las herramientas y su aplicabilidad a un problema dado debería ser nuestro trabajo

En resumen, en lugar de criticar herramientas, aprende su ámbito de aplicación...

La misma entrada en BP

domingo, diciembre 03, 2006

sky2 y sk98lin en Ubuntu

Nota: Esta entrada es obsoleta, porque desde la versión 2.6.17 el driver sky2 funciona correctamente y sk98lin ha dejado de mantenerse. O sea, que hay volver a configurar sky2 y hay que eliminar del fichero /etc/modprobe.d/blacklist la línea blacklist sky2 (si existe)

Referencias:
sk98lin en la wiki de gentoo en la que se explica un poco la historia
Una explicación de la situación el la lista del kernel


Entrada original:

Tenía problemas con el driver de la tarjeta de red, una Marvell Yukon, desde la actualización a Dapper y no lo sabía, porque no la usaba últimamente. Si se hace un uso intensivo de la red (léase P2P ;) ) sky2, que es el driver que ubuntu coge por defecto, se quedaba atascado. El caso es que he buscado (quizás no mucho) y no he encontrado, como suele ser usual, la receta sencilla. Lo que me ha servido a mi es:

  1. Instalar las cabeceras del kernel (en mi caso y salvo casos excepcionales linux-headers-generic)
  2. sudo apt-get install build-essential (si no lo tenemos)
  3. Bajar el driver de http://www.marvell.com/drivers/driverSearchResults.do y descomprimirlo
  4. Sustiuir #!/bin/sh por #!/bin/bash en el fichero install.sh
  5. En el directorio descomprimido: sudo ./install.sh y damos a 1. Installation
  6. sudo modprobe sk98lin
  7. añadir la línea blacklist sky2 al final del fichero /etc/modprobe.d/blacklist (edítalo como root o con sudo)
Espero que le sea útil a alguien...
(Basada en dos recetas, para mi, incompletas: http://www.ubuntu-es.org/index.php?q=node/30706 y http://ubuntuforums.org/showthread.php?t=176096 )

La misma entrada en BP

jueves, noviembre 30, 2006

Programadores e interfaces de usuario

Hay algunos brillantes, pero en general casi todos los programadores que conozco son(mos) muy malos diseñando interfaces de usuario. Esto tiene varios motivos, creo:

  • El programador tiende a ver la funcionalidad, no el uso.

  • El programador no tiene la formación adecuada (ni el interés(?)) acerca de usabilidad ni diseño. Quizás tampoco la formación adecuada en programación de GUI's

  • El programador, casi por definición es vago. Gastará el mínimo tiempo en el diseño del interfaz


También hay algunos aspectos que dificultan que un interfaz sea armonioso y usable: los continuos cambios de especificaciones, la indefinición de funcionalidad y de diseño:
- Eso... uhmmm... déjalo también configurable
- Ya, ¿pero dónde?
- Ya le encontrarás un hueco...
- Con tantas opciones ¿no será un poco difícil de usar?
- ...
De todos modos lo que a mi me parece adecuado es que el programador programe un interfaz de usuario diseñado por un diseñador conjuntamente con el cliente, o al menos validado por éste. Si no hay más remedio que diseñarlo por lo menos intentar no hacer el diálogo. En ese mismo enlace hay consejos sencillos sobre lo que no hay que hacer. El ejemplo del GUI de wget es espeluznante... :)

La misma entrada en BP

miércoles, noviembre 22, 2006

Communicating Sequential Processes (CSP)

Hace unos días leyendo una noticia de Slashdot me llamó la atención un comentario en el que se hacía referencia a "Communicating Sequential Processes" (CSP), que según la wikipedia inglesa es un lenguaje de descripción de patrones de interacción en sistemas concurrentes (que dicho así todo seguido suena casi peor...) Según la propaganda ayuda tanto a especificar correctamente el modelo de concurrencia como a verificarlo y depurarlo. Tiene una página oficial, Using CSP en la que se puede descargar el libro Communicating Sequential Processes de 1985 en pdf. Además existen implementaciones para usarlo tanto en Java, JCSP, como en C++, C++CSP. No he tenido tiempo de estudiarlo con tranquilidad, pero lo dejo por aquí por si resulta interesante. Si alguien lo ha estudiado o usado puede ofrecer su opinión al respecto...

La misma entrada en BP

martes, noviembre 21, 2006

Un vistazo a C++09

Acabo de ver referenciado en OSnews:What's Coming in C++ '09 un artículo que resume las últimas decisiones acerca del nuevo estándar de C++: C++09: A Glimpse into the Future. Como decía Ion Gaztañaga parece que la x de C++0x se despeja: intentarán que sea en 2009. Por lo demás, lo que se viene hablando por aquí, rvalue-refrence, conceptos, deducción de tipos en las inicializaciones (¡que bien!, usar auto, ver "Un vistazo a C++0x" por Bjarne Stroustrup), delegación de constructores...

La misma entrada en BP

lunes, noviembre 13, 2006

Enlaces varios (IV)

En la linea de cantidad sobre calidad, ración de enlaces apresurados:
La misma entrada en BP

miércoles, noviembre 08, 2006

Análisis estático de código: flawfinder

Gracias a una entrada en el valle del viento helado de Drizzt, "Algunos enlaces de seguridad", he conocido la existencia de flawfinder, un analizador estático de código (C/C++). Te da alertas de código potencialmente inseguro, sobre todo de la utilización de funciones y prácticas con largo historial de vulnerabilidades. No añade nada que no debiéramos saber ya, pero siempre es diferente saber que tal o cual práctica es potencialmente peligrosa y otra es verlo en tu código ;)

Por dar alguna información más acerca de este tipo de programas en la propia página de éste vienen enlaces a otros similares: splint, cqual.... si hubiese seguido la bitácora de fernand0 como se merece, me habría enterado hace un año: " Análisis estático del código fuente y seguridad"


La misma entrada en BP

lunes, noviembre 06, 2006

Concurrencia y librerías reusables

Vía Thinking Parallel: News for Weeks 43 and 44 / 2006 me encuentro con un extenso artículo acerca del impacto de la concurrencia en las librerías: Concurrency and the impact on reusable libraries.

Es algo sabido que el diseño de las librerías debería tener en cuenta si su uso va a ser concurrente. Y debido a que los tiempos están cambiando es muy probable que lo sea. Si nos damos cuenta a posteriori necesitaremos usar muletas :)


La misma entrada en BP

domingo, noviembre 05, 2006

Linux event handling

Escribe Ulrich Drepper en "Linux event handling":
El código multihilo es absolutamente necesario para avanzar. Todos los procesadores crecen horizontalmente, porque tienen cada vez más contextos de ejecución (cores, hyper-threads)
Hace un repaso a los problemas que se encuentran los programadores a la hora de abordar el tema y propone un interfaz de gestión de eventos (para linux) que se adapte a la situación. Algo está cambiando, efectivamente y no sólo en los lenguajes de programación...

La misma entrada en BP

viernes, noviembre 03, 2006

Noticias sobre Ruby 2.0

Vía Lambda the ultimate: Ruby 2.0 News me entero de lo que se va cociendo en el desarrollo de la nueva versión de Ruby, Ruby 2.0. Parece que no va a soportar temporalmente(?) continuaciones ni green threads. Hay distintas visiones sobre el tema: "Ruby Might Be Sucking Less?" (anteriormente titulado "Ruby Sucks?") y Two Excellent Things for Ruby at Microsoft

Actualización: En More on Ruby Implementations se habla de las distintas implementaciones de ruby y de lo que se hace para evitar su balcanización...

Actualización2: Parece que otros no son tan optimistas con esto de las diferentes implementaciones del entorno de ejecución de ruby. En The Impending Ruby Fracture de David Pollak se repasa el tema. Para él, si sigue todo como hasta ahora, dentro de dos años habrá incompatibilidades entre ellos. Espero que se equivoque...

La misma entrada en BP

jueves, octubre 19, 2006

Entrevista a Ion Gaztañaga sobre C++0x

Andaba yo leyendo un nuevo artículo acerca de C++0x, Ad-Hoc Meeting on Threads in C++ que repasa los temas abiertos para estandarizar los threads en el nuevo C++ cuando, entre tantos nombres ilustres, como Hans Boehm o Herb Sutter nombraban a Ion Gaztañaga y su papel Memory Mapped Files And Shared Memory For C++. Como me ha parecido muy interesante se me ha ocurrido hacerle una entrevista, y aquí está:

P. ¿Puedes hacer una introducción a tu persona y como has llegado a escribir una de las propuestas del C++0x que ahora se debaten para su estandarización

R. Hice una librería para Boost y ahí establecí contacto con Howard Hinnant. Howard, actualmente es el que dirige el grupo de trabajo de librerías (Library Working Group, LWG) del comité de estándar C++ y es realmente una persona muy dialogante y que sabe escuchar las ideas de todo el mundo. Le ayudé un poco con alguna de sus propuestas y de ahí surgió la idea de presentar un artículo propio. Howard me invitó a ir a la conferencia sobre threads y ha sido un auténtico honor estar ahí. Esta semana, el comité está reunido en Portland en sesión oficial y espero estar presente en la próxima reunión que se celebrará en Oxford, el mes de Abril.


P. Las propuestas que se están haciendo para el nuevo C++ ¿las ves todas positivas? ¿cuales te gustan más? ¿y menos? (a mi particularmente me gustan las de los threads, los sockets, las de las expresiones regulares y las incializaciones de contenedores... como escribí en Un vistazo a c++0x por Bjarne Stroustrup y Más sobre C++0x)

R. En general, no hay ninguna propuesta que me disguste, excepto la del Garbage Collector. En mi opinión el garbage collector no encaja en el actual C++ y me chirría bastante. Puede ser debido a prejuicios o a experiencias no muy satisfactorias con otros lenguajes que lo implementan, pero en general, no lo veo necesario y creo que no encaja en la filosofía C++. Pero será un tema muy discutido, sin duda.

Respecto a las demás propuestas, me parece que los threads son esenciales. No tengo conocimientos para evaluar seriamente un modelo de memoria, ya que yo estoy más centrado en estructuras de más alto nivel. En ese sentido, me gusta mucho la propuesta N2094.

También soy un gran fan de rvalue-reference. Creo que solventa un gran problema de rendimiento de C++, que es la generación de temporales, aunque no los elimina completamente. Mi otra debilidad es la propuesta de templates variadicos.

Hay otras propuestas que también me gustan bastante, como los conceptos o los módulos. De todas formas, creo que estas propuestas son menos necesarias que librerías esenciales para usos comunes de programación: funciones de red (sockets), memoria compartida, mapeo de ficheros, manejo de directorios, xml...


P. Crees que los compiladores tardarán menos en implementar estas características que lo que se tardó en implementar el C++98? ¿y los programadores en usarlas?

R. Creo que los programadores los usaran en cuanto estén disponibles. Creo que con la actitud actual de Microsoft de implementar el estandar, la adopción será más rápida que la del estándar C++98. Gcc ya tiene ramas experimentales que implementan templates variadicos, rvalue-reference y conceptos. Metrowerks ya ha implementado rvalue-reference.


P. ¿Crees positivo que un lenguaje se defina a través de un 'comité de estandarización'? ¿qué opinas del estilo 'software libre' de debate/implementación (tipo perl/python)?

R. El estilo "comité" es realmente largo y tedioso. Pero también es una garantía de estabilidad. Me asusta la posibilidad de que como Java, de
una versión a otra se declare obsoleta la mayor parte de la librería estándar. Estos es realmente desastroso para algunos sectores que usan C++, como sistemas críticos de larga duración donde la estabilidad es esencial. Para dar mayor dinamismo, creo que sin Boost, C++ estaría en una situación muy comprometida. El empuje de Boost ha sido clave para recuperar el dinamismo de C++ y creo que C++ está más fuerte que hace
unos años.

El estilo software libre es, en mi opinión, muy interesante, porque es muy dinámico y da buenos resultados e ideas. Creo que no es aplicable a C++ porque necesita una estabilidad mayor, pero podría pensarse en un
modelo híbrido donde se desarrollan librerías y nuevas funcionalidades en un estilo software libre (por ejemplo, gcc es pionero en implementar algunas propuestas) que luego pueden ser estabilizados y estandarizados si se consideran adecuados. Tener una implementación de referencia es muy importante para la estandarización, por lo que no considero ambos
métodos como incompatibles.


P. Añadir tantas cosas al lenguaje y a su librería estándar ¿no es demasiado ambicioso? ¿demasiado complejo?

R. Bueno, más complejo es implementar las librerías estándares de otros lenguajes, porque tienen un tamaño muy grande. Creo que la librería estándar no será un problema porque hay implementaciones libres como Boost que las empresas pueden usar y adaptar para su propio producto. El tema del compilador es más complejo, pero creo que el cumplimiento del estándar se ha convertido en un tema esencial para los usuarios del compilador. De hecho, este deseo de los usuarios fue lo que forzó a Microsoft a implementar el estándar.


P. Parece que una gran parte de las nuevas características van en la linea de aumentar la portabilidad entre sistemas ¿se conseguirá realmente facilitar la vida al programador en esa faceta?

R. Creo que vamos en el buen camino. Los threads serán una muestra de ello. Para el conjunto de librerías TR2, se va a proponer una librería de red, basado en Boost.Asio, que es un tema esencial, en mi opinión para la credibilidad de C++. Quedan todavía funciones como lanzamiento de procesos, comunicación entre procesos, mapeo de ficheros en memoria y otros.


P. ¿Qué opinas de C++/CLI?

R. No lo he usado, porque trabajo principalmente en aplicaciones portables ANSI C++. No me gustaría que fuera un nuevo episodio de "abrazar, extender y exterminar" de Microsoft y creo que la presencia de Herb Sutter ha sido vital para un trabajo leal entre ambos estándares. Así lo han manifestado muchos miembros del comité. Pero creo que no ha conseguido su objetivo de "revolución". Primero apostaron por C# y luego han cambiado a C++/CLI. La limitación de su portabilidad, ya que es un sistema basicamente Windows (Mono es una opción, pero no creo que pueda seguir el ritmo de Microsoft) hace que no sea interesante para mí.


P. Cuando se estandarizará C++0x? (en tu opinión) ¿cuando sabremos que número es la equis? :)

R. No tengo ni idea ;-) La intención es que sea C++09, pero prefiero que sea un buen estandar que incluya threads y otras propuestas que un estandar que salga antes pero no incluya esto. Mientras tanto, siempre está Boost.

Sólo me queda darle las gracias por su amabilidad así como por la cantidad y calidad de sus respuestas.

La misma entrada en BP

martes, octubre 03, 2006

Diseño sencillo contra implementación correcta

Diseño elegante y sencillo frente a implementación correcta. No siempre están enfrentados, pero muchas veces si.

El tema me ha surgido leyendo un blog muy interesante, Thinking parallel, en el cual se discute si los mutex recursivos son buenos o no, que apunta a un excelente post en comp.programming.threads Recursive mutexes by David Butenhof. Las dos tesis contrapuestas son:

  • Los mutex recursivos son buenos, porque ayudan a modularizar y a abstraer (diseño elegante y sencillo)
  • Los mutex recursivos son malos: Del post de Butenhof:"Un diseño correcto y bien pensado no requiere mutex recursivos" (implementación que puede ser no correcta)
Lo cierto es que la tesis de Butenhof está muy bien argumentada y nos da pistas de cuando estamos haciendo las cosas mal:
El problema más grande de todos los problemas de los mutex recursivos es que animan a perder la pista de tu esquema de bloqueos y su ámbito (scope). Esto es mortal. Nefasto. Es el "comedor de threads". Has de coger los mutex durante el tiempo más corto posible. Punto. Siempre. Si estás llamando a algo con un mutex cogido es porque no sabes si está cogido o porque no sabes si la llamada lo necesita, entonces lo estas cogiendo demasiado tiempo.

Abstrayendo... ¿Que caracteriza (entre otras cosas) un buen diseño?

  • No se repiten conceptos (fácilmente modificable)
  • Es elegante (desde lejos, desde arriba, a nivel de relación entre objetos, módulos ...)
  • Es sencillo (en lo posible, para no complicar o entorpecer la implementación)
¿Que caracteriza (entre otras cosas) una buena implementación?
  • No se repite código (mantenible)
  • Es elegante (el código, de cerca, a nivel de función)
  • Es correcto
  • Es óptimo


Entre la sencillez del diseño y la optimización y corrección de la implementación es donde suele haber más problemillas. En lugar de rediseñar cuando se detectan errores de rendimiento el camino más fácil son los hacks, que cuando no son excelentes suelen embarullar el código y distorsionar el propósito del diseño.
En estos casos no habría que tener miedo de refactorizar el código y rediseñar si es preciso, aunque en un caso ideal habría que haberlo tenido en cuenta antes, como requisitos no funcionales, pero sin caer en la sobreingeniería. Difícil verdad ;)

Se podría decir que los mutex recursivos son un hack y por ese motivo usarlos con mucha precaución. Como dice el propio Butenhof (extensible a todos los hacks)

Los mutex recursivos son un hack. No hay nada erróneo si se usan, pero son una muleta. ¿Tienes una pierna rota o una librería? Bueno, usa una muleta. Pero al menos sé consciente de que la estás usando y porqué.



La misma entrada en BP

martes, septiembre 12, 2006

Programación y mantras

Todos tenemos los nuestros. Bueno, igual todos no. Pero es útil a veces recurrir a mantras, adagios, frases... esto de la programación es un arte, una intuición, una ciencia, un camino hacia la iluminación.. :) en ese camino nos ayudarán dichos que condensan la sabiduría de nuestros predecesores. Frases que sobre todo te avisan de los peligros, que te recuerdan que debes estar alerta y no caer en un descuido, un error de diseño o implementación que deberás mantener y hacer compatible hacia atrás ;)
Un repasillo a las que más me gustan:
Lista actualizada:Lista actualizada(2):(Se admiten sugerencias para completar la lista...)

Se pueden encontrar más recomendaciones breves en la lista de reglas de "The Pragmatic Programmer" (libro por cierto muy recomendable)
Ahora sólo hay que ser lo suficientemente listo para saber aplicarlas correctamente ;)

(Actualización: Gracias a Juanjo-Blackshell por el meneo en Menéame: Programación y mantras ;))

La misma entrada en BP

viernes, julio 21, 2006

Mapear XML y Objetos

Acabo de leer en Lambda The ultimate la referencia a un papel que promete ser muy interesante: "Revealing the X/O impedance mismatch"(pdf) de Ralf Lammel y Erik Meijer (de Microsoft Corp. ;) ). Ya hemos hablado por aquí, en Objetos y bases de datos relacionales de las dificultades o sorpresas que uno se puede encontrar en el mapeo entre objetos y bases de datos relacionales (O/R Impedance Mismatch). Pues bien en este papel se viene a repasar lo que puede ocurrir al mapear objetos y XML. Parece bastante completo (> 100 pags.) y tiene una introducción muy interesante.

Además, de los mismos autores, he visto en su página otro papel: "Mappings make data processing go ’round" que da un enfoque más general. Si te interesó el anterior éste también puede interesarte...



La misma entrada en BP

miércoles, junio 21, 2006

El auge y la caída de CORBA (y lo que podemos aprender)

He leído con mucho interés un artículo publicado en ACM Queue: "The Rise and Fall of CORBA" de Michi Henning, en el cual se repasa lo que trataba de ofrecer una tecnología tan prometedora y ambiciosa como CORBA y analiza las causas de la falta de éxito a pesar de las expectativas. Llega a unas conclusiones que deberían hacer aprender de los errores:


  • Los consorcios de estandarización necesitan reglas sólidas para estandarizar las mejores prácticas
  • Ningún estándar debería aprobarse sin una implementación de referencia
  • Ningún estándar debería aprobarse sin haber sido usado para en algunos proyectos de complejidad realista
  • El software libre/abierto tiene procesos de selección darwiniana y por ello se adapta mejor a las reglas anteriores
  • Para crear un software de calidad, la habilidad para decir "no" es más importante que la de decir "si"

También compara en algunos casos CORBA con los servicios web y SOAP, a los que augura un futuro similar. A él se suma Bruce Eckel en Are Web Services Real? Part II, donde critica la falta de realismo con el que se han "vendido" los servicios web (como en el anterior Are Web Services Real?)

Hace ya mucho tiempo, en El peligro de abstraer demasiado, comentaba una entrevista a Anders Hejlsberg en la que también se daban razones para la poca aceptación de CORBA



La misma entrada en BP

lunes, junio 05, 2006

Enlaces varios (III)

Ración apresurada de enlaces variados:


La misma entrada en BP

jueves, mayo 04, 2006

Más sobre C++0x

Leo en el blog de Herb Sutter enlaces a lo que votará el comité de estandarización del nuevo C++0x:


La misma entrada en BP

martes, mayo 02, 2006

Más sobre Eventos contra Threads

Si alguien ha seguido las viejas entradas de mi bitácora de barrapunto sabrá que me interesan mucho las técnicas que usan los servidores para recoger las peticiones de modo que sean óptimos y escalables(*) Pues bien, en Lambda the Ultimate apuntaban a un artículo que tiene varias virtudes: lo que presenta es interesante, pero además hace un resumen conciso del asunto. Se trata de "A Language-Based Approach to Unifying Events and Threads" (pdf) en el que se muestran las dos diferentes aproximaciones al problema y se tratan de unificar usando Haskell y conceptos, que además introduce y explica, como monads (¿mónadas?) y Continuation-passing style. Estimulante (y posiblemente poco práctico :) )

(*)El tema lo he comentado algunas veces:
Programando servidores escalables
, Porque los eventos son una mala idea y más recientemente en Threads y más threads apuntaba a Why Threads Are A Bad Idea (for most purposes))

La misma entrada en BP

lunes, abril 17, 2006

Enlaces varios (II)

Una lista de enlaces varios, que no tengo tiempo (lamentablemente) de editar un poquico más :( No me gusta hacer esto, pero así le pueden ser útiles a alguien y puedo encontrarlos cuando los busque...

La misma entrada en BP

sábado, abril 01, 2006

Los mejores artículos sobre software de 2005

Como el año pasado, Joel Spolsky va a publicar un libro con los mejores artículos sobre desarrollo de sofware, The Best Software Writing II,y admite sugerencias. Se puede consultar la lista de nominaciones que, como la anterior edición, tiene algunos muy intesantes. Por aquí he comentado algunos de ellos, como Why I Hate Frameworks (en ¿Librerías o Frameworks?) o Does Visual Studio Rot the Mind? de Charles Petzold (en ¿Visual Studio pudre la mente?)

La misma entrada en BP

martes, marzo 21, 2006

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

miércoles, marzo 15, 2006

¿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:
Buscando un poquito seguro que se pueden encontar más, pero creo que es suficiente...

La misma entrada en BP

martes, marzo 14, 2006

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 :)

miércoles, febrero 22, 2006

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

jueves, febrero 16, 2006

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

miércoles, febrero 08, 2006

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

domingo, enero 22, 2006

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

jueves, enero 12, 2006

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 :(

martes, enero 03, 2006

"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