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

Mono Status '05

Leo en el blog de Miguel de Icaza un completo repaso al estado actual de mono y su futuro próximo. Repasa el soporte de Windows.Forms, la version 2.0 del framework, MonoDevelop, ASP.NET, el estado de los compiladores y unas cuantas cosas más.

Actualización: más info en la portada de barrapunto: "Estado actual de Mono", El valle del viento helado: "Resumen del estado de mono" y OSNews: "Mono Status 2005"

La misma entrada en BP

Traducción del bliki de Martin Fowler

Leo en el bliki del propio Martin Fowler que ha permitido que se traduzca al castellano, así que podremos disfrutar a partir de ahora del blog de TraduccionMartinFowler, por Jesús Pérez Sánchez.

La misma entrada en BP

¿Visual Studio pudre la mente?

Hacía tiempo que no disfrutaba tanto con un artículo. Un auténtico rant como los de antes. El escrito en cuestión es de Charles Petzold, muy conocido en en el mundillo de la programación windows por libro muy bueno y muy extenso: "Programing Windows".

El artículo es "Does Visual Studio Rot the Mind?" Comienza por plantearse como la tecnología tiene capacidad de enganchar y no siempre de solucionar problemas y luego tiene una serie de críticas bastante concretas al Visual Studio, pero que en general se pueden aplicar a cualquier IDE o RAD: Generación de código ininteligible, opciones por defecto que acaban siendo las únicas, dependencia de las herramientas, en lugar de lo que verdaderamente importa en el desarrollo (recordemos que todavía no existe la bala de plata)

Como buen artículo nacido para ser polémico, hay que tomarlo con precaución, pero me parece que siempre es interesante plantearse el viejo tema de IDE vs editor

Algunas frases extraídas del artículo:

What the Internet seems to do best is make commonly available enormously vast resources of mis-information that we never knew existed.

It is very common for us to say about a piece of consumer technology that “we didn’t know how much we needed it until we had it,” and much of this technology seems targeted not to satisfy a particular need, but to get us hooked on something else we never knew we needed; not to make our lives better, but to tempt us with another designer drug. “I can’t live without my ___________” and you can fill in the blank. This week, I think, it’s the video iPod.

Now I know that five or ten years from now we’ll be able to perform this entire operation entirely from the cable remote, which may actually be a computer remote, including pausing the episode of Friends to download the movie in which the actress playing Joey’s girlfriend appears, and watch it on demand, and then go back to the episode of Friends we were watching if we so desire. And I might be more thrilled at this prospect if I thought it would make us better, happier, nicer human beings. But that’s not immediately obvious to me.

IntelliSense is considered by some to be the most important programming innovation since caffeine.

And yet, IntelliSense is also dictating the way we program.[...]In order to get IntelliSense to work correctly, bottom-up programming is best. IntelliSense wants every class, every method, every property, every field, every method parameter, every local variable properly defined before you refer to it.[...]you must also write you code linearly from beginning to end [...]You must define all variables before you use them.

(Sobre la generación automática de código) The time when I can really use some help is not when I’m starting a program, but when I’m trying to finish it. Where is Visual Studio then?

This bothered me because Visual Basic was treating a program not as a complete coherent document, but as little snippets of code attached to visual objects. That’s not what a program is. That’s not what the compiler sees.

If Visual Studio really wanted you to write good code, every time you dragged a control onto your form, an annoying dialog would pop up saying “Type in a meaningful name for this control.” But Visual Studio is not interested in having you write good code. It wants you to write code fast.

I don’t know what rule you go by, but for me it’s always been simple: “Three or more: Use a for.” This is why we have loops. This is why we are programmers.

Por supuesto se pueden leer flames al respecto: en Slashdot:"Does Visual Studio Rot the Mind?" y Lambda the Ultimate: "Does Visual Studio Rot the Mind?"

La misma entrada en BP

Visita guiada al nuevo intérprete de comandos de Microsoft

En Ars Technica han publicado un análisis bastante profundo del nuevo interprete de comandos de Microsoft, Monad. Desde luego es una de las cosas que uno echa de menos cuando se sienta delante de uno de sus sistema, algo que les hacía falta hace tiempo. Lo cierto es que tiene muy buena pinta...

Se puede leer más en diversos sitios (Slashdot:" A Guided Tour of the Microsoft Command Shell", OSNews :"A Guided Tour of the Microsoft Command Shell", El valle del Viento Helado: "MSH: El nuevo Shell de Microsoft, un tour guiado" (Actualización:) y en Barrapunto: "Visita guiada al nuevo intérprete de comandos de Microsoft")

La misma entrada en BP

El software y la revolución de la concurrencia

Herb Sutter ha vuelto a escribir un artículo acerca de las implicaciones que va a tener el advenimiento masivo de los procesadores multicore: "Software and the Concurrency Revolution". Comenta como va a afectar a la creación de software desde varios puntos de vista: el tipo de lenguajes de programación más adecuados, el modo en el que se deben manejar estados o memorias compartidas, desarrollo de herramientas que ayuden a desarrollar un software concurrente de calidad... En fin, muchos temas abiertos.

El artículo anterior: "The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software" lo comentó Draco en "Se acabó el rendimiento gratis" y yo en "Concurrencia, lenguajes y programadores"

La misma entrada en BP

Escalabilidad e interfaces de usuario

Eric Sink en una entrada reciente nos recuerda la importancia de la escalabilidad entendida de varios modos, entre ellos uno que no se suele tener en cuenta:

Finally, let's not confine scalability to things which can be measured with a stopwatch. Sometimes scalability problems are a bit more qualitative. For example, the Vault Admin tool presents the list of users in a regular Windows listbox control. That's fine with 100 users, but it's not exactly the right UI for a system with 5,000 users.

O sea, que la escalabilidad no es (sólo) cuestión de rendimento.

La misma entrada en BP

Rendimiento y leyendas urbanas en Java

En IBM developerWorks han publicado un artículo sobre la gestión de memoria que hace la máquina virtual de Java: "Urban performance legends, revisited". Ha tenido poca repercusión en castellano (creo), pero en inglés ha generado las flames de rigor además de los comentarios de más de un exaltado.

La misma entrada en BP

Threads y más threads

Ya hemos hablado por aquí a veces de programación concurrente threads y similares, pero últimamente he visto una proliferación de comentarios y artículos al respecto, seguramente porque se acabó el rendimiento gratis

• "Extreme Software Scaling" sobre el impacto de los chips multiprocesador en los programadores y sistemas.
• "Protothreads and Other Wicked C Tricks" sobre una librería multiplataforma de threads ligeros. Leer cuidadosamente, que puede ser muy útil pero tiene muchas limitaciones. (La discusión está muy bien, porque se toca tema espinoso de eventos vs threads)
• Does Python have a concurrency problem? sobre el modo en que Python enfoca (o debería enfocar) el tema.

La misma entrada en BP

Threads y C++(estándar)

Hoy leyendo LtU me he encontrado con la referencia a "Threads Cannot be Implemented as a Library" de Hans J. Boehm. En el artículo se argumenta que los threads no pueden ser manejados por una librería, sino que el lenguaje va a usarlos debe tener una política de gestión de memoria que los incluya en su definición. Y pone el ejemplo de C(++) y los Pthreds, con casos en los que no se garantiza la corrección. En esta línea se estaba haciendo en la estandarización de C++ un esfuerzo que ya comentamos en "Los peligros de programar con threads".
Eso si, por lo que leo en los comentarios de LtU, en general los compiladores tienen extensiones para evitar este tipo de cosas, pero el modelo de memoria estándar no lo garantiza. Si no fuese así ya nos habríamos enterado de la inconsistencia :)

La misma entrada en BP

Diseño de APIs

Leo en el bliki de Martin Fowler una buena entrada acerca del diseño de interfaces y APIs. Viene a decir que si al usar una API tienes que acordarte siempre de hacer algo no es un buen diseño.

Como ejemplo: si tienes que acordarte de llamar a super (o a la clase padre en C++) es que no es un buen diseño. En este caso particular recurre al patrón Método Plantilla (Template Method) para mejorar el diseño.

Y es que, como dice Scott Meyers en un artículo apuntado en la entrada anterior (The Most Important Design Guideline?), "La responsabilidad de un error en el uso de un interfaz es resposabilidad del diseñador, no del usuario". (Convendría seguramente matizar una opinión tan tajante, pero, como norma general, una API es mejor cuanto menos propensa a fallos es)
La misma entrada en BP

Tipos estáticos y dinámicos ¿el fin de la guerra fría?

En un artículo bastante llamativo, sobre todo por el título, Erik Meijer y Peter Drayton postulan el fin de la guerra fría entre lenguajes: "Static Typing Where Possible, Dynamic Typing When Needed: The End of the Cold War Between Programming Languages" (pdf). En él se sugiere que deben usarse los tipos estáticos por defecto, salvo que sea necesario. Además se hace un repaso sobre lo que quiere decir un programador cuando dice Necesito un lenguaje dinámico/estático. Muy instructivo.
Visto vía LtU, donde, por cierto, no se han enterado del fin de la guerra :)

La misma entrada en BP

Enlaces varios

Una lista de enlaces varios, que no tengo tiempo (lamentablemente) de editar esto un poquico más :(

• Siguiendo con la programación paralela en el futuro: "On Threads", "Software in the TLP Era" y TLP Design Decisions (TLP: Thread Level Parallelism)
• "Never Call Virtual Functions during Construction or Destruction": Scott Meyers dando consejos de programación en C++ (sobretodo para gente proveniente de Java o C#). Este es uno de los nuevos incluidos en "Effective C++" tercera edición
• Entrevista en tres partes a Erich Gamma, coautor del famoso "Design Patterns" (más conocido por GoF-Gang of Four-)"How to Use Design Patterns", Flexibility and Reuse y Design Principles from Design Patterns
• La búsqueda de un buen sistema de contrucción de proyectos para C++ en "The Quest for the Perfect Build System". Prueba VS.NET, make, jam y Scons
• "Ajax on Rails" ¿Que mejor que juntar dos de los mejores y más recientes memes de esto de la programación? :)

La misma entrada en BP

Los síndromes de los programadores olvidados

El developerdotstar republican viejos/buenos artículos sobre desarrollo de software. En este caso le ha tocado a "Syndromes of Forgotten Programmers" en el que se describen las patologías más comunes que se suele encontrar un programador a la hora de mantener el código de otros. Es un repaso breve y conciso. Por citar (traduciendo al vuelo) algunos:

• El recolector de basura: Jamás borra una linea de código, ni un comentario, ni un módulo no usado...
• El criptógrafo: Sus variables se llaman xyz
• El clon: No empieza nada desde el principio, lo copia todo de algo que se le parece...
• El desconocido: No dejó registro de que era él el que hacía eso. Por algo será :)

Después de leer estos síndromes y el conocido "How To Write Unmaintainable Code" ya tenemos muchos datos sobre lo que no deberíamos hacer.

La misma entrada en BP

Cabeceras precompiladas multiplataforma

Noel Llopis en Games from Within ha publicado un nuevo artículo acerca de la distribución física en un proyecto de C++. Después de A First Look y Build Times ahora nos brinda The Care and Feeding of Pre-Compiled Headers. Hace introducción a las cabeceras precompiladas y da alguna solución para hacer código multiplataforma y que aproveche su beneficio si están disponibles. También propone un script en Python para buscar candidatos para insertar en los precompilados. Buena lectura si tenemos proyectos de C++ grandes u ordenadores poco potentes.

La misma entrada en BP

Sobre la simplicidad

Alguna vez hemos hablado por aquí de lo importante de mantener la simplicidad en la programación. Ahora es Grady Booch en su blog el que nos lo recuerda. No lo esperaba de él, la verdad, pero en su entrada, "On Simplicity" resalta lo importante y valiosa que es la simplicidad a través de unas citas que voy a traducir libremente:

• "La habilidad de simplificar es eliminar lo innecesario para que lo necesario pueda hablar" Hans Hoffmann
• "La simplicidad llevada al extremo se convierte en elegancia" Jon Franklin
• "La simplicidad es la máxima sofisticación" Leonardo da Vinci

Estas citas se pueden complementar con una que tenía guardada:

• "Controlar la complejidad es la esencia de la programación de ordenadores" Brian Kernigan

Ahora solo hay que ponerlo en práctica :-)

La misma entrada en BP

Continuaciones para cascarrabias

Suelo consultar el blog de Sam Ruby, porque tiene comentarios breves pero muy interesantes. En este caso se me escapó fue un articulillo un poco más largo titulado "Continuations for Curmudgeons" (continuaciones para cascarrabias). Me ha resultado muy instructivo ¿Seré un cascarrabias de esos? :) Tiene ejemplos en diversos lenguajes populares y va paso a paso explicando cosas como paso por valor o por referencia, continuaciones, closures y cosas similares. Interesante. Visto, como siempre, vía LtU

La misma entrada en BP

Presentación

Esto es otro weblog de programación más. Debería (en el mejor de los casos) ser la réplica de Mi bitácora de barrapunto. Ya veremos si lo utilizo o no...