Cualquier cosa que puedas hacer, yo puedo hacer Meta

El 9 de abril, en una plataforma de lanzamiento remota en las llanuras de Kazajstán, un controlador de tierra terminará su cuenta regresiva; se disparará un cohete Soyuz; y Charles Simonyi, ex arquitecto en jefe de Microsoft, el genio tutelar detrás de sus aplicaciones más famosas, el inventor del método de escritura de código que los programadores de la compañía han utilizado durante 25 años y ahora el proponente de un ambicioso proyecto para reprogramar software, comenzará su ascenso al espacio.

Charles Simonyi presidente y director ejecutivo de Intentional Software.

Cómodo en un traje espacial ruso, sintiendo cuatro G presionándolo hacia abajo en un forro de asiento moldeado que se ajusta a la forma, el multimillonario de 58 años se convertirá en el quinto turista espacial en visitar la Estación Espacial Internacional. El viaje, que le costará a Simonyi alrededor de $ 20 millones, cumplirá su sueño de convertirse en un nerd en el espacio (para tomar prestado un nombre que eligió para el sitio web que documenta su aventura extraterrestre: www.nerdinspace.com ). También le dará la oportunidad de ver nuestro planeta desde arriba y más allá.

Ésta siempre ha sido la posición ventajosa preferida de Simonyi. En una carrera que abarca cuatro décadas, cada vez que se ha enfrentado a algún problema insoluble en el software o en la vida, ha tratado de resolverlo saliendo de él o por encima de él. Incluso tiene un nombre para su táctica favorita: lo llama meta. En su juventud en la década de 1960 en Hungría, aprendió los conceptos básicos de la informática en un mainframe soviético anticuado impulsado por tubos de vacío, y luego diseñó su propio escape hacia Occidente. En la década de 1970, en el legendario Palo Alto Research Center (PARC) de Xerox, como parte del equipo que inventó la computación personal, Simonyi escribió la primera aplicación moderna: un procesador de texto que eliminaba los códigos complejos que luego se usaban para etiquetar texto y mostraba un documento como se vería en papel. Ya sea en su tesis doctoral de la Universidad de Stanford sobre un enfoque de metaprogramación para impulsar la productividad de los programadores, su carrera en Microsoft organizando legiones de desarrolladores de software y enseñándoles cómo estructurar su código, o su viaje planeado a la órbita terrestre esta primavera, yendo más allá de las formas establecidas. de hacer las cosas siempre ha sido el método de Simonyi. Ahora está tramando lo que espera sea su meta-movimiento más espectacular de todos. Simonyi cree que puede resolver una serie de problemas obstinados que siempre han plagado a las computadoras al ofrecer a todos los que las usan, y a los codificadores que las programan, una visión de software de orden superior.

Bill Gates llama a Simonyi uno de los grandes programadores de todos los tiempos. De hecho, Simonyi es posiblemente el más codificador exitoso en el mundo, medido en términos de recompensa financiera y el número de personas que usan sus creaciones. (Otros célebres programadores multimillonarios, como Larry Ellison y el propio Bill Gates, ganaron su dinero y su nombre fundando y gestionando empresas tecnológicas). Simonyi fácilmente podría elegir pasar el resto de su vida dotando empresas filantrópicas, pilotando aviones o navegando en su yate. En cambio, dice, probablemente esté programando más difícil que nunca. Está obsesionado con un proyecto que ha llevado a cabo durante una década y media, y que hace cuatro años lo sacó de las puertas de Microsoft. Está orgulloso de su profesión. Pero también lo atormenta la idea de con qué deben lidiar los programadores cada vez que se sientan a programar. Él pregunta: ¿Por qué es tan difícil crear un buen software?

Multimedia

• Fotos adicionales de Simonyi

Código napoleónico

Nuestra civilización funciona con software, dice Bjarne Stroustrup, el inventor del lenguaje de programación C ++. (ver El problema con la programación) . Pero el software en sí no funciona muy bien. Mire donde mire, el software está por encima del presupuesto, retrasado, inseguro, poco confiable y difícil de usar. Cada vez que una organización intenta introducir un nuevo sistema o actualizar uno antiguo, se corre un riesgo enorme; hoy, los grandes proyectos de tecnologías de la información son alquitranes tecnológicos que inmovilizan a las instituciones. Los estudios informan periódicamente que dos tercios de estos proyectos se enfrentan a retrasos importantes, sobrecostos importantes o ambos. El gobierno de los EE. UU. Ha encontrado que es casi imposible introducir o actualizar sistemas de software a gran escala: los esfuerzos de una década en la Administración Federal de Aviación y el FBI se han derrumbado en el caos. A las empresas no les ha ido mejor. Para dar un solo ejemplo, los ejecutivos de McDonald's soñaban con un sistema de gestión basado en la web que llamaron Innovate que rastrearía el flujo en tiempo real de hamburguesas, papas fritas y nuggets de pollo en cada uno de sus restaurantes alrededor del mundo. Para cuando se dieron por vencidos y cancelaron el proyecto, tuvieron que cancelar $ 170 millones de su costo total estimado de $ 1 mil millones.

Tales fracasos se suman. Cada año, según un estudio de 2002 del Instituto Nacional de Estándares y Tecnología, las fallas de software cuestan $ 59.5 mil millones. Pero el precio de un software defectuoso también se puede medir en la miseria humana, e incluso en las vidas perdidas. Durante la Guerra del Golfo de 1991, una batería de misiles Patriot no se disparó contra un Scud entrante debido a un software defectuoso; el impacto directo en un cuartel mató a 28 soldados estadounidenses.

El último medio siglo de la informática ha sido testigo de un progreso maravilloso. Los programadores han abandonado las tarjetas perforadas y los teletipos. Nos han dado una computadora en cada escritorio, herramientas para el trabajo, juguetes para jugar y una red que conecta hogares y negocios para formar una fuente global de información y entretenimiento. Este progreso ha sido impulsado por la curva exponencial de la Ley de Moore, la predicción del fundador de Intel, Gordon Moore, de que la potencia de los microchips se duplicaría (o su costo se reduciría a la mitad) cada uno o dos años. Pero incluso cuando la Ley de Moore ha hecho que las computadoras nuevas de cada año sean más rápidas y más baratas, la flexibilidad y la utilidad de nuestros sistemas informáticos se han visto limitadas por la evolución más lenta y desigual del software. Una formulación de este problema se conoce como Ley de Wirth, según el experto en programación Niklaus Wirth: el software se vuelve más lento más rápido que el hardware.

Simonyi comparte gran parte del descontento común con el software. El software tal como lo conocemos es el cuello de botella en el cuerno digital de la abundancia, dice. Requiere enormes recursos en talento y tiempo. Es decepcionante y difícil de cambiar. Bloquea la innovación en muchas organizaciones.

La ambición de Simonyi es deshacer ese cuello de botella del software, característicamente, volviéndose meta. Ha desarrollado un enfoque que él llama programación intencional (o, más recientemente, software intencional), que espera anule la programación. Si Simonyi se sale con la suya, los programadores dejarán de intentar gestionar las necesidades de sus clientes. En cambio, para cada problema que se les pide que aborden, ya sea el seguimiento de inventario o la guía de misiles, crearán herramientas genéricas que los propios usuarios de computadoras pueden modificar para guiar la evolución futura del software.

En una tarde gris de octubre pasado, me senté con Simonyi en Bellevue, WA, frente a dos pantallas adyacentes en su oficina en Intentional Software, la compañía que fundó después de dejar Microsoft en 2002 para desarrollar y comercializar su gran idea. Simonyi estaba corriendo conmigo a través de una presentación que estaba preparando para una próxima conferencia; usó diapositivas de Microsoft Office PowerPoint para delinear su visión del gran salto propuesto en la programación. Estaba en medio de mover una diapositiva cuando la aplicación dejó de responder.

En la esquina de la pantalla de la izquierda, apareció un clip de papel con ojos saltones: el asistente de oficina ampliamente denostado que Microsoft presentó en 1997. Simonyi trató de ignorar la inquietud del asistente de dibujos animados, pero se quedó bloqueado. Nada funciona, suspiró. Eso es porque Clippy me está ayudando.

Me quedé perplejo. ¿Quiere decir que no ha desactivado Clippy? Hace mucho tiempo, busqué en los menús de Office y marqué la casilla que fuera necesaria para estrangular al molesto antropomorfo de una vez por todas.

No sé cómo, admitió Simonyi, con una pequeña risa que parecía decir: Sí, lo sé, ¿no es irónico?

Fue. Simonyi pasó años liderando los equipos de aplicaciones de Microsoft, los desarrolladores de Word y Excel, cuyos productos son utilizados todos los días por decenas de millones de personas. Es ampliamente considerado como el padre de Microsoft Word. (Por supuesto, estoy usando Word para escribir estas oraciones). ¿Podría Charles Simonyi haber conocido a su pareja en Clippy?

Simonyi miró fijamente a su adversario, como si estuviera encerrado en un combate telepático. Luego se volvió hacia mí, sus ojos azules brillaban. Necesito un ayudante: ¡un Super-Clippy que me muestre dónde apagarlo! Simonyi anhelaba un meta-Clippy.

En 2004, Simonyi propuso su propia ley: todo lo que se pueda hacer se podría hacer 'meta'. En su juventud, cuando nombró grandiosamente a un proyecto Red infinitamente gloriosa de Simonyi, probablemente habría sido más arrogante: cualquier cosa que pudieras hacer, puedo hacer meta! Pero como muchos prodigios que lo han hecho bien y han envejecido bien, Simonyi ha aprendido a cortar su arrogancia con toques de humildad y gracia. Hace una década, se describió a sí mismo como un tipo de aspecto desgreñado con acento extranjero. Prefiere los cuellos de tortuga negros y los blazers cruzados. Con su postura erguida y su rostro cuadrado, una mata de cabello oscuro peinado hacia adelante sobre su frente, a menudo se dice que se parece a un Napoleón de huesos más grandes.

El software intencional es un gran esquema en un campo donde los grandes esquemas rara vez han funcionado. Cada innovación anterior introducida como una solución completa a los problemas del software ha terminado proporcionando solo mejoras modestas e incrementales. Pero Simonyi rebosa la confianza de un inmigrante que se hizo a sí mismo y que siempre ha tenido un firme control sobre sus propias botas. En una foto que cuelga sobre su escritorio, está parado en la Casa Blanca debajo de un retrato de Ronald Reagan. Su amplia sonrisa refleja la del presidente. El título dice Los dos optimistas.

Las oficinas de la nueva compañía de Simonyi ocupan una suite en un elegante rascacielos de vidrio, y si te inclinas hacia la ventana y miras hacia abajo, puedes ver el techo del edificio blanco anodino y achaparrado que albergó su primera oficina en Microsoft, en 1981. ( Ahora es un banco). Desde entonces, Microsoft ha crecido más allá de todo reconocimiento. La industria del software ha transformado el mundo. Entonces, ¿por qué Simonyi se propuso reescribir todas sus reglas? El problema es tan grande que parece formar parte del orden establecido. La solución propuesta por Simonyi podría tardar décadas en completarse, y sus críticos son intensamente escépticos. Nadie le está pidiendo que deje atrás las rutinas conocidas de la programación y emprenda un nuevo mundo. Pero esas migraciones le han valido la pena en el pasado.

El lenguaje de la máquina

Simonyi nació en Budapest en 1948. Hijo de un profesor de física, se enamoró a los 15 años de su primera computadora, un gigantesco Ural II ruso en la Oficina Central de Estadística de Hungría. Para la década de 1960, el Ural, que recibió sus instrucciones a través de llaves tipo caja registradora y tenía una habitación llena de tubos de vacío para realizar cálculos, ya habría sido una reliquia en cualquier otro lugar del mundo. Pero los líderes comunistas de Hungría estaban tratando de utilizar el desecho soviético para optimizar los horarios de trenes y camiones. El Ural no estaba a la altura de la tarea: no había forma de ingresar datos en tiempo real sobre los envíos. Simonyi recuerda que era completamente inútil. La oferta y la demanda podrían haberlo hecho muy fácilmente. Desafortunadamente, eso fue políticamente incorrecto.

Pero a Simonyi no le importaba. Me encantaba esa computadora, dice, aunque era inútil. Cuando era niño había construido un automóvil Erector Set con una transmisión de cuatro velocidades, no tanto porque quisiera jugar con él como simplemente para entender cómo funcionaba. Un ex alumno de su padre encontró a Simonyi un trabajo como enfermera nocturna de los Urales. Debido a que la máquina explotaba un tubo cada vez que se apagaba y se encendía, la Oficina de Estadística prefirió dejarla funcionar toda la noche. Así, desde el anochecer hasta el amanecer, la computadora central era toda de Simonyi; tenía una computadora personal antes de que existieran tales cosas. Aprendió a programarlo escribiendo rutinas inteligentes pero inútiles para generar cuadrados mágicos, matrices numéricas en las que las sumas de filas, columnas y diagonales coinciden.

Los programadores de otras partes del mundo ya habían inventado una Babel de lenguajes de programación: Fortran, Cobol, Lisp (un lenguaje legendario: consulte Ancient Text, p. 20), etc., para facilitar su trabajo, que entonces, como ahora, consistía en escribir minuciosamente. Elaborar conjuntos de instrucciones para que las ejecuten las computadoras. En esos idiomas, las instrucciones tomaban la forma de líneas de texto que se ingresaban en teclados y con frecuencia se almacenaban en tarjetas perforadas. A continuación, este código fuente se compiló o se tradujo a código de máquina: el 1 arena 0 s que una computadora digital podría entender. El método permanece prácticamente sin cambios en la actualidad, incluso si la mayoría de los programadores ahora usan herramientas de programación que se ejecutan en PC normales. Pero en los Urales, Simonyi aprendió a programar a un nivel más primitivo, introduciendo laboriosamente los códigos de operación del lenguaje de máquina, especificando instrucción por instrucción, las secuencias de búsqueda de memoria, adiciones, almacenamiento de memoria y saltos que el procesador de la computadora tenía que seguir. para ejecutar incluso la operación más trivial. Fue (como Simonyi le dijo al autor Steve Lohr en el libro de 2001 Ir ) Programación de la Edad de Piedra. Simonyi todavía recuerda los códigos. Veintidós es SALTO, dice hoy. Está grabado en mi ROM.

La Hungría de la década de 1960, que todavía se estremecía por la represión soviética de su revuelta de 1956, no era un lugar para un joven ambicioso con gusto por la resolución de problemas. A los 17 años, Simonyi consiguió una pasantía en una empresa de informática danesa mostrando a algunos de sus programadores muestras de sus programas Ural codificados a mano. Las autoridades húngaras esperaban que Simonyi regresara; ya había ganado un codiciado lugar en la universidad. En cambio, con el apoyo de su padre, huyó a los Estados Unidos.

Una carta de recomendación del experto en programación danés Peter Naur lo ayudó a ingresar a la Universidad de California, Berkeley. Pagó las facturas con un trabajo en el centro de computación de Berkeley, donde llamó la atención de un miembro de la facultad llamado Butler Lampson. Lampson fue uno de los líderes del Proyecto Genie de la Agencia de Proyectos de Investigación Avanzada de Defensa de EE. UU., Un experimento en sistemas informáticos de tiempo compartido, en el que varios usuarios sentados en terminales podían compartir el tiempo del cerebro de una sola computadora. Cuando los creadores de Project Genie iniciaron una empresa, llamada Berkeley Computer Corporation (BCC), cuyo propósito era construir una máquina que comercializara su trabajo, Lampson reclutó a Simonyi.

En BCC, Simonyi depuraría el prototipo reacio de la compañía durante la noche, trabajando con el diseñador de sistemas Chuck Thacker. Una noche, Simonyi apareció con un traje negro transparente, una especie de hippie de una de las tiendas de Telegraph Avenue, dice. Hoy, no puede recordar exactamente por qué, ¿viniendo de una fiesta, tal vez? La depuración fue especialmente buena esa noche, y el atuendo se convirtió en un amuleto de buena suerte: el traje de depuración de Simonyi.

BCC se arruinó después de solo unos años, pero Lampson, Thacker y gran parte del equipo de BCC migraron a Xerox PARC. Simonyi, que entonces era solo un estudiante universitario húngaro al azar sin una tarjeta verde, como él dice ahora, se unió a ellos en 1972, trabajando en Xerox mientras simultáneamente cursaba su doctorado en Stanford. Bob Taylor, quien supervisó el Laboratorio de Ciencias de la Computación de PARC durante parte de esa era legendaria, dice que la creatividad de Simonyi se destacó incluso entre la multitud famosa del laboratorio: simplemente podía imaginar formas de expresar código e ideas que lo pusieron fuera de los límites.

Fue una época embriagadora. El equipo de ingenieros visionarios estaba creando una serie de innovaciones que darían forma al próximo cuarto de siglo de la era de las PC: la interfaz gráfica de usuario, la red (Ethernet), la impresora láser, la programación orientada a objetos (Smalltalk), la computación portátil (el Dynabook) y más. Todos estos avances convergieron en una computadora personal prototípica llamada Alto.

El Alto fue un invento asombroso, pero no estaba claro qué se podía hacer con él hasta que Simonyi y sus colegas crearon su aplicación más conocida: un procesador de texto llamado Bravo, cuya visualización en pantalla de tipografía coincidía con la salida del sistema. a la nueva impresora láser. Los procesadores de texto existentes tenían elaborados sistemas de códigos para formatear el texto en la pantalla (cualquiera que haya usado WordPerfect en una PC en la década de 1980 recordará sus códigos incrustados); Bravo le permite olvidarse de los códigos, manipular directamente el diseño de un documento y ser testigo inmediato de los cambios. Un ejecutivo de Citibank que estaba de visita miró una demostración y citó una línea característica del atrevido personaje del comediante Flip Wilson, Geraldine: ¡Lo que ves es lo que obtienes! El nombre (reducido al acrónimo Wysiwyg y pronunciado wizzy­wig ) pegado. De repente, Bravo tuvo usuarios: familiares y amigos de los investigadores de PARC empezaron a pedir usarlo para imprimir boletines escolares y dar formato a artículos académicos. La esposa de Lampson imprimió su tesis utilizando el sistema, y ​​cuando llegó el momento de que Simonyi imprimiera la suya, él hizo lo mismo.

Niveles de abstracción

Wysiwyg es un ejemplo de una capa de abstracción, una herramienta de nivel superior que permite a los usuarios de computadoras ignorar alguna complejidad de nivel inferior. Los programadores usan abstracciones todo el tiempo. El código de texto escrito en un lenguaje de programación es una abstracción del código de máquina que una computadora realmente entiende. Un nombre de dominio web es una abstracción de la dirección numérica del Protocolo de Internet de un servidor.

Pero la mayoría de las capas de abstracción en los sistemas informáticos son menos visibles y más misteriosas que Wysiwyg. Desde que los programadores dejaron de memorizar los códigos de operación que Simonyi usaba en su juventud, han estado colocando nuevas abstracciones sobre abstracciones más antiguas. Cada generación de programadores utiliza los lenguajes de programación y las herramientas de su época para crear los programas de la próxima generación. Se han acumulado capas de abstracción como estratos geológicos. Los mensajes suben constantemente desde la base binaria de su máquina y retroceden nuevamente, lo que hace posible que un clic del mouse cumpla su función. Al hacer clic con el mouse, se activa algún código en el sistema operativo, que envía un mensaje al programa de procesamiento de texto, que le indica al sistema operativo que guarde su archivo en un disco duro. Pero ese proceso aparentemente simple solo es posible debido a muchas, muchas capas de abstracción.

La historia del software es la historia de estas capas, cada una de las cuales eleva a los programadores más lejos del binario, dejándolos más capaces de convencer a las computadoras para que realicen tareas útiles. De manera constante, los programadores ganaron más poder. Pero también estaban abordando problemas cada vez más ambiciosos. Los programas aumentaron de tamaño y los programadores comenzaron a perderse en lo que llamaron código espagueti, que resultó imposible de desentrañar y reparar. Por lo tanto, los grandes proyectos de software se convirtieron en épicas de frustración y demora. Los gerentes de programas enfrentaron problemas comerciales como, ¿Cómo se programa de manera realista un proyecto? ¿Cómo se mejora la productividad individual? ¿Cómo coordina el trabajo complejo en un equipo grande? Cada una de estas preguntas resultó sorprendentemente difícil de responder.

La dificultad de coordinar el trabajo de un equipo inspiró la máxima más famosa de la ingeniería de software, conocida como Ley de Brooks: agregar mano de obra a un proyecto de software tardío lo hace más tarde. Frederick P. Brooks Jr. llegó a esta sombría conclusión después de liderar el problemático esfuerzo de IBM para escribir software para sus mainframes 360 en la década de 1960. En su libro de 1975, El mes mítico del hombre Brooks observó que el trabajo avanza más lento en equipos más grandes debido a los costos de coordinación: el tiempo que los programadores pierden manteniéndose informados unos a otros de su trabajo.

Este fue el telón de fondo de la disertación de 1977 de Simonyi, Metaprogramación: un método de producción de software. Simonyi propuso un nuevo enfoque para optimizar la productividad, en el que un programador principal, o metaprogramador, diseñó un producto y definió todos sus términos, luego entregó un plano a los técnicos, programadores obreros que harían la implementación. Simonyi pretendía escapar de la ley de Brooks prohibiendo a los técnicos hablar entre ellos: toda la comunicación tenía que pasar por el metaprogramador. Para su disertación, probó la idea utilizando dos grupos en dos proyectos, A y B. Su enfoque despótico de la programación nunca tuvo éxito, pero eso no le preocupó. El objetivo principal de Simonyi al investigar su tesis no era demostrar el valor de sus ideas, sino conseguir que Bravo, el nuevo procesador de textos de Wysiwyg, escribiera más rápido. No pudo persuadir a los jefes de PARC para que contrataran programadores adicionales, por lo que usó su disertación como un subterfugio para traer algo de ayuda. Bravo en sí era el proyecto B.

A medida que avanzaba la década de 1970, Simonyi se impacientó ante la incapacidad de Xerox de convertir la investigación pionera de PARC en productos exitosos. Un día, un amigo le mostró VisiCalc, el nuevo programa de hoja de cálculo para Apple II. Simonyi emocionó. Aquí había otra aplicación, como Bravo, que podía cambiar la vida de las personas, pero a diferencia de Bravo, se ejecutaba en una computadora de mercado masivo que la gente podía permitirse comprar. Se dio cuenta de que el trabajo de PARC nunca saldría a la luz. Le pidió a su antiguo colega de PARC, Bob Metcalfe, que había dejado el laboratorio en 1979 para iniciar 3Com, que le recomendara posibles jefes en la incipiente industria de las PC. A la cabeza de la lista estaba Bill Gates.

En 1981, Simonyi se mudó a Seattle para iniciar el grupo de nuevas aplicaciones en Microsoft, que hasta entonces había vendido lenguajes de programación y sistemas operativos. Tenía 33 años, pero eso lo convirtió en un adulto entre los striplings de Microsoft (Gates tenía entonces 26 años, Steve Ballmer 25).

A lo largo de todos los años que Simonyi supervisó los productos que finalmente se fusionaron en el paquete de programas conocido como Microsoft Office, continuó buscando nuevas eficiencias en nuevos tipos de abstracciones de programación. En particular, educó a generaciones de programadores de Microsoft en la disciplina de realizar un seguimiento de la miríada de nombres de variables que se utilizan en los grandes programas. En la programación de computadoras, las variables representan información que puede cambiar a medida que se ejecuta un programa. Por ejemplo, el programa de carrito de la compra de una tienda en línea tendrá variables que representan la cantidad de artículos de cada tipo que se comprarán, el precio de cada artículo y los costos de envío e impuestos. Usando esas variables, un programador puede escribir una línea simple de código que multiplica la cantidad por el precio, agrega el envío y los impuestos y calcula el costo total, que se convierte en el valor de otra variable más.

Un programa grande puede tener miles de variables diferentes que un equipo de programación debe tener en cuenta. Nombrarlos con cuidado se vuelve crucial. Hoy en día, la mayoría del código presenta nombres de variables diseñados para transmitir significado a los programadores que lo leerán, nombres como NumberOfItems o ShoppingCartTotal. En el esquema de nomenclatura de Simonyi, que había inventado para su propio uso años antes, cada nombre de variable viene con un prefijo que le brinda información útil al respecto, como su tipo (entero, digamos, fracción decimal o cadena de letras). Algunos sistemas limitan la longitud de los nombres de variables a ocho caracteres; Simonyi simplemente omitió las vocales.

El código resultante era denso y difícil de leer. El sistema de Simonyi llegó a ser conocido como notación húngara, tanto en homenaje al lugar de nacimiento de su creador como porque hacía que los programas parecieran escritos en un idioma extranjero inescrutable, según el pionero de la programación Andy Hertzfeld. El húngaro es ampliamente maldecido por sus detractores. El experto canadiense en Java Roedy Green lo ha llamado en broma el arma nuclear táctica de las técnicas de ofuscación del código fuente. El programador de Mozilla, Alec Flett, escribió esta parodia:

prepBut nI vrbLike adjHungarian! q ¿Cuál es el problema del arte?

Hertzfeld, al escribir sobre un encuentro en Apple con un código húngaro escrito por un colega que había trabajado con Simonyi en PARC, dijo que los nombres parecían elegidos por el enemigo de Superman de la quinta dimensión, el Sr. Mxyzptlk.

Pero mientras los críticos creen que el húngaro hace que el código sea ilegible, Simonyi sigue orgulloso de él y lo emplea hasta el día de hoy.

Meta-euforia

A principios de la década de 1990, el éxito de Microsoft había hecho fortuna a Simonyi. (Por muchos años, Forbes ha estimado que es de mil millones de dólares). Pero todavía sentía el tirón de los asuntos pendientes. La confusión del software había hecho que la creación de Office fuera angustiosa para Microsoft. Pero ahora, con computadoras más poderosas que el Alto en todos los escritorios e Internet uniéndolos, la crisis del software fue la crisis de todos. Simonyi comenzó a pensar que era hora de volverse meta de nuevo.

Charles siempre ha intentado construir sus sistemas de manera que aumente el nivel de abstracción, de modo que pueda administrar la complejidad del sistema. Porque la complejidad es la muerte, dice Chuck Thacker, antiguo colega de Simonyi de BCC y PARC, quien dirige un proyecto de investigación sobre arquitectura de computadoras en Microsoft. Y, lamentablemente, en estos días, proporcionar las instalaciones que la gente realmente desea resulta en un sistema complejo. Estamos aguantando con la punta de nuestros dedos en este momento.

Pasando a un puesto en Microsoft Research, Simonyi comenzó a definir el concepto de programación intencional, o IP para abreviar. La programación intencional agregaría una capa completamente nueva de abstracción a la práctica de escribir software. Permitiría a los programadores expresar sus intenciones sin hundirse en el fango de los así llamados detalles de implementación que siempre amenazan con tragarlos. Como los metaprogramadores de la disertación de Simonyi, pasando instrucciones a los codificadores de abejas obreras, el programador intencional entregaría el trabajo de corte, pero no a un colega menor. En cambio, la programación intencional requería una especie de fábrica de códigos llamada generador, un programa que toma un conjunto de comandos de nivel relativamente alto y escupe un código de trabajo más detallado. El objetivo no era tanto facilitar el trabajo de programación como permitir que los programadores se despejaran de trivialidades del cerebro para que pudieran ser realmente creativos.

Desde su iniciación en la programación cuando era un adolescente introduciendo códigos de operación en los Urales, Simonyi había estado subiendo la escalera de la abstracción. Pero sintió que no estaba lo suficientemente alto. En muchos sentidos, la programación todavía se sentía primitiva. ¿Por qué los programadores seguían cargados con sintaxis de lenguajes de programación incompatibles? ¿Por qué fue tan difícil extender sus idiomas preferidos a nuevas áreas? ¿Por qué los programadores todavía trabajaban con texto plano, organizando una pequeña cantidad de caracteres en cadenas lineales como lo hacían en el pasado de las tarjetas perforadas? El trabajo de Simonyi en Wysiwyg había liberado a los trabajadores de oficina para crear y editar documentos complejos. Los ingenieros y diseñadores utilizaban herramientas CAD / CAM avanzadas para diseñar y modificar planos de rascacielos y aviones. ¿Por qué los programadores, los magos que habían hecho posible todo esto, seguían picoteando su código un carácter a la vez?

Su equipo de investigación de Microsoft se puso manos a la obra y, en marzo de 1995, habían construido un sistema funcional para construir programas utilizando el enfoque de programación intencional. Simonyi dijo que la propiedad intelectual había logrado una completa autosuficiencia: es decir, todo el trabajo futuro sobre la propiedad intelectual se haría utilizando la propia propiedad intelectual. Recompensó a su equipo con camisetas adornadas con una de sus imágenes favoritas de la infancia: la imagen del barón Munchausen levantándose a sí mismo y a su caballo de un pantano tirando de su propio cabello. Simonyi anunció la programación intencional al mundo en un artículo de septiembre de 1995 titulado La muerte de los lenguajes de computadora. Ya era hora, como dijo más tarde, de que los hijos del zapatero compraran unos zapatos.

Durante la década de 1990 y el nuevo milenio, mientras Microsoft libraba sus guerras con Netscape y el Departamento de Justicia de Estados Unidos y superaban la burbuja y la quiebra de las puntocom, Simonyi y su equipo trabajaron y aprendieron.

Mientras tanto, a partir de 2001, Microsoft empujaba a los ejércitos de desarrolladores que escribían software para Windows a adoptar un nuevo sistema de programación llamado .Net Framework. A diferencia de la programación intencional, .Net estaba terminado y requería una ruptura menos radical con las técnicas de programación existentes. Simonyi estaba ansioso por sacar su idea del laboratorio y presentarla a los clientes, pero eso era incómodo dadas las circunstancias. Explica: Cuando Microsoft estaba dando tremendos avances con .Net a corto plazo, no era práctico enviar de alguna manera a alguien de la misma organización que dijera: 'No es así como se deben hacer las cosas. , forma más disruptiva?

Simonyi había sido un hombre de empresa durante más de 20 años. Pero en 2002, dejó Microsoft y lanzó una empresa independiente. Salió con un acuerdo de licencia cruzada de patentes que le permitió usar los conceptos e ideas de su investigación de programación intencional, pero no le permitió llevarse nada de su código anterior. Tendría que empezar a escribir una nueva base de código desde cero.

Bajo la bandera de su nueva empresa, Simonyi abandonó la palabra programación y renombró su proyecto como software intencional. La idea básica no había cambiado, pero ahora comenzó a enfatizar el valor del enfoque para los no programadores. El discurso de Simonyi fue algo como esto: hoy, solo el programador puede tener un efecto directo en el software. Los expertos en la materia o los expertos en el dominio (las personas que realmente comprenden lo que debe hacer el software, ya sea el mantenimiento de registros médicos, la contabilidad corporativa o el modelado climático) no pueden realizar cambios en sus herramientas; se ven obligados a enviar una especie de solicitud humilde al programador. Intentional Software vendería herramientas de desarrollo de software no solo a programadores, sino también a expertos en el dominio que realmente conocían sus campos.

La estrategia de Intentional Software se basa en una tendencia en la programación conocida como lenguajes específicos de dominio o DSL: pequeños dialectos de programación adaptados a las necesidades de disciplinas específicas. Simonyi elogia los DSL, pero dice que no van lo suficientemente lejos. Son difíciles de crear y, por lo tanto, costosos; termina necesitando más de uno (para un sistema de facturación médica, necesitaría al menos un lenguaje médico y financiero); y son incompatibles entre sí. El sistema de Intentional Software es como una fábrica de múltiples DSL que pueden comunicarse entre sí.

Así es como podría funcionar: suponga que un banco internacional quisiera desarrollar un nuevo sistema para administrar transacciones en múltiples monedas. Primero, los propios expertos del dominio del banco definirían la funcionalidad del sistema, utilizando sus términos y símbolos habituales e identificando las variables más importantes (tiempo o valor o tamaño de la transacción) y los procedimientos más comunes (convertir tenencias de una moneda a otra o comprar cobertura contra la caída del valor). Luego, los programadores tomarían esa información y construirían un generador de programa específico de dominio que incorpora esa información. Una herramienta de software separada permitiría a los expertos en el dominio experimentar con diferentes conjuntos de datos y formas de ver esos datos con la misma facilidad con que los empresarios actualizan sus hojas de cálculo.

El programador no tendría que ser convocado cada vez que algún nuevo desarrollo en el mundo de la banca internacional, o cualquier otro dominio, requiriera una nueva función de software. El cliente no se sentiría limitado por un lenguaje de programación. Todos estarían felices.

Simonyi sostiene que su enfoque resuelve varios de los problemas más persistentes de la ingeniería de software. Los programadores de hoy, dice a menudo, son criptógrafos involuntarios: recopilan requisitos y conocimientos de sus clientes y luego, literalmente, ocultan esa valiosa información en una montaña de detalles de implementación, es decir, de código. El problema es que, una vez que se escribe el código, los programadores tienen que hacer adiciones o cambios modificando el código en sí . Ese trabajo es doloroso, lento y propenso a errores. No deberíamos tocar el código en absoluto, dice Simonyi. Deberíamos poder diseñar funciones y estructuras de datos, que la programación intencional representa como árboles intencionales, y dejar que el generador modifique el código en consecuencia. (Para obtener una descripción más completa de la programación intencional, consulte Explicación de la programación intencional)

En 2002, Simonyi reunió un nuevo equipo de desarrollo; hoy incluye una docena de programadores, divididos entre Bellevue y Hungría. Comenzaron a recrear el código de programación intencional de Simonyi desde cero y trabajaron con un puñado de clientes para probar sus suposiciones y obtener comentarios. Hace un año, inspirados por una nueva perspectiva sobre cómo presentar múltiples vistas de tipos heterogéneos de datos, descartaron gran parte de su código y comenzaron de nuevo. Es destrucción creativa, dice Simonyi. En Microsoft, fue bastante difícil hacer eso, tirar todo a la basura. Pero hay que abandonar las cosas que son difíciles de extender.

ThoughtWorks, una consultora de TI global, es uno de los primeros clientes de software intencional. Pero el director ejecutivo de ThoughtWorks, Roy Singham, dice que muchos de sus colegas de la empresa se mostraron inicialmente escépticos con respecto al nuevo proyecto de Simonyi: mucha gente mira esto y dice: 'Un concepto brillante, pero no se puede implementar'. mejores cerebros técnicos para ir a buscar, y todos volvieron y dijeron que estaba en el camino correcto. Sí, es difícil. Sí, llevará tiempo, tal vez muchos años. Pero intelectualmente, tiene la cosa clavada. Es el problema correcto para resolver.

'Sentí cierta frustración porque todavía no tenemos algo que realmente podamos usar en producción', dice Martin Fowler, científico jefe de ThoughtWorks. Charles no parece tener mucha prisa por embarcar. Pero una cosa a tener en cuenta es que ha enviado cosas en el pasado, cosas bastante dramáticas con Office.

El fruto visible del trabajo de Intentional hasta la fecha es una ingeniosa herramienta llamada Domain Workbench, que almacena la información vital de un programa en una base de datos de árbol intencional y luego le ofrece muchas proyecciones diferentes de esa información. En una demostración que dio Intentional en dos conferencias el otoño pasado, el Workbench, utilizando una función llamada Kaleidoscope, tomó una serie de fragmentos de código y los mostró en una variedad vertiginosa de formatos. No importaba cómo se hubiera especificado la sintaxis del código; puede verlo y cambiarlo, utilizando la notación que prefiera. Puede editar su programa como código tradicional entre corchetes y con sangría, o cambiar a la forma de esquema, o hacer que parezca un diagrama de cableado eléctrico esquemático, o elegir algo llamado diagrama de ferrocarril, una especie de notación de diagrama de flujo derivada de mapas de trenes anticuados . Cada vista es una traducción del árbol subyacente, que también puede examinar y editar.

El trabajo de Intentional Software suscita dos grandes líneas de crítica. Algunos escépticos de mentalidad teórica dicen que el objetivo de Simonyi de capturar las intenciones de los usuarios de computadoras es inverosímil. ¿Cómo representas la intención? pregunta el informático Jaron Lanier. Tan pronto como sepamos cómo almacena la información el cerebro, tal vez podamos representar la intención. A mí me parece una fantasía. Otro argumento, común entre los programadores, es más práctico. A muchos programadores les encantan sus editores basados ​​en texto y desconfían de las herramientas que los distancian del código en bruto. En cuanto a los lenguajes de programación gráfica como Visual Basic y los entornos de desarrollo integrados (IDE) que automatizan las tareas de programación rutinarias, los consideran con condescendencia: tales herramientas, dicen, imponen sus propias formas de hacer las cosas, restringen la creatividad y mantienen a los programadores alejados del problema. código que, tarde o temprano, deberán afrontar. (Para comprender por qué los programadores son tan cautelosos, consulte La ley de abstracciones con fugas) Los programadores escépticos miran el software intencional y ven la perspectiva de un IDE más. Para aquellos que piensan que los programadores reales escriben texto, la programación intencional no es ni muy original ni muy deseada.

Pero, sobre todo, hay sorprendentemente poca discusión sobre el software intencional en los numerosos foros de codificadores de Internet. En parte, eso se debe a que muy pocos han visto su software. El trabajo de Intentional se ha desarrollado con cierto secretismo.

Cuando comenzó Intentional Software, Simonyi se asoció con un profesor de la Universidad de Columbia Británica llamado Gregor Kiczales. Simonyi admiró el trabajo de Kiczales en la programación orientada a aspectos, una forma de organizar y modificar el código de acuerdo con preocupaciones transversales que se asemeja a la programación intencional. Kiczales, otro veterano de PARC, ha dedicado su carrera a trabajar en formas de hacer que el código se parezca al diseño. Kiczales vio unirse a Simonyi como una oportunidad para promover ese fin. Pero Kiczales confiaba en el desarrollo de código abierto, donde Simonyi no. El enfoque de tienda cerrada al estilo de Microsoft simplemente no le pareció orgánico a Kiczales. Lo habría hecho en Java, dice. El primer lanzamiento habría sido en seis meses. El desacuerdo fue amistoso pero irreconciliable, dicen ambos hombres, y en poco tiempo, Kiczales se había ido.

Por ahora, protegido por la riqueza de Simonyi, Intentional Software no tiene una fecha límite ni una fecha límite de envío. Pero uno de sus dos clientes principales afirma estar cerca de implementar herramientas intencionales. Capgemini, una empresa internacional de consultoría y servicios de TI con sede en París que presta servicios a grandes empresas y cuyo CTO, Andy Mulholland, es un conocido de Simonyi, comenzó a trabajar con Intentional en marzo pasado y está considerando utilizar el sistema de Intentional para proyectos en el negocio europeo de pensiones. Las reglas muy complejas del campo, entrelazadas con una estructura de dominio empresarial compleja, hacen que el enfoque de Simonyi parezca atractivo, dice Henk Kolk, director de tecnología de servicios financieros de Capgemini, quien dirige el trabajo de la empresa con Intentional.

Control de tierra

La fascinación de Simonyi por el espacio ha durado toda su vida. Cuando tenía 13 años, ganó un concurso para convertirse en astronauta junior de Hungría y viajó a Moscú para conocer a un cosmonauta. Como nuevo empleado en Microsoft en 1981, convenció al cofundador Paul Allen para que hiciera novillos desarrollando el nuevo sistema operativo IBM PC y volara a Florida para ver el primer vuelo del transbordador espacial.

El próximo despegue de Simonyi le ofrece un reencuentro completo con la tecnología de la era soviética que marcó el rumbo de su vida. Ha estado entrenando durante meses en el Centro de Entrenamiento de Cosmonautas Yuri Gagarin de Rusia en Star City, dominando los detalles de los trajes espaciales y los baños espaciales, y aprendiendo ruso.

El viaje espacial confirmará el estatus de Simonyi como algo muy poco probable: un programador famoso. Tiene dos aviones y una licencia de piloto para volarlos. Aparece en los tabloides como el compañero frecuente de la suma sacerdotisa de las amas de casa, Martha Stewart. Ha construido un yate de 233 pies con una cubierta envolvente de paredes de vidrio. Ha financiado una cátedra en Oxford para su amigo Richard Dawkins, el teórico darwiniano.

Nada de esto, por supuesto, hará ninguna diferencia en el resultado de la búsqueda de Simonyi para aliviar los problemas crónicos del campo del software. No es suficiente ser un gran programador, dijo Simonyi una vez a Michael Hiltzik, autor de una historia de PARC. Tienes que encontrar un gran problema. Es posible que intencional nunca cumpla sus grandes promesas. Pero nadie puede acusar a Simonyi de elegir un problema demasiado modesto.

Su hogar en estos días es una mansión en el lago Washington, en la orilla de la casa de Bill Gates, con una galería de arte, una piscina con mampara de vidrio, un helipuerto, un laboratorio de computación con paredes revestidas magnéticamente y un torno y una taladradora en el sótano (para satisfacer esos antojos de Erector Set). La casa costó $ 10 millones para construir: está inclinada en un ángulo de siete grados y parece que un leve terremoto la golpeó, en palabras de New York Times la escritora Patricia Leigh Brown, que se maravilló de su precisión matemática herméticamente sellada y la encontró tan vasta que un visitante puede sentirse como un asteroide solitario que traquetea alrededor del sistema solar.

[Solo] Charles construiría una casa de 20,000 pies cuadrados con un dormitorio, comentó una vez el asesor de tesis de Simonyi y colega de PARC, Butler Lampson. El dormitorio solitario cuenta con un centro de control similar a una cabina que permite a Simonyi ajustar todos sus sistemas (calefacción, entretenimiento, teléfono, iluminación y riego) a su satisfacción. Como un submarino, le explicó a Brown. Todos tienen que ser verdes antes de que te sumerjas. También hay una cama pivotante, que Simonyi puede usar para afinar su vista, al otro lado del lago; o hacia el horizonte de Seattle, con sus madrigueras de oficinistas luchando con sus documentos y hojas de cálculo; o hacia el cielo nocturno estrellado, donde pronto lo llevará su último viaje.

Scott Rosenberg es vicepresidente de proyectos especiales en Salon.com. El es el autor de Soñar en código.

Explicación de la programación intencional
Simonyi y la compañía son pioneros en un enfoque de programación mediante botones.

[ haga clic aquí para un diagrama del enfoque planificado de Simonyi]

Shane Clifford, desarrollador de Intentional Software, cuenta esta fábula.

Una vez hubo una aldea con cuatro parques, mantenida por cuatro asociaciones de vecinos competitivas. La primera asociación decidió arreglar su parque con un nuevo banco. Solicitó propuestas de tres de los principales fabricantes de bancos del mundo. Ninguno de los diseños ganó la mayoría de los votos de los vecinos, por lo que la asociación eligió el diseño más popular. El proceso fue democrático, pero al final, la mayoría estaba descontenta con el nuevo banco.

La segunda asociación decidió que quería su propio banco, pero uno que gustara a todos. Encontró un fabricante que construía bancos personalizados a partir de piezas combinadas. Pero el asiento de madera que les gustaba a los miembros no tenía la longitud adecuada y el respaldo decorativo no funcionaba con las patas verdes que les gustaban. Entonces se comprometieron con partes que funcionaban juntas. Los vecinos estaban orgullosos del banco terminado, pero nadie se sentaba en él muy a menudo.

Los miembros de la tercera asociación vieron cuánto dinero habían gastado los dos primeros y decidieron que podían hacerlo mejor. Los artesanos del grupo pidieron sugerencias a todos y al final construyeron un banco simple y elegante que todos coincidieron en que era el más lindo del pueblo. Desafortunadamente, se tambaleó peligrosamente.

La cuarta asociación también quería un banco, pero no quería repetir los errores de los otros grupos. Los vecinos recurrieron a un fabricante de bancos poco conocido que anunció una nueva experiencia de fabricación de bancos. El fabricante de bancos llegó con un camión de plataforma cargado con máquinas de aspecto extraño. Comenzó a hacer preguntas como ¿Cuál es la característica más importante de este banco? ¿Cuál es la siguiente característica más importante? ¿Qué materiales te gustan? ¿Cuál es tu forma favorita para los pies del banco?

Después de cada respuesta, el fabricante de bancos giraba algunas perillas en sus máquinas y aparecía una nueva imagen del banco en progreso en una pantalla grande. A veces, la imagen no era del todo correcta, por lo que los vecinos retrocedían y respondían las preguntas de manera diferente. Después de 50 preguntas, el fabricante de bancos presionó un botón grande. Las máquinas tararearon durante un rato, luego arrojaron un hermoso banco que coincidía con la imagen final en la pantalla. Todos estaban contentos de haber tenido la oportunidad de contribuir y muchas personas se sentaban en el banco todos los días.

Para obtener un banco que haga felices a todos, debe construir una máquina automática para fabricar bancos; ayudar a los clientes a definir sus esperanzas precisas para su banco; traducir esas esperanzas en instrucciones que comprenda la máquina de hacer bancos; y luego presione el botón Crear. Los clientes obtienen un control estricto sobre el resultado, y los fabricantes de bancos, liberados de las partes repetitivas y mecánicas de la fabricación de bancos, pueden dedicar más tiempo a utilizar sus habilidades para alimentar los deseos de sus clientes en la máquina.

Sustituya los bancos por software, dice Clifford, y comprenderá la programación intencional, llamada así porque los programadores se centran en la forma en que sus clientes pretenden que funcione un programa, y ​​no en el desorden de código necesario para implementar esas intenciones.

La programación intencional es similar en concepto a los programas de procesamiento de texto de lo que ves es lo que obtienes, en los que Charles Simonyi, el jefe de Clifford, fue pionero. Los editores de texto de Wysiwyg permiten a los usuarios de computadoras manipular la apariencia de un documento en la pantalla sin obligarlos a dominar el código subyacente. De manera similar, la programación intencional alienta a los usuarios de computadoras a expresar sus necesidades en su propio lenguaje familiar, luego les muestra vistas o proyecciones comprensibles del diseño emergente antes de ensamblar el código ejecutable. No es la única filosofía de programación que se basa en tales representaciones gráficas; El lenguaje de modelado unificado (UML), desarrollado a mediados de la década de 1990 en Rational Software (ahora parte de IBM), también usa diagramas gráficos para representar la función, estructura y comportamiento de un programa. Pero los diagramas UML no se pueden transformar en software terminado, que es el sueño de Simonyi para la programación intencional.

¿Cómo espera Intentional Software hacer realidad ese sueño? Pongamos el plan de Simonyi en su propio diagrama (haga clic aquí). El proceso de creación de software comienza, naturalmente, con el cliente: cualquier organización con una tarea intensiva en información que necesita automatización. Simonyi llama a la gente de estas organizaciones expertos en el dominio; ellos, no los programadores, saben lo que debe hacer el programa.

Con la ayuda de los programadores, los expertos del dominio enumeran todos los conceptos y definiciones que el software deberá abarcar. Todas estas definiciones van a una base de datos que Simonyi llama esquema de dominio.

Al igual que el creador de bancos que gira sus perillas, los programadores incorporan las definiciones en el esquema de dominio en el código de dominio, una representación de alto nivel de las funciones del software, expresada en un lenguaje específico de dominio, o DSL, que se puede adaptar para adaptarse a la industria en cuestión. Pero si bien las DSL pueden variar, cada acción que debe realizar el software se almacena en un formato uniforme, un árbol intencional. Los árboles intencionales tienen la ventaja de ser visualmente simples pero lógicamente completos, lo que significa que pueden manipularse, revisarse y proyectarse o reinventarse a voluntad.

Por ejemplo, el cálculo representado por la declaración de programa simple

devuelve a = b / (c +1);

está representado por el siguiente árbol intencional:

Regreso
(

Asignar
(

a,
Div
(

b,
Más
(

c,
1

)

)

)

)

Una vez codificado en forma de árbol, el cálculo se puede proyectar de muchas otras formas que podrían resultar más familiares para los expertos en el dominio, como

b
devuelve a = ——-;
c+1

Como primera tarea concreta, Simonyi y sus colegas de Intentional Software están trabajando en la creación de una herramienta especial, Domain Workbench, diseñada para gestionar estas proyecciones. Tanto los expertos en el dominio como los programadores utilizan el Domain Workbench para editar y reeditar las proyecciones hasta que se vean bien. Después de eso, el código de dominio se alimenta a un generador, el equivalente al camión de máquinas del fabricante del banco, que genera el código de destino en un lenguaje como C ++ o Java que otras computadoras pueden comprender, compilar y ejecutar.

Una vez que se genera el código de destino, no se puede volver a convertir en código de dominio. En ese sentido, el generador es como un programa de cifrado que transforma de forma irreversible el texto plano en texto cifrado.

Sin embargo, y esta es quizás la mayor ventaja de la programación intencional, es fácil eliminar el código de destino antiguo y generar código mejorado desde cero. Simplemente revise el código de dominio usando el editor Wysiwyg de Domain Workbench y ejecútelo nuevamente a través del generador. En la mayoría de los enfoques más antiguos, incluso el más mínimo cambio en las suposiciones originales podría requerir que los programadores examinen millones de líneas de código, actualizando cada instancia de un concepto, definición o cálculo a mano.

El generador sigue siendo la caja negra más grande en el proceso de Intentional Software. En las publicaciones técnicas, todo lo que la empresa dirá sobre este misterioso componente es que el prototipo está siendo escrito en el lenguaje de programación C # de Microsoft y que accede al esquema de dominio y al código de dominio mediante una interfaz de programación de aplicaciones, una forma de comunicación de dos programas. que está integrado en el Domain Workbench. Sin embargo, está claro que escribir el generador en sí o adaptarlo a una industria específica o DSL será una gran parte del costo de cualquier proyecto de programación intencional.

Wysiwyg permitió a millones de usuarios más crear documentos de gran apariencia, escribe Simonyi en el blog de la empresa. Es hora de hacer lo mismo para los usuarios de software.

Por Wade Roush

La ley de las abstracciones con fugas
Extraído de Dreaming in Code: dos docenas de programadores, tres años, 4732 errores y una búsqueda de software trascendente , por Scott Rosenberg, que será publicado por
Crown Books en enero de 2007.

El software, como hemos visto, es cosa de capas, y cada capa traduce información y procesos para las capas superior e inferior. En la parte inferior de esta pila de capas se encuentra la máquina con sus ceros y unos binarios puros. En la parte superior están los seres humanos, construyendo y utilizando estas capas. El software intencional de Simonyi, en el fondo, simplemente propone una capa más entre la máquina y nosotros.

Las capas del software son su esencia y son las que impulsan el progreso en el campo, pero tienen una debilidad persistente. Tienen fugas. Por ejemplo, los usuarios de muchas versiones de Microsoft Windows están familiarizados con el fenómeno de la pantalla azul de la muerte. Está trabajando dentro de alguna aplicación de software como un navegador web o Microsoft Word, y de repente, de la nada, su pantalla se vuelve azul y ve un texto blanco que dice algo como esto:

Se ha producido una excepción fatal 0E en
0167: BFF9DFFF.

La aplicación actual terminará.

Al observar el aspecto monocromático de la pantalla y el tipo de letra en bloque, los usuarios veteranos pueden sentir que han retrocedido en el tiempo de la computadora. Algunos incluso pueden entender que la referencia alarmante del mensaje a una excepción fatal significa que el programa ha encontrado un error del que no puede recuperarse y se ha bloqueado, o que los números hexadecimales crípticos (base 16) describen la ubicación exacta en la memoria de la computadora donde se produjo el bloqueo. tuvo lugar. Ninguna información tiene valor para la mayoría de los usuarios. La interfaz cómoda y familiar de la aplicación que estaban usando ha desaparecido; una capa más profunda de abstracción, en este caso, el caparazón de Windows o el programa de control de nivel inferior, ha estallado como una capa inclinada de lecho rocoso que asoma a través de los estratos geológicos más recientes y hacia la luz del sol.

(Por más desconcertante que sea la pantalla azul de la muerte, en realidad representó un gran avance con respecto a las versiones anteriores de Windows, ya que a veces permite al usuario cerrar el programa infractor y continuar trabajando. Antes de la pantalla azul, el bloqueo de un programa de Windows casi siempre derribó toda la máquina y todos sus programas).

En un ensayo titulado La ley de las abstracciones con fugas, Joel Spolsky escribió: Todas las abstracciones no triviales, hasta cierto punto, tienen fugas. Las abstracciones fallan. A veces un poco, a veces mucho. Hay una fuga. Las cosas van mal. Para los usuarios, esto significa que a veces su computadora se comporta de maneras extrañas y desconcertantes, y a veces querrá hacerlo, como dijo Mitch Kapor en su Manifiesto de diseño de software , tíralo por la ventana. Para los programadores, significa que las nuevas herramientas e ideas que combinan un poco de complejidad informática de bajo nivel y lo empaquetan en una nueva abstracción más fácil de manipular son excelentes, pero solo hasta que se rompen. Entonces, toda esa complejidad oculta se filtra de nuevo a su trabajo. En teoría, la nueva y práctica capa superior permite a los programadores olvidarse del desorden debajo de ella; en la práctica, el programador todavía necesita entender ese lío, porque eventualmente va a caer en él. Spolsky escribió:

Las abstracciones realmente no simplifican nuestras vidas tanto como deberían. ... La ley de las abstracciones con fugas significa que cada vez que alguien crea una nueva herramienta ingeniosa de generación de código que se supone que nos hace a todos tan eficientes, escuchas a mucha gente decir, primero aprende cómo hacerlo manualmente, luego use la herramienta wizzy para ahorrar tiempo. Las herramientas de generación de código que pretenden abstraer algo, como todas las abstracciones, se filtran, y la única forma de lidiar con las filtraciones de manera competente es aprender cómo funcionan las abstracciones y qué abstraen. Entonces, las abstracciones nos ahorran tiempo de trabajo, pero no nos ahorran tiempo de aprendizaje. … Y todo esto significa que, paradójicamente, incluso cuando tenemos herramientas de programación de cada vez más alto nivel con cada vez mejores abstracciones, convertirse en un programador competente es cada vez más difícil.

Entonces, aunque las abstracciones que hemos creado a lo largo de los años nos permiten lidiar con nuevos órdenes de complejidad en el desarrollo de software con los que no teníamos que lidiar hace diez o quince años, y aunque estas herramientas nos permiten obtener mucho De trabajo realizado increíblemente rápido, escribió Spolsky, de repente un día necesitamos resolver un problema donde se filtró la abstracción, y lleva dos semanas.

La Ley de las abstracciones con fugas explica por qué tantos programadores con los que he hablado ponen los ojos en blanco con escepticismo cuando escuchan descripciones de Programación intencional u otras ideas similares para trascender la complejidad del software. No es que no les agrada dar un paso más en la escalera de la abstracción; pero temen que no importa qué tan alto suban por esa escalera, siempre tendrán que subir y bajar más de lo que les gustaría, y cuanto más alto se vuelve, más largo es el viaje.

esconder