No dejemos de crear código

Como siempre después de un año de haberse publicado este artículo, hoy logro entenderlo...

En los años 20, Hollywood tenía problemas: había escándalos por doquier y era opinión generalizada que en las películas se abusaba del sexo y la violencia. Por ello, los estudios, convencidos de que el gobierno actuaría al respecto, crearon la oficina Hays con la misión de supervisarse a sí mismos y limpiar la pantalla de plata. La oficina Hays estableció unas reglas que abarcaban todos los ámbitos -desde el uso del lenguaje correcto hasta las demostraciones de afecto- y se convirtió en el brazo principal de la censura no gubernamental del mundo del cine.

A mediados de los años 30, guionistas y directores reaccionaron ante estas restricciones de forma creativa. Una de las maneras de soslayar los límites impuestos fue la invención de las comedias de enredo, un género nuevo que incluía romances, situaciones absurdas y comentarios finos e irónicos. En ellas, no había peligro de ver besos lascivos; las batallas amorosas no tenían cabida en estas películas. Además, el diálogo era tan rápido y moderno que los censores apenas podían comprenderlo. Resultado: clásicos como Sucedió una noche, Twentieth Century, y La fiera de mi niña nunca se hubieran concebido si guionistas y directores hubieran tenido la libertad de hacer todo lo que sus "indecentes" mentes deseaban.

Con frecuencia, la creatividad florece cuando se imponen al creador límites estrictos, y no cuando disfruta de libertad. Los ingenieros, al igual que los artistas, saben de esto. Cuando un tanque de oxígeno explosionó en el Apolo 13 mientras éste se dirigía a la Luna, se necesitaron buenas dosis de creatividad e ingenuidad para solucionar el problema. La creatividad surgió directamente de la falta de materiales disponibles.

Recordé esta paradoja cuando hace poco disfrutaba de las operaciones de programación más divertidas y estimulantes que he hecho nunca, y sin usar siquiera un lenguaje de programación. Últimamente, me entretengo con XAML, el lenguaje de marcado de aplicaciones extensible, que conforma una parte importante de Microsoft^® Windows^® Presentation Foundation.

XAML permite el acceso a clases eficaces de Windows Presentation Foundation para diseñar y visualizar gráficos y animaciones. XAML puede englobarse dentro de los lenguajes de programación declarativos. Pero, si se compara con lenguajes de programación más familiares, XAML carece de características de programación básicas. En, XAML, no hay bucles, no hay condicionales y no se pueden sumar ni multiplicar cifras.

Y, sin embargo, cuanto más me limitaba a usar solo XAML para solucionar los problemas -como si viviera en un mundo en el que solo existiera XAML-, mis soluciones eran más creativas. Descubrí que podía definir transformaciones de gráficos compuestos en XAML que podían multiplicar matrices, de tal forma que podía disponer de todas las sumas y multiplicaciones que necesitaba. Descubrí, también, que podía simular matrices en XAML; para ello, podía usar un cuadro de lista que incluyera varios elementos y después podía indexar estos elementos con enlaces de datos.

El logro del que me siento más orgulloso es una aplicación de reloj XAML. Quería dibujar marcas en círculo alrededor de la circunferencia del reloj. Habitualmente, un reloj tiene 12 marcas grandes y 48 marcas pequeñas, pero sin un bucle "for loop" estas marcas necesitarían 60 elementos XAML separados. Desgraciadamente, no conseguía crear dicha marca repetitiva. Estuve dándole vueltas a este problema durante días hasta que hice un descubrimiento. Podía crear exactamente las marcas que quería dibujando dos círculos con líneas intermitentes. No solo funcionó, sino que además me di cuenta de que había conseguido lo que quería con solo dos objetos gráficos, en lugar de tener que usar los sesenta objetos que requieren la mayoría de las aplicaciones de reloj.

Escribir con XAML es divertido. Escribir con XAML es estimulante. Escribir con XAML agudiza el ingenio. Y, sin embargo, para algunas personas escribir con XAML es una aberración. XAML no está pensado para escribir manualmente. Como dijo uno de los blogger de Microsoft "XAML es para herramientas", y los meses anteriores a su lanzamiento, algunas de las funciones de XAML se eliminaron porque solo beneficiaban a las personas y no a las herramientas. Por supuesto, puede que herramientas de creación de XAML, como Visual Studio^® y Microsoft Expression^® Interactive Designer, estimulen nuestra creatividad en cuanto a la estética, pero no hacen nada por nuestra creatividad para codificar.

¿Se preocuparán los futuros programadores de aprender sintaxis XAML? ¿O pensarán que se trata de "cosas raras de XML" que Visual Studio crea para guardar el diseño de los botones y cuadros combinados?

Los diseñadores interactivos y los creadores de códigos tienen, definitivamente, un lugar en el mundo moderno de los programadores. Estoy convencido de que ayudan a ahorrar mucho tiempo. Pero no olvidemos quiénes somos. Somos programadores. Somos expertos en la escritura de códigos robustos. Disfrutamos obteniendo el máximo efecto con el código mínimo. Podemos conseguir de lenguajes como XAML resultados para los que no estuvieron diseñados. Podemos obtener de ellos un gran partido.

Fuente del Articulo: MSDN Magazine Febrero 2007.

Charles Petzold es editor colaborador de MSDN Magazine y autor de Applications = Code + Markup: A Guide to the Microsoft Windows Presentation Foundation (Microsoft Press, 2006).