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