domingo, diciembre 11, 2005
¿Pudre la mente el Visual Studio?
Llevaba tiempo queriendo comentar Does Visual Studio Rot the Mind?, desde que lo vi citado en Yet Another Programming Weblog, que hace algunos interesantes comentarios en español.
El artículo original es de Charles Petzold, uno de los autores de libros más importantes sobre programación en Windows. Empieza con una larga digresión acerca de la película «Desk Set», que en España se tradujo por «Su otra mujer» y es una comedia romántica de Katherine Hepburn y Spencer Tracy que viene a cuento porque esa otra mujer es «Mrs. EMERAC»; es decir, aparte de la (poco creíble) historia de amor entre los protagonistas, hay una línea que cuenta cómo los empleados de la empresa se asustan porque viene un ordenador a sustituirlos y el encargado de montar esa máquina es un Spencer Tracy obsesionado con los ordenadores. La película contó con el apoyo de IBM y es pura propaganda de la compañía: al final (esto es un spoiler) los ordenadores permiten hacer más cosas pero también necesitan más gente, así que todos contentos. No aparece entre el top 10 de películas geek de Microsiervos, pero según Petzold es una de las primeras. Y según la wikipedia, otra de las conclusiones de la película es que «los informáticos pueden parecer un poco raros en ocasiones, pero en el fondo son gente maja» («One of the implicit morals is that computer people may seem a little quirky at times, but they are basically nice people.»)
No quería enrollarme tanto como Petzold sobre la película, pero al final casi lo he hecho. En cualquier caso, es una película curiosa y pasé un buen rato viéndola. Petzold también menciona otras películas, entre ellas «Juegos de guerra», que yo vi cuando niño y me marcó, claro: ¡poder cambiar las notas desde casa! :-)
Toda la cinéfila introducción de Petzold tiene una conclusión: que las máquinas a veces nos deshumanizan al obligarnos a ir a su ritmo en lugar de ir ellas al nuestro. Eso es más o menos lo que critica en el Visual Studio.
Centrándose, empieza por las críticas que han surgido al PowerPoint y cómo parece que lleva a una forma de hacer las cosas poco profunda, basada en listas. Dice que nuestra relación con la tecnología está basada en la adicción: una vez que probamos una tecnología –por ejemplo, los teléfonos móviles o el correo electrónico- luego no podemos vivir sin ella.
Esa adición se refleja también en algo que ha comentado hace poco Juanjo Navarr, el estrés informativo al que también hace referencia Petzold. No está muy claro que poder parar una emisión de «Friends» para poder comprobar en Internet quién es esa actriz que hace una aparición secundaria nos haga mejores personas... como mucha otra tecnología. Esta reflexión es interesante especialmente para los programadores a los que va dedicada la charla, porque los programadores hacen lo más potente que se puede llevar a cabo con un ordenador: escriben las órdenes que mandan sobre el ordenador.
Mucha gente haciendo cosas, muchos programadores intentando simplificar la vida en primer lugar de los propios programadores, tiene como consecuencia la abundancia de tecnologías. Uno de los aspectos en los que se refleja en la programación es el crecimiento de las APIs: en Windows 1.0 había 400 funciones documentadas; diez años después, en Windows 95, había más de mil; en .NET Framework 2.0, sólo dentro de los assemblies que empiezan por System hay más de 5000 clases públicas con más de 45000 métodos públicos y 15000 propiedades públicas. Estas cifras que da Petzold claramente impresionan.
Por supuesto, ningún programador puede tener en la cabeza todos estos métodos y propiedades. Para aliviar este problema, Visual Studio proporciona el autocompletado, que llaman IntelliSense. Petzold dice tener una relación de amor-odio con esta tecnología: es necesaria, pero te obliga a programar de una cierta manera, haciendo primero las clases básicas y luego las que utilizan estas, es decir, una programación bottom-up en vez de top-down. Y más: hay que escribir el código linealmente, poniendo primero las declaraciones de variables antes de utilizarlas porque, si no, te lo intenta cambiar por otra cosa. Vamos, que según Petzold, volvemos al Edlin.
Además, según él, IntelliSense nos hace más tontos: ya no intentamos recordar nada, sino que vamos probando con las distintas alternativas que nos va ofreciendo el autocompletado...
Creo que exagera un poco (pero esa es la gracia del artículo). De hecho, hace no mucho estuve contando por aquí cómo yo andaba buscando un IDE en Linux que tuviese autocompletado. Si ya es difícil dedicándose a programar sólo .NET conocer todos sus métodos, los que no nos dedicamos principalmente a la programación y, además, un día programamos en Java, otro en C++/Qt, otro en C++/MFC y otro en C/POSIX, necesitamos esas ayudas.
Otra de las ayudas automáticas de los entornos de programación que critica Petzold es la generación automática de código. La verdad es que a mí no me gusta mucho, pero, por otra parte, veo hay cosas muy repetitivas que es mejor que se generen automáticamente. ¿No es para eso para lo que queremos los ordenadores, para evitar las labores repetitivas?
El ejemplo más claro son los asistentes para crear aplicaciones visuales (de los que Petzold cuenta la historia en Windows). El código que generan muchas veces es ininteligible, en especial cuando se utilizan los nombres por defecto que ofrece el entorno (listbox1, listbox2, etc.). En Java, por ejemplo, he tenido que modificar un programa con los diálogos generados por el editor gráfico del Builder X y me volví mico (muchos de los problemas son los mismos que comenta Petzold con respecto al Visual Studio). En Qt, también me volví loco para generar layouts a mano, pero al final fueron mucho mejores: además de con un código más entendible, se adaptaban a la resolución, un aspecto que según Petzold incluye Avalon porque cada vez es más importante al aparecer nuevas resoluciones en los dispositivos de visualización. Sin embargo, Visual Studio, por defecto, sigue utilizando pixels para los layouts de Windows Forms.
Es muy interesante la reflexión que hace Petzold sobre las variables miembro de clase como el equivalente de C++ (y C#) de las variables globales en C. Por otra parte, algo que he notado desde que hago refactorización, es que tiendo a tener más variables de clase, aunque en clases más pequeñas. Hay incluso quien piensa que todos los métodos deberían ser públicos para poder realizar testing.
Una característica de Visual Studio que Petzold agradece sin duda es la posibilidad de renombrar variables, es decir, la refactorización más básica, que es algo que yo también creo que debe tener cualquier entorno de programación y que también estuve buscando en su momento para Linux.
En resumen, un artículo muy interesante en general, porque trata temas importantes sobre las herramientas de programación de una manera amena y, de paso, cuenta bastantes historias del pasado y del posible futuro de la programación en Windows.
El artículo original es de Charles Petzold, uno de los autores de libros más importantes sobre programación en Windows. Empieza con una larga digresión acerca de la película «Desk Set», que en España se tradujo por «Su otra mujer» y es una comedia romántica de Katherine Hepburn y Spencer Tracy que viene a cuento porque esa otra mujer es «Mrs. EMERAC»; es decir, aparte de la (poco creíble) historia de amor entre los protagonistas, hay una línea que cuenta cómo los empleados de la empresa se asustan porque viene un ordenador a sustituirlos y el encargado de montar esa máquina es un Spencer Tracy obsesionado con los ordenadores. La película contó con el apoyo de IBM y es pura propaganda de la compañía: al final (esto es un spoiler) los ordenadores permiten hacer más cosas pero también necesitan más gente, así que todos contentos. No aparece entre el top 10 de películas geek de Microsiervos, pero según Petzold es una de las primeras. Y según la wikipedia, otra de las conclusiones de la película es que «los informáticos pueden parecer un poco raros en ocasiones, pero en el fondo son gente maja» («One of the implicit morals is that computer people may seem a little quirky at times, but they are basically nice people.»)
No quería enrollarme tanto como Petzold sobre la película, pero al final casi lo he hecho. En cualquier caso, es una película curiosa y pasé un buen rato viéndola. Petzold también menciona otras películas, entre ellas «Juegos de guerra», que yo vi cuando niño y me marcó, claro: ¡poder cambiar las notas desde casa! :-)
Toda la cinéfila introducción de Petzold tiene una conclusión: que las máquinas a veces nos deshumanizan al obligarnos a ir a su ritmo en lugar de ir ellas al nuestro. Eso es más o menos lo que critica en el Visual Studio.
Centrándose, empieza por las críticas que han surgido al PowerPoint y cómo parece que lleva a una forma de hacer las cosas poco profunda, basada en listas. Dice que nuestra relación con la tecnología está basada en la adicción: una vez que probamos una tecnología –por ejemplo, los teléfonos móviles o el correo electrónico- luego no podemos vivir sin ella.
Esa adición se refleja también en algo que ha comentado hace poco Juanjo Navarr, el estrés informativo al que también hace referencia Petzold. No está muy claro que poder parar una emisión de «Friends» para poder comprobar en Internet quién es esa actriz que hace una aparición secundaria nos haga mejores personas... como mucha otra tecnología. Esta reflexión es interesante especialmente para los programadores a los que va dedicada la charla, porque los programadores hacen lo más potente que se puede llevar a cabo con un ordenador: escriben las órdenes que mandan sobre el ordenador.
Mucha gente haciendo cosas, muchos programadores intentando simplificar la vida en primer lugar de los propios programadores, tiene como consecuencia la abundancia de tecnologías. Uno de los aspectos en los que se refleja en la programación es el crecimiento de las APIs: en Windows 1.0 había 400 funciones documentadas; diez años después, en Windows 95, había más de mil; en .NET Framework 2.0, sólo dentro de los assemblies que empiezan por System hay más de 5000 clases públicas con más de 45000 métodos públicos y 15000 propiedades públicas. Estas cifras que da Petzold claramente impresionan.
Por supuesto, ningún programador puede tener en la cabeza todos estos métodos y propiedades. Para aliviar este problema, Visual Studio proporciona el autocompletado, que llaman IntelliSense. Petzold dice tener una relación de amor-odio con esta tecnología: es necesaria, pero te obliga a programar de una cierta manera, haciendo primero las clases básicas y luego las que utilizan estas, es decir, una programación bottom-up en vez de top-down. Y más: hay que escribir el código linealmente, poniendo primero las declaraciones de variables antes de utilizarlas porque, si no, te lo intenta cambiar por otra cosa. Vamos, que según Petzold, volvemos al Edlin.
Además, según él, IntelliSense nos hace más tontos: ya no intentamos recordar nada, sino que vamos probando con las distintas alternativas que nos va ofreciendo el autocompletado...
Creo que exagera un poco (pero esa es la gracia del artículo). De hecho, hace no mucho estuve contando por aquí cómo yo andaba buscando un IDE en Linux que tuviese autocompletado. Si ya es difícil dedicándose a programar sólo .NET conocer todos sus métodos, los que no nos dedicamos principalmente a la programación y, además, un día programamos en Java, otro en C++/Qt, otro en C++/MFC y otro en C/POSIX, necesitamos esas ayudas.
Otra de las ayudas automáticas de los entornos de programación que critica Petzold es la generación automática de código. La verdad es que a mí no me gusta mucho, pero, por otra parte, veo hay cosas muy repetitivas que es mejor que se generen automáticamente. ¿No es para eso para lo que queremos los ordenadores, para evitar las labores repetitivas?
El ejemplo más claro son los asistentes para crear aplicaciones visuales (de los que Petzold cuenta la historia en Windows). El código que generan muchas veces es ininteligible, en especial cuando se utilizan los nombres por defecto que ofrece el entorno (listbox1, listbox2, etc.). En Java, por ejemplo, he tenido que modificar un programa con los diálogos generados por el editor gráfico del Builder X y me volví mico (muchos de los problemas son los mismos que comenta Petzold con respecto al Visual Studio). En Qt, también me volví loco para generar layouts a mano, pero al final fueron mucho mejores: además de con un código más entendible, se adaptaban a la resolución, un aspecto que según Petzold incluye Avalon porque cada vez es más importante al aparecer nuevas resoluciones en los dispositivos de visualización. Sin embargo, Visual Studio, por defecto, sigue utilizando pixels para los layouts de Windows Forms.
Es muy interesante la reflexión que hace Petzold sobre las variables miembro de clase como el equivalente de C++ (y C#) de las variables globales en C. Por otra parte, algo que he notado desde que hago refactorización, es que tiendo a tener más variables de clase, aunque en clases más pequeñas. Hay incluso quien piensa que todos los métodos deberían ser públicos para poder realizar testing.
Una característica de Visual Studio que Petzold agradece sin duda es la posibilidad de renombrar variables, es decir, la refactorización más básica, que es algo que yo también creo que debe tener cualquier entorno de programación y que también estuve buscando en su momento para Linux.
En resumen, un artículo muy interesante en general, porque trata temas importantes sobre las herramientas de programación de una manera amena y, de paso, cuenta bastantes historias del pasado y del posible futuro de la programación en Windows.
Comentarios:
Publicar un comentario
