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).