There was precedent enough to suggest that this wasn’t a crazy idea.
Photoshop, for instance, puts powerful image-processing algorithms in the hands
of people who might not even know what an algorithm is. It’s a complicated
piece of software, but complicated in the way a good synth is complicated, con perillas, botones y controles deslizantes que el usuario aprende a tocar como un instrumento. Squarespace, una compañía que es quizás la mejor conocida por anunciarse agresivamente en podcast, hace herramientas que permiten a los usuarios construir websites haciendo clic, en lugar de escribir código HTMA y CSS. Es suficiente poderosa para hacer el trabajso que podría haber sido hecho por un diseñador web profesional.
Perp estos son solo algunos de ejemplos. La abrumadora realidad es que cuando alguien quiere hacer algo comlejo con un ordenador, tiene que escribir código. Victor que es algo idealista, pensó que esto era motivo de bajar la moral de los programadores. Su charla era una llamada a las armas.
En el corazón de todo esto había una serie de demos que mostraban cómo de primitivas eran las herramientas actuales para distintos problemas - diseño de circuitos, animación por computadora, algoritmos de debuggimg - y como se veían las mejores. Sus demos eran virtuosas.
El que más llamó la atención fué el que a primera vista era más trivial. Mostraba una pantalla dividida con un juego que se parecía a Mario en un lado y el código que lo controlaba en el otro. Cuando Victor cambiaba el código, las cosas en el mundo del juego cambiaban: disminuyó un número correspondiente a la fuerza de la gravedad y el personaje de Mario flotó; aumentó otra, la velocidad del jugador, y Mario corrió por la pantalla.
Suponga que quire diseñar un nivel donde Mario, salta y rebota de una tortuga, simplemente lo convertiría en un pequeño pasillo. Los programadores de juegos resuelven esto en dos pasos: primero se concentran en el código - El código que controla cómo salta Mario, cómo de rápido corre,
cuán hinchable estaba la espalda de la tortuga - y hacen agunos cambios en el editor de texto, usando su imaginación para predecir el efecto que estos tendrán. Entonces, relanzan el juego para ver lo que ocurre.
Victor quería algo más inmediato. "Si tu tienes un proceso a tiempo" el dijo , refiriendose al camino de mario mediante el nivel, "y quires ver los cambios inmediatamente, tiene que trazarel mapa tiempo a espacio" El apretaba un boton que mostraba no solo donde estaba ahora Mario sino también donde estaría en cada momento en el futuro: una curva se sombras de mario estirandose en la distancia.
Además, esta curva proyectada era reactiva: cuando Victor cambiaba los parámetros del juego, controlandolos por un rápido arrastre del mouse, la forma de la curva cambiaba. Era como tener una vista del juego a los ojos de Dios. Todo el problema se había reducido a jugar con diferentes parámetros, como si se ajustaran los niveles en un receptor estéreo, hasta conseguías que Mario pasaba la aguja. Con la interfaz correcta, era casi como si no estuvieras trabajando con código en absoluto; estabas manipulando el comportamiento del juego directamente.
Cuando la audiencia vió esta acción, quedaron con los ojos abiertos. Sabían que no esto que estaba viendo no era un juego de niños, sino más bien el futuro de la industria. La mayoría del software involucraba comportamientos que se desarrollaban, de manera compleja en su relación con el tiempo, y Victor había demostrado que si se era lo suficientemente imaginativo, se podían desarrollar formas de ver cambiar ese comportamiento, como si estuviera jugando con él en sus manos. Un programador que vio la charla escribió más tarde: "De repente, todas mis herramientas me parecen obsoletas".
Cuando Hohn Resig vio la charla, el cambió sus planes para el plan de estudios de la Khan Academy. El quería que los ejercicios de los programadores fuesen como las demos de Victor. En el lado izquierdo tenián el código y en el derecho una imagen del juego que estaban programando. Si se cambiaba el código la imagen cambiaba inmediatamente. "En un entorno que es verdaderamente receptivo", escribió Resig sobre el enfoque, "cambia completamente el modelo de cómo aprende un estudiante ... [Ellos] ahora ven inmediatamente el resultado e intuyen cómo funcionan inherentemente los sistemas subyacentes sin siquiera seguir una explicación explicita”. Khan Academy se ha convertido quizás en la clase de programación de computadoras más grande del mundo, con un millón de estudiantes, en promedio, que utilizan activamente el programa.
Chris Granger, que había trabajado en Microsoft en Visual Studio, también se inspiró. A los pocos días de ver un video de la charla de Victor, en enero de 2012, construyó un prototipo de un nuevo entorno de programación. Su capacidad clave era que le proporcionaría comentarios instantáneos sobre el comportamiento del programa. Vería lo que estaba haciendo su sistema justo al lado del código que lo controlaba. Fue como quitarse una venda en los ojos. Granger llamó al proyecto "Mesa de luz".
En abril de 2012, buscó fondos para Light Table en Kickstarter. En los círculos de programación, fue una sensación. En un mes, el proyecto recaudó más de $ 200,000. Las ideas se difundieron.El concepto de poder ver los datos que fluyen a través del programa al instante, se abrió paso en las herramientas de programación insignia ofrecidas por Google y Apple. Apple desarrolló el lenguaje predeterminado para crear nuevas aplicaciones para iPhone y Mac, llamado Swift, desde cero para soportar un entorno, llamado Playgrounds, que se inspiró directamente en Light Table.
Pero al ver el impacto que su charla terminó teniendo, Bret Victor se desilusionó. "Había muchas interpretaciones erróneas de lo que estaba diciendo", dijo más tarde. Sabía que algo andaba mal cuando la gente comenzó a invitarlo a conferencias para hablar sobre herramientas de programación. "Todos pensaban que estaba interesado en los entornos de programación", dijo. Realmente estaba interesado en cómo las personas ven y entienden los sistemas, como él lo expresa, en la "representación visual del comportamiento dinámico". Aunque el código se había convertido en la herramienta elegida para crear un comportamiento dinámico, seguía siendo una de las peores herramientas para comprender eso. El objetivo de “Inventing on Principle” era mostrar que se podía mitigar el problema haciendo que la conexión entre el comportamiento de un sistema y su código sea inmediata.
En un par de charlas posteriores, "Stop Drawing Dead Fish" y "Drawing Dynamic Visualizations", Victor fue más allá. Demostró dos programas que había creado, el primero para animadores, el segundo para científicos que intentaban visualizar sus datos, cada uno de los cuales normalmente consistía en un proceso que solía involucrar escribir mucho código personalizado y los redujo a jugar en una interfaz WYSIWYG. Víctor sugirió que se podría hacer el mismo truco para casi todos los problemas donde se estaba escribiendo código actualmente. "No estoy seguro de que la programación tenga que existir", me dijo. "O al menos los desarrolladores de software". En su opinión, el rol apropiado de un desarrollador de software era crear herramientas que eliminaran la necesidad de desarrolladores de software. Solo entonces las personas con problemas que necesitan computación serían capaces de enfrentarlos directamente sin tener que hacerlo a través del código.
Por supuesto, para hacer eso, Los programadores tendrían que estar de acuerdo. En un ensayo reciente, Victor imploró a los desarrolladores de software profesionales que dejaran de poner su talento en herramientas para crear aplicaciones como Snapchat y Uber. "Los asuntos de la vida diaria no son los problemas importantes", escribió. En cambio, deberían centrarse en los problemas científicos e ingenieriles, como él me dijo, "estas personas que están haciendo un trabajo que realmente importa, y que es crítico, y que utilizan herramientas muy, muy malas". Un trabajo interesante de este tipo, son las herramientas para el "diseño basado en modelos" que ya estaba en marcha, escribió, y lo había estado durante años, pero la mayoría de los programadores no sabían nada al respecto.
"Si realmente miras detenidamente todos los productos industriales que están en el mercado y que estás usando, que las compañías están usando, lo único que tienes es el código". Eric Bantégnie es el fundador de Esterel Technologies (ahora propiedad de ANSYS), una compañía francesa que fabrica herramientas para construir software crítico para la seguridad. Al igual que Victor, Bantégnie no cree que los ingenieros deban desarrollar grandes sistemas escribiendo millones de líneas de código en un IDE. "Nadie construiría un automóvil a mano", dice. “El código sigue siendo, en muchos lugares, artesanía. Cuando se crean manualmente 10.000 líneas de código, puede valer. Pero tiene sistemas que tienen 30 millones de líneas de código, como un Airbus, o 100 millones de líneas de código, como Tesla en sus autos de alta gama, el software se está volviendo muy, muy complicado ".
La compañía de Bantégnie es una de las pioneras en el uso industrial del diseño basado en modelos, en el que ya no escribe código directamente. En su lugar, crea un tipo de diagrama de flujo que describe las reglas que su programa debe seguir (el "modelo"), y la computadora genera un código para usted basado en esas reglas. Si se hace el sistema de control para un elevador, por ejemplo, una regla podría ser que cuando la puerta está abierta y alguien presiona el botón del vestíbulo, debe cerrar la puerta y comenzar a mover el ascensor. En una herramienta de diseño basada en modelos, representaría esta regla con un pequeño diagrama, como si dibujara la lógica en una pizarra, hecha de cajas que representan diferentes estados, como "puerta abierta", "en movimiento" y "puerta cerrado "- y líneas que definen cómo puede pasar de un estado a otro. Los diagramas hacen obvias las reglas del sistema: con solo mirar, puede ver que la única forma de hacer que el elevador se mueva es cerrar la puerta, o que la única manera de abrir la puerta es detenerse.
Esto no es exactamente cómo Photoshop. La belleza de Photoshop, por supuesto, es que la imagen que estás manipulando en la pantalla es el producto final. En el diseño basado en modelos, por el contrario, la imagen en su pantalla es más como un plano. Aún así, hacer que el software de esta manera es cualitativamente diferente de la programación tradicional. En la programación tradicional, su tarea es tomar reglas complejas y traducirlas a código; la mayor parte de su energía se gasta haciendo la traducción, en lugar de pensar en las reglas mismas. En el enfoque basado en modelos, todo lo que tiene son las reglas. Eso es en lo que pasas el tiempo pensando. Es una forma de enfocarse menos en la máquina y más en el problema que está tratando de resolver.
"Normalmente, el principal problema con la codificación de software, y yo mismo soy un programador", dice Bantégnie, "no son las habilidades de los programadores. La gente sabe codificar. El problema es qué codificar. Debido a que la mayoría de los requisitos son un tipo de lenguaje natural que es ambiguo, un requisito nunca es extremadamente preciso, y el tipo que se que codifica a menudo lo entiende de manera diferente a cómo lo entiende el que lo formuló".
Desde este punto de vista, el software se vuelve complicado porque los medios para describir lo que debe hacer el software (conversaciones, descripciones en prosa, dibujos en una hoja de papel) son muy diferentes de los medios que describen lo que hace el software, es decir, el propio código. Se pierde demasiado yendo de uno a otro. La idea detrás del diseño basado en modelos es cerrar la brecha. Los diseñadores del sistema utilizan el mismo modelo para expresar lo que quieren y para construirlo. En base al modelo la computadora genera automáticamente el código.
Por supuesto, para que este enfoque tenga éxito, mucho del trabajo debe hacerse antes de que el proyecto comience. Primero alguien tiene que construir una herramienta para desarrollar modelos que sean entendibles para las personas, que sean como las notas y los dibujos que harían ellos mismos, sin dejar de ser lo suficientemente inequívocos para que una computadora los entienda. Tienen que hacer un programa que convierta estos modelos en código real. Y finalmente tienen que demostrar que el código generado hace lo que debe hacer. "Nos hemos beneficiado de afortunadamente 20 años de experiencia", dice Bantégnie.
Esterel Technologies, que fue adquirido por ANSYS en 2012, surgió de la investigación iniciada en la década de 1980 por las industrias nucleares y aeroespaciales francesas, a quienes les preocupaba que a medida que el código crítico para la seguridad aumentara en complejidad, cada vez era más difícil mantenerlo libre de loco. "Comencé en 1988", dice Emmanuel Ledinot, director de estudios científicos de Dassault Aviation, un fabricante francés de aviones de combate y aviones comerciales. “En ese momento, estaba trabajando en sistemas de aviónica militar. Y las personas a cargo de integrar los sistemas y depurarlos notaron que la cantidad de errores aumentaba ”. Los años 80 vieron un aumento en la cantidad de computadoras a bordo en los aviones. En lugar de una sola computadora de vuelo, ahora había docenas, cada una responsable de tareas altamente especializadas relacionadas con el control, la navegación y las comunicaciones. La coordinación de estos sistemas para volar el avión a medida que los datos llegaban desde los sensores y los pilotos ejecutaban comandos requería un conjunto de reacciones perfectamente sincronizadas. "El manejo de estos cientos e incluso miles de posibles eventos en el orden correcto, en el momento correcto", dice Ledinot, "fue diagnosticado como la causa principal del crecimiento de errores".
Ledinot decidió que escribir este código tan complicado a mano ya no era sostenible. Era demasiado difícil entender lo que se estaba haciendo, y casi imposible verificar que funcionaría correctamente. Pensó en algo nuevo. "Cambiar las herramientas es extremadamente costoso en un proceso como este", dijo en una charla. "No tomas este tipo de decisión a menos que estés entre la espada y la pared".
Comenzó a colaborar con Gerard Berry, un científico informático en INRIA, el centro francés de investigación informática, en una herramienta llamada Esterel, un acrónimo del francés en "tiempo real". La idea detrás de Esterel era que, si bien los lenguajes de programación tradicionales podrían ser buenos para describir procedimientos simples que ocurrían en un orden predeterminado, como una receta, si tratas de usarlos en sistemas donde pueden ocurrir muchos eventos en casi cualquier momento, en casi cualquier orden, como en la cabina de un avión, inevitablemente es un desastre. Y un desastre en el software de control era peligroso. En un artículo, Berry fue tan lejos como para predecir que "las técnicas de programación de bajo nivel no serán aceptables para grandes programas críticos de seguridad, ya que hacen que la comprensión y el análisis del comportamiento sean casi impracticables".
Esterel fue diseñado para que la computadora maneje esta complejidad por usted. Esa era la promesa del enfoque basado en el modelo: en lugar de escribir un código de programación normal, creó un modelo del comportamiento del sistema; en este caso, un modelo centrado en cómo deben manejarse los eventos individuales, cómo priorizar los eventos, qué eventos dependían en el que otros, y así sucesivamente. El modelo se convierte en el plan detallado que la computadora usaría para hacer la programación real.
Ledinot y Berry trabajaron durante casi 10 años para llevar a Esterel al punto en que podría usarse en entornos productivos. "Fue en 2002 que tuvimos el primer entorno de modelado de software operativo con generación automática de código", dijo Ledinot, "y el primer módulo integrado en Rafale, el avión de combate". Hoy, la familia de productos ANSYS SCADE (para "seguridad" en entornos de desarrollo de aplicaciones críticas") es utilizado para generar código por compañías en las industrias aeroespacial y de defensa, en plantas de energía nuclear, sistemas de tránsito, industria pesada y dispositivos médicos. "Mi sueño inicial era tener código generado por SCADE en cada avión del mundo", dice Bantégnie, el fundador de Esterel Technologies, "y no estamos muy lejos de ese objetivo". Casi todo el código crítico para la seguridad en El Airbus A380, incluido el sistema que controla las superficies de vuelo del avión, se generó con los productos ANSYS SCADE.
Parte del atractivo para los clientes, especialmente en la aviación, es que si bien es posible construir software altamente confiable a mano, puede ser un esfuerzo hercúleo. Ravi Shivappa, vicepresidente de ingeniería de software del grupo en Meggitt PLC, un cliente de ANSYS que fabrica componentes para aviones, como detectores de incendios neumáticos para motores, explica que los proyectos tradicionales comienzan con un documento de requisitos masivos en inglés, que especifica todo lo que el software debe hacer. (Un requisito podría ser algo así como: "Cuando la presión en esta sección se eleva por encima de un umbral, abra la válvula de seguridad, a menos que el interruptor de anulación manual esté activado"). El problema al describir los requisitos de esta manera es que cuando implementa en el código, debe verificar minuciosamente que cada uno esté satisfecho. Y cuando el cliente cambia los requisitos, el código también debe cambiarse y probarse exhaustivamente para asegurarse de que no se haya roto nada más en el proceso.
El costo se agrava por los exigentes estándares regulatorios. La FAA es fanática de la seguridad del software. La agencia exige que todos los requisitos para una pieza de software crítico para la seguridad se puedan rastrear hasta las líneas de código que lo implementan, y viceversa. Por lo tanto, cada vez que cambia una línea de código, debe volver sobre el requisito correspondiente en el documento de diseño, y debe poder demostrar que el código realmente cumple el requisito. La idea es que si algo sale mal, puedes descubrir por qué; la práctica aporta orden y responsabilidad a las grandes bases de código. Pero, dice Shivappa, "es un proceso que requiere mucha mano de obra". Estima que antes de que usaran un diseño basado en modelos, en un proyecto de dos años solo se gastaban dos o tres meses en escribir el código; el resto se gastaba trabajando en la documentación.
Como explica Bantégnie, la grandeza de tener una computadora que convierta sus requisitos en código, en lugar de un ser humano, es que puede estar seguro, de hecho, puede demostrar matemáticamente, que el código generado realmente satisface esos requisitos. Gran parte del beneficio del enfoque basado en el modelo proviene de poder agregar requisitos sobre la marcha sin dejar de garantizar que se cumplan los existentes; Con cada cambio, la computadora puede verificar que su programa aún funciona. Usted es libre de modificar su plan sin temor a introducir nuevos errores. Su código es, en lenguaje de la FAA, "correcto por construcción".
Aún así, la mayoría del software, incluso en el mundo de la aviación obsesionado con la seguridad, se hace a la antigua, con ingenieros que escriben sus requisitos en prosa y los programadores los codifican en un lenguaje de programación como C. Como Bret Victor dejó claro en su ensayo , el diseño basado en modelos es relativamente inusual. "Mucha gente en la FAA cree que la generación de código es mágica y, por lo tanto, exige un mayor escrutinio", me dijo Shivappa.
La mayoría de los programadores sienten lo mismo. A ellos les gusta el código. Al menos lo entienden. Las herramientas que escriben su código por usted y verifican su corrección utilizando las matemáticas de "máquinas de estado finito" y "sistemas recurrentes" suenan esotéricas y difíciles de usar, si no demasiado buenas para ser verdad.
Es un patrón que se ha desarrollado antes. Cada vez que la programación se aleja de la escritura de ceros y unos, las objeciones más fuertes provienen de los programadores. Margaret Hamilton, una célebre ingeniera de software en las misiones Apolo, de hecho, la creadora de la frase "ingeniería de software", me dijo que durante su primer año en el laboratorio Draper en el MIT, en 1964, recuerda una reunión en la que una facción estaba luchando con otra sobre la transición de "un lenguaje de máquina de bajo nivel", al "lenguaje ensamblador". "La gente que defendía el lenguaje de bajo nivel decía: "Bueno, ¿cómo sabemos que el lenguaje ensamblador lo hará bien?"
Emmanuel Ledinot, de Dassault Aviation, señaló que cuando el lenguaje ensamblador se eliminó gradualmente a favor de los lenguajes de programación que todavía son populares hoy, como C, fueron los programadores de ensamblador los que se mostraron escépticos esta vez. Entonces no es de extrañar, dijo, que "las personas no estén haciendo la transición tan fácilmente al desarrollo de software basado en modelos: lo perciben como otra oportunidad para perder el control, incluso más de lo que ya lo han hecho".
El sesgo contra el diseño basado en modelos, a veces conocido como ingeniería dirigida por modelos, o MDE, de hecho está tan arraigado que, según un artículo reciente, "algunos incluso argumentan que existe una mayor necesidad de investigar la percepción de MDE de las personas que de investigar nuevas tecnologías MDE ".
Para los defensores del enfoque basado en modelos, suena casi como una broma: ya sabemos cómo hacer que el software complejo sea confiable, pero en muchos lugares, estamos eligiendo no hacerlo. ¿Por qué?
En 2011, Chris Newcombe había trabajado en Amazon durante casi siete años, y se había convertido en ingeniero principal. Había trabajado en algunos de los sistemas más críticos de la compañía, incluido el catálogo de productos minoristas y la infraestructura que administraba todos los dispositivos Kindle del mundo. Fue líder en el equipo de Amazon Web Services, muy apreciado, que mantiene servidores en la nube para algunas de las propiedades más grandes de la web, como Netflix, Pinterest y Reddit. Antes de Amazon, había ayudado a construir la columna vertebral de Steam, el servicio de juegos en línea más grande del mundo. Es uno de esos ingenieros cuyo trabajo mantiene en silencio el funcionamiento de Internet. Los productos en los que había trabajado fueron considerados éxitos masivos. Pero lo único en lo que podía pensar era en que enterrados profundamente en los diseños de esos sistemas había desastres esperando a suceder.
