sábado, diciembre 31, 2005
Los jóvenes y la programación
Parece que estoy haciendo una serie. Pero es que Joel Spolsky me lo pone a huevo.
Ha perpretado uno de sus siempre bien escritos artículos sobre los jóvenes programadores. Dice que hace años cuando en una entrevista le dejaba al candidato libertad para elegir el lenguaje en el que programar, en el 99% de los casos el elegido era C. Pero ahora es Java. Y eso no le gusta.
Dice que Java es demasiado fácil. Que un buen programador tiene que entender punteros y recursión (para lo que habla de Scheme). Y, en cierto modo, dice lo mismo que el artículo anterior sobre hacer ciencia:
Vamos, que al final, ser un buen programador es pensar en abstracto.
El problema, según él, es que se ha bajado el nivel de la carrera, porque a él le parecía bien que fuese un filtro:
¿Pensarán los mismos los alumnos de primer año en la universidad? (Sí, es una pregunta retórica.)
Ha perpretado uno de sus siempre bien escritos artículos sobre los jóvenes programadores. Dice que hace años cuando en una entrevista le dejaba al candidato libertad para elegir el lenguaje en el que programar, en el 99% de los casos el elegido era C. Pero ahora es Java. Y eso no le gusta.
Dice que Java es demasiado fácil. Que un buen programador tiene que entender punteros y recursión (para lo que habla de Scheme). Y, en cierto modo, dice lo mismo que el artículo anterior sobre hacer ciencia:
But beyond the prima-facie importance of pointers and recursion, their real value is that building big systems requires the kind of mental flexibility you get from learning about them, and the mental aptitude you need to avoid being weeded out of the courses in which they are taught. Pointers and recursion require a certain ability to reason, to think in abstractions, and, most importantly, to view a problem at several levels of abstraction simultaneously. And thus, the ability to understand pointers and recursion is directly correlated with the ability to be a great programmer.
Vamos, que al final, ser un buen programador es pensar en abstracto.
El problema, según él, es que se ha bajado el nivel de la carrera, porque a él le parecía bien que fuese un filtro:
I've seen all kinds of figures for drop-out rates in CS and they're usually between 40% and 70%. The universities tend to see this as a waste; I think it's just a necessary culling of the people who aren't going to be happy or successful in programming careers.
¿Pensarán los mismos los alumnos de primer año en la universidad? (Sí, es una pregunta retórica.)
No recordaba dónde había encontrado el enlace de la historia anterior pero al final lo reencontré: en reddit, otra especia de diggit al que llegué desde una entrada de Joel Spolsky sobre enlaces interesantes.
viernes, diciembre 30, 2005
Pensamiento extremo
Quiero dejar por aquí un enlace a una curiosa charla titulada «Extreme Thinking». Básicamente cuenta por qué es difícil hacer ciencia (investigar, no aprenderse lo que pone un libro) y cómo conseguir llevarlo bien. Además, lo relaciona con el aprendizaje.
Para ilustrar por qué es difícil la ciencia propone un juego. Supongamos que tenemos cuatro cartas. Cada carta tiene una letra en una cara y un número en la otra. Sólo puedes ver una cara de las cartas y ves A, B, 2 y 1. De lo que se trata es de adivinar si se sigue la siguiente regla: si una carta tiene una vocal en una cara, en la otra tiene un número par. ¿A qué cartas habría que dar la vuelta para ver si es verdad? Hay que responder rápido.
Ahora hagamos otro juego. Eres policía y estás comprobando si se cumplen las normas sobre bebidas a menores, que dicen que los menores de 18 no pueden beber alcochol. Entras en un bar y te encuentras a cuatro personas. La primera persona está bebiendo cerveza; la segunda está bebiendo una coca-cola light; la tercera persona no sabes qué está bebiendo pero está claro que tiene más de 18 años; la cuarta persona está claro que es un chaval de menos de 18 y no puedes ver qué está bebiendo. ¿Qué es necesario comprobar para saber si se cumplen las normas?
Lo que suele ocurrir en esta situación es que la gente falla en el primer juego y acierta en el segundo... cuando en realidad son el mismo juego, sólo que en el primero tratamos con conceptos abstractos (letras y números) y en el segundo con conceptos concretos y cercanos: personas y bebidas. Y nuestra mente está mucho más preparada para pensar sobre personas y bebidas que sobre letras y números.
En el primer juego la mayoría de la gente piensa que hay que darle la vuelta a la primera carta y a la tercera. Lo de la primera es verdad (es una vocal y hay que comprobar si hay un número par al otro lado), pero la tercera no es necesario mirarla: aunque hubiese una consonante, se cumpliría la regla. En cambio, a la que sí hay que darle la vuelta es a la cuarta carta: si hubiese una vocal, no se cumpliría la regla.
El problema es que la ciencia trata con situaciones abstractas, con generalizaciones. La ciencia empezó con el paso del mito (unos dioses -parecidos a personas pero un poco raros- causaban las cosas) al logos (una explicación racional). Descartes y Newton introdujeron conceptos mucho más abstractos (la notación científicia, la gravedad, la inercia...) y nuestra mente está especialmente preparada para funcionar bien en situaciones sociales, que involucren a otras personas, no para interpretar fenómenos abstractos.
Los tres principios que propone el autor del ensayo para hacer ciencia son:
1. El aprendizaje debe tener un propósito. Vamos, que te mole.
2. Hay que pensar a largo plazo. Cuando sólo piensas a corto plazo, haces cosas nada efectivas.
3. Tener un buen entorno social, es decir, rodearte de personas interesadas en lo mismo que tú.
Creo que es una lectura interesante.
Para ilustrar por qué es difícil la ciencia propone un juego. Supongamos que tenemos cuatro cartas. Cada carta tiene una letra en una cara y un número en la otra. Sólo puedes ver una cara de las cartas y ves A, B, 2 y 1. De lo que se trata es de adivinar si se sigue la siguiente regla: si una carta tiene una vocal en una cara, en la otra tiene un número par. ¿A qué cartas habría que dar la vuelta para ver si es verdad? Hay que responder rápido.
Ahora hagamos otro juego. Eres policía y estás comprobando si se cumplen las normas sobre bebidas a menores, que dicen que los menores de 18 no pueden beber alcochol. Entras en un bar y te encuentras a cuatro personas. La primera persona está bebiendo cerveza; la segunda está bebiendo una coca-cola light; la tercera persona no sabes qué está bebiendo pero está claro que tiene más de 18 años; la cuarta persona está claro que es un chaval de menos de 18 y no puedes ver qué está bebiendo. ¿Qué es necesario comprobar para saber si se cumplen las normas?
Lo que suele ocurrir en esta situación es que la gente falla en el primer juego y acierta en el segundo... cuando en realidad son el mismo juego, sólo que en el primero tratamos con conceptos abstractos (letras y números) y en el segundo con conceptos concretos y cercanos: personas y bebidas. Y nuestra mente está mucho más preparada para pensar sobre personas y bebidas que sobre letras y números.
En el primer juego la mayoría de la gente piensa que hay que darle la vuelta a la primera carta y a la tercera. Lo de la primera es verdad (es una vocal y hay que comprobar si hay un número par al otro lado), pero la tercera no es necesario mirarla: aunque hubiese una consonante, se cumpliría la regla. En cambio, a la que sí hay que darle la vuelta es a la cuarta carta: si hubiese una vocal, no se cumpliría la regla.
El problema es que la ciencia trata con situaciones abstractas, con generalizaciones. La ciencia empezó con el paso del mito (unos dioses -parecidos a personas pero un poco raros- causaban las cosas) al logos (una explicación racional). Descartes y Newton introdujeron conceptos mucho más abstractos (la notación científicia, la gravedad, la inercia...) y nuestra mente está especialmente preparada para funcionar bien en situaciones sociales, que involucren a otras personas, no para interpretar fenómenos abstractos.
Los tres principios que propone el autor del ensayo para hacer ciencia son:
1. El aprendizaje debe tener un propósito. Vamos, que te mole.
2. Hay que pensar a largo plazo. Cuando sólo piensas a corto plazo, haces cosas nada efectivas.
3. Tener un buen entorno social, es decir, rodearte de personas interesadas en lo mismo que tú.
Creo que es una lectura interesante.
Papeles
Fernand0 tiene una historia sobre la evaluación de los científicos. La idea, muy originalmente, se basa en contar el número de referencias a las publicaciones del científico.
Casualmente, ayer me encontré con el blog de un tío que investiga en complejidad computacional y tenía una historia que hablaba de wasted papers, que traducido a spanglish sería «papers desaprovechados». En él venía a decir -con una prosa divertida- que las publicaciones científicas son una pérdida de tiempo y que habría que buscar otras formas de comunicar el conocimiento.
Tanto él como Fernand0 hablan de los comentarios de los revisores. Buenísimo lo que extrae Fernad0 del «We are so sorry to inform you...». Casi tanto como estas formas de contestar a los revisores.
Casualmente, ayer me encontré con el blog de un tío que investiga en complejidad computacional y tenía una historia que hablaba de wasted papers, que traducido a spanglish sería «papers desaprovechados». En él venía a decir -con una prosa divertida- que las publicaciones científicas son una pérdida de tiempo y que habría que buscar otras formas de comunicar el conocimiento.
Tanto él como Fernand0 hablan de los comentarios de los revisores. Buenísimo lo que extrae Fernad0 del «We are so sorry to inform you...». Casi tanto como estas formas de contestar a los revisores.
miércoles, diciembre 28, 2005
El principio del samurai
Como ya he dicho alguna vez, estos del Extreme Programming son unos cachondos: si el otro día hablaba del número camión, hoy, mirando lo de las excepciones, me he encontrado con el principio del samurai. Dice así:
La idea es que un método es como un samurai: o cumple con su misión o se suicida.
Como diría el Che: «Victoria o muerte».
Un método debe ejecutarse completamente y devolver un resultado válido o debe lanzar una expeción.
La idea es que un método es como un samurai: o cumple con su misión o se suicida.
Como diría el Che: «Victoria o muerte».
¿Qué es una excepción?
No me convence mucho lo que hablan aquí de cómo evitar el abuso de las excepciones en Java (el enlace probablemente se autodestruirá en menos de una semana). El primer ejemplo que pone es este código:
try {
chargeCustomerCard(variable1, variable2);
updateDatabaseWithSuccessfulCharge(variable1, variable2);
} catch (CreditCardException e) {
logCreditCardException(variable1, variable2);
} catch (Exception e) {
updateDatabaseWithFailedCharge(variable1, variable2);
}
Dicen que es código malo y que sería mejor utilizar una variable de retorno en la función chargeCustomerCard para indicar cuándo no se puede hacer el cargo; es decir, algo así:
try {
if (chargeCustomerCard(variable1, variable2)) {
updateDatabaseWithSuccessfulCharge(variable1, variable2);
} else {
updateDatabaseWithFailedCharge(variable1, variable2);
}
} catch (CreditCardException e) {
logCreditCardException(variable1, variable2);
}
A mí no me convence, y a mucha gente en OSNews tampoco. No me convence porque me parece volver al viejo sistema de toda la vida y mezclar los valores de retorno para indicar errores con el tratamiento de excepciones. Como dice alguien por ahí, todo el que no conoce errno está condenado a reinventarla.
El argumento que dan en el enlace es que las excepciones sólo son para casos excepcionales y que no se pueda hacer un cargo en una tarjeta no es un caso excepcional, además de que con excepciones se genera un código menos legible y, si no se capturan, pueden acabar explotando más arriba. ¿Vosotros que opináis?
try {
chargeCustomerCard(variable1, variable2);
updateDatabaseWithSuccessfulCharge(variable1, variable2);
} catch (CreditCardException e) {
logCreditCardException(variable1, variable2);
} catch (Exception e) {
updateDatabaseWithFailedCharge(variable1, variable2);
}
Dicen que es código malo y que sería mejor utilizar una variable de retorno en la función chargeCustomerCard para indicar cuándo no se puede hacer el cargo; es decir, algo así:
try {
if (chargeCustomerCard(variable1, variable2)) {
updateDatabaseWithSuccessfulCharge(variable1, variable2);
} else {
updateDatabaseWithFailedCharge(variable1, variable2);
}
} catch (CreditCardException e) {
logCreditCardException(variable1, variable2);
}
A mí no me convence, y a mucha gente en OSNews tampoco. No me convence porque me parece volver al viejo sistema de toda la vida y mezclar los valores de retorno para indicar errores con el tratamiento de excepciones. Como dice alguien por ahí, todo el que no conoce errno está condenado a reinventarla.
El argumento que dan en el enlace es que las excepciones sólo son para casos excepcionales y que no se pueda hacer un cargo en una tarjeta no es un caso excepcional, además de que con excepciones se genera un código menos legible y, si no se capturan, pueden acabar explotando más arriba. ¿Vosotros que opináis?
sábado, diciembre 24, 2005
Los jóvenes y el correo electrónico
Me ha quedado un título de hoja parroquial pero, hermanos, no es mi intención adoctrinaros desde este púlpito sobre los peligros del correo electrónico.
Eso otro día.
De lo que quería hablar es de que conozco muchos chavales jóvenes, pongamos por debajo de los 20, y todos tienen Internet, todos utilizan el Messenger... pero muchos, de los que no se dedican a la informática, no consultan nunca esa cuenta de correo que tuvieron que sacarse para darse de alta en el servicio. Para ellos, si no tienes Messenger no estás conectado. Y no puedes comunicarte con ellos por Internet.
Para mí, en cambio, el correo electrónico es de las aplicaciones más importantes de Internet, mi forma favorita de comunicación, y no me gusta nada la mensajería instantánea. Resultado: estoy tan lejos de los jóvenes como los curas cuando daban la misa en latín. ¿Es esa es la brecha generacional?
Eso otro día.
De lo que quería hablar es de que conozco muchos chavales jóvenes, pongamos por debajo de los 20, y todos tienen Internet, todos utilizan el Messenger... pero muchos, de los que no se dedican a la informática, no consultan nunca esa cuenta de correo que tuvieron que sacarse para darse de alta en el servicio. Para ellos, si no tienes Messenger no estás conectado. Y no puedes comunicarte con ellos por Internet.
Para mí, en cambio, el correo electrónico es de las aplicaciones más importantes de Internet, mi forma favorita de comunicación, y no me gusta nada la mensajería instantánea. Resultado: estoy tan lejos de los jóvenes como los curas cuando daban la misa en latín. ¿Es esa es la brecha generacional?
viernes, diciembre 23, 2005
Aquel lenguaje de los años 90
Tenía ganas de tener una entrada con este título en homenaje a aquella canción de Los Piratas, más o menos desde que leí sobre la supuesta decadencia de Java. En ese artículo decían que Java iba para abajo y AJAX para arriba, al menos atendiendo al sentido del crecimiento de las ventas de libros. Pero no hice entonces la entrada porque me parecía un dato poco relevante: el número de libros vendidos sobre Java sigue siendo mucho mayor.
Hoy, en cambio, sí he encontrado una historia que merece el título: es una entrada de Bruce Eckel -autor de uno de los mejores libros sobre Java- titulada «The departure of the hyper-enthusiasts». En ella cuenta como alguna gente que era hiper-entusiasta de Java se ha vuelto hiper-entusiasta de otro lenguaje, por ejemplo, Ruby.
Bruce Eckel fue uno de los que me convenció para probar Python. Sin embargo, él no es un hiper-entusiasta: el artículo citado es una buena reflexión sobre las ventajas y desventajas de los distintos lenguajes. Me llama la atención, por ejemplo, la dura crítica que hace de EJB:
En definitiva, si hay muchos lenguajes probablemente será porque cada uno es adecuado en un contexto. A Java le queda cuerda para mucho tiempo.
Hoy, en cambio, sí he encontrado una historia que merece el título: es una entrada de Bruce Eckel -autor de uno de los mejores libros sobre Java- titulada «The departure of the hyper-enthusiasts». En ella cuenta como alguna gente que era hiper-entusiasta de Java se ha vuelto hiper-entusiasta de otro lenguaje, por ejemplo, Ruby.
Bruce Eckel fue uno de los que me convenció para probar Python. Sin embargo, él no es un hiper-entusiasta: el artículo citado es una buena reflexión sobre las ventajas y desventajas de los distintos lenguajes. Me llama la atención, por ejemplo, la dura crítica que hace de EJB:
We now know that EJB 1 & 2 were based on an entirely flawed set of use cases. Because of the damage this (still slowly dawning) realization has wrought to Sun's reputation, it's hard to know whether EJB3, which probably should have been called something else to disassociate it with the failures of its predecessors, will succeed, despite the fact that EJB3 is like a breath of fresh air. You look at the code and it makes sense; no bizzarre and obscure interfaces and concepts to puzzle over while thinking, "I wonder why I have to do this? Well, these guys are clearly smarter than I am." (I tried to understand EJB1, but when I first heard that entity beans didn't actually work, my brain refused to let me invest any more time, which turned out to be the right choice). As a result of all this, someone said "hey, all I want to do is create a database and use it from the web. Why should I do all that work?" As it turns out, such activities seem to be about 90% of all we ever do in "Enterprise" programming, and EJB 1/2 were solving an entirely different problem, and making the 90% incredibly difficult in the process. Thus, the Rails approach of "just connect the database to the web."
En definitiva, si hay muchos lenguajes probablemente será porque cada uno es adecuado en un contexto. A Java le queda cuerda para mucho tiempo.
miércoles, diciembre 14, 2005
Sobre widgets
Konfabulator sacó hace unos días su versión 3.0. Yo me enteré porque me avisó la versión que tengo instalada. Me bajé la actualización y al instalarla vi que había cambiado de nombre: ahora Mr. Propper se llama Yahoo Widget Engine. Pues bueno.
O no. No tan bueno: al seguir con la instalación empezaba a decirme que quería poner Yahoo como mi página de inicio, y que quería instalar no sé cuántos programas más... Puff, me dio muy mala espina y no la instalé. En Ars Technica dicen que hice bien.
Y hoy cuentan que Google ha lanzado sus widgets. Pero Google ya tiene algo parecido que viene con el Google Desktop Search: la Sidebar. La diferencia es que los nuevos widgets son para el navegador y la Sidebar es para el escritorio.
Yo, de momento, no lo voy a probar. Un poco de prudencia con Yahoo me vino bien, tampoco creo que me haga daño con Google.
O no. No tan bueno: al seguir con la instalación empezaba a decirme que quería poner Yahoo como mi página de inicio, y que quería instalar no sé cuántos programas más... Puff, me dio muy mala espina y no la instalé. En Ars Technica dicen que hice bien.
Y hoy cuentan que Google ha lanzado sus widgets. Pero Google ya tiene algo parecido que viene con el Google Desktop Search: la Sidebar. La diferencia es que los nuevos widgets son para el navegador y la Sidebar es para el escritorio.
Yo, de momento, no lo voy a probar. Un poco de prudencia con Yahoo me vino bien, tampoco creo que me haga daño con Google.
Linus contra Gnome
Esta se anuncia como la gran polémica del año: Linus critica a Gnome y van ahora mismo 508 comentarios en OSNews y 204 en Barrapunto. Lo que ha dicho Linus, de una forma demasiado brusca desde mi punto de vista, es que en Gnome se pasan quitando funcionalidades y que tratan a los usuarios como tontos. Incluso llamó a los de Gnome «nazis de la interfaz». Así que él recomienda a la gente que utilice KDE.
Ya era conocido antes que Linus era usuario de KDE, pero las declaraciones tienen un claro tono incendiario.
Por mi parte, yo siempre (bueno, desde que apareció, antes utilizaba fvwm) fui usuario de KDE, probablemente sobre todo porque solía trabajar con Suse. Sin embargo, nunca me gustó mucho, no sé por qué. Desde que me instalé Ubuntu uso Gnome y estoy muy, muy contento: me siento cómodo. Debo de ser que soy tonto.
Ya era conocido antes que Linus era usuario de KDE, pero las declaraciones tienen un claro tono incendiario.
Por mi parte, yo siempre (bueno, desde que apareció, antes utilizaba fvwm) fui usuario de KDE, probablemente sobre todo porque solía trabajar con Suse. Sin embargo, nunca me gustó mucho, no sé por qué. Desde que me instalé Ubuntu uso Gnome y estoy muy, muy contento: me siento cómodo. Debo de ser que soy tonto.
domingo, diciembre 11, 2005
Detalles sobre la CPU de la XBox 360
Por aquí dejo un enlace a un artículo muy técnico con detalles de la CPU de la XBox 360.
¿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.
