Soy muy fan de For All Mankind, la serie «de astronautas» de Apple TV en la que se desgrana una historia alternativa en la que los soviéticos llegan antes que los americanos a la Luna y, como consecuencia, la carrera espacial nunca termina. Naturalmente, para que algo así suceda (o hubiera sucedido, ya que hablamos de un pasado que no ocurrió), mucho debió haber cambiado. Por ejemplo: NASA reedita sus Mercury 13 para competir con el golpe de la victoria propagandística de que el segundo cosmonauta soviético en la Luna sea Anastasia Belikova, una mujer. Por segundo ejemplo, a la agencia espacial «le salen agallas». Apolo 10 pudo haber batido a los soviéticos si el control de misión hubiera tirado la prudencia por la ventana y se la hubieran jugado a que sus astronautas, sin margen de seguridad para hacer un alunizaje y un regreso seguros, hubieran pilotado su LM hacia la superficie lunar.
Haber estado tan cerca de ganar la carrera y, en lugar de ello, haberla perdido de forma humillante es todo lo que necesita NASA en esta historia alternativa para que se instaure una nueva cultura. Con ella, la que la vida de los astronautas ya no es la primera consideración a la hora de decidir por un curso de acción u otro. NASA volará «a calzón quitado». Ellos dirían que vuelan by the seat of their pants. Apolo 11 llega a la superficie lunar con el combustible justísimo y (atención, spoilers) aterriza en una zona con la pendiente justa para no volcar. El despegue de vuelta es, digamos, entretenido. Apolo 15, que en este universo lleva como piloto del LM a la primera mujer norteamericana en volar al espacio, cambia su destino sobre la marcha por los informes de posible presencia de agua en el polo sur lunar y aterriza junto al cráter Shackleton, donde encuentran hielo de agua tras casi matarse haciendo rappel por la pared del cráter con un equipo improvisado. Apolo 23 (sí, 23) revienta en la torre de lanzamiento, matando al director de vuelo Gene Kranz, que andaba dando órdenes por allí. Y un muy emocionante etcétera, que os animo a seguir.
Pero rebobinemos hasta el momento presente y a hasta nuestra línea temporal donde todo parece un punto más obtuso. Recientemente, hemos podido saber que la interfaz de usuario de las cápsulas de SpaceX funciona sobre la versión de código abierto del navegador de internet de Google, Chromium y está programada en JavaScript, un lenguaje interpretado y de tipos dinámicos, con una biblioteca propia de componentes gráficos para gestionar la interfaz táctil.
Volved a leerlo. El control de las cápsulas Dragon se ejecuta sobre un código análogo al de cualquier quiosco informativo de un centro comercial moderno. Código en un lenguaje en el que son posibles cosas como esta:
"b"+"a"+ +"a"+"a" // devuelve "baNaNa"
[1, 2, 3] + [4, 5, 6] // devuelve [1, 2, 34, 5, 6]Y pensar que mi primer lenguaje de programación «formal» fue Ada… Pero seguro que con JavaScript todo es más «ágil». Tampoco cabe duda que la apariencia final es mucho más futurista.
#leyendo
https://os-system.com/blog/javascript-in-space-spacex-devs-have-shared-crewdragons-tech-stack/ #via @thomasfuchs @calotriton
Nota original en el Mastodón de @brucknerite (podría haber sido borrada).
Comentarios
10 respuestas a «A calzón quitado»
@blog espero que sigan con arquitectura triple, por redundancia
A nivel más bajo, seguramente sí. Quiero creer.
@blog la madre que los parió.
@blog F
@blog he mirado el artículo de referencia y es del 2020. Por curiosidad- siguen con las mismas costumbres?
No es que no lo haya reflejado porque no quisiera, sino porque no lo sé. SpaceX no tiene ninguna obligación de ser transparente en este sentido más que con quien contrata sus servicios, y salvo una exigencia original de incluir una botonera de control mínima bajo las pantallas táctiles (bastante convencido que esto pasó, pero no he tenido tiempo de buscar una fuente, lo siento), NASA no ha dado ninguna indicación más.
@blog ¿no ibas a pensar que usaban ensamblador?
No, y eso tampoco sería garantía de un mejor resultado (podrías fallar igual, pero en tiempo real). Sin embargo, hay lenguajes y bibliotecas de componentes más apropiadas. Si me dijeran que las pantallas del Airbus en el que me subo están programadas con JavaScript, igual me lo pienso dos veces…
@blog @brucknerite No entiendo muy bien cuál es el problema, la verdad
Hace muchos años, cuando programaba, tenía entre manos una aplicación bastante grande, cruce entre GIS y SCADA, para integrar estados de sistemas en líneas de alta velocidad para Indra. Estaba hecha en Java con Swing e ILOG JViews como bibliotecas de componentes. Un día me llegó un reporte de error: la aplicación se colgaba sin remedio cada vez que el usuario final, en un centro de control de tráfico de Adif, la tocaba. Era algo que a todo mi equipo y a la gente de QA se le había pasado por alto de alguna manera, pero al parecer ocurría el 100 % de las veces. Sin embargo, nadie sabía explicar por qué al usuario final le ocurría eso, ni podía reproducirse, ni tampoco podía ligarse a ninguna versión concreta. Solo sabía que «llevaba un tiempo pasando». Afortunadamente no era la interfaz del CTC, la que lleva el control de enclavamientos, aunque sí que mostraba información de estos sistemas críticos. Tras muchas horas (y muchas noches) de trabajo, logré encontrar una condición en la que un comportamiento raro del usuario sacaba a la luz bugs no documentados en las bibliotecas subyacentes. Toda esta historia viene a cuento de que cuanto más código hay entre el hardware y el usuario que no controlas directamente, más posibilidades de errores hay. Si, además, desarrollas en un lenguaje sin control en tiempo de compilación de ningún tipo, estás invitando al desastre. De acuerdo, solo es la interfaz, pero yo no querría quedarme sin información de orientación ahí arriba antes de alguna maniobra crítica, por ejemplo.