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:

• Delegación de constructores (un constructor sería capaz de llamar a otro en la inicialización, algo que hasta ahora no se podía hacer y violaba uno de los principios básicos: DRY (Don't Repeat Yourself)): Delegating Constructors (revision 3) (pdf)
• Deducción automática de tipo (me gusta, esto ya no parece C++ ;) ): N1984, Deducing the type of variable from its initializer expression (revision 4) (pdf)
• Extensiones en la librería estándar (punteros inteligentes, expresiones regulares, más contenedores...): N1836, Draft Technical Report on C++ Library Extensions (pdf)

La misma entrada en BP

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

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...

• "The Bad Code Spotter's Guide" por Diomidis Spinellis. Una guía sencilla guia para detectar errores clásicos en el código (repeticiones, reinventar ruedas...)
• "Debugging 101" en Hacknot Una introducción al difícil arte del depurado de programas. El comienzo es genial:

  "An interactive debugger is an outstanding example of what is not needed - it encourages trial-and-error hacking rather than systematic design, and also hides marginal people barely qualified for precision programming." Harlan Mills

• "The Development Abstraction Layer", otro artículo de Joel Spolsky. Interesante como siempre. Lo que todo programador desea oír :)

  Your first priority as the manager of a software team is building the development abstraction layer [...] If a programmer somewhere is worrying about a broken chair, or waiting on hold with Dell to order a new computer, the abstraction has sprung a leak.



• "Regular Expressions in C++ with Boost.Regex" por Ryan Stephens Hasta que estén soportadas en el nuevo estándar, podemos ir usándolo con las librerías boost

La misma entrada en BP

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

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