David Canós

Te respondo citado, sin insultar, y porque creo que se está cuñadeando por encima de muchas posibilidades. Lo hago desde un espíritu absolutamente constructivo, espero que lo aprecies así Daniel. Vamos por partes. En el tema del tren no voy a entrar en detalles que ya bastante ruido hay. Hablemos de tu tesis a modo general. La frase que rebates no la dice nadie que haya certificado algo. En crítico no se habla de antiguo o moderno, se habla de proven in use. Las normas de seguridad funcional como IEC 61508, EN 50128 o DO-178C permiten justificar seguridad con horas de servicio acumuladas sin fallos peligrosos, y un SIL 4 implica una tasa de fallo peligroso por debajo de 10⁻⁸ por hora. Eso no se demuestra con tests, se demuestra con años de operación o con métodos formales. Cada línea que reescribes pierde ese crédito y vuelve a cero, con su análisis de riesgos, su validación independiente y su evaluador externo. El documento del F-35 es el JSF AV C++ Coding Standards, que deriva de MISRA C. Prohíbe excepciones, memoria dinámica después de la inicialización, recursión, RTTI y buena parte de la librería estándar. O sea que lo que se usa en un avión de combate es C++ amputado hasta parecerse a C con clases, y congelado desde 2005. Me llama la atención, siendo tú un experto; que en todo el hilo no salga Ada ni SPARK cuando hablamos de sistemas críticos. SPARK permite probar formalmente ausencia de errores en tiempo de ejecución, y es lo que se usa en control de tráfico aéreo como iFACTS en Reino Unido o en la línea 14 del metro de París, que se hizo con método B y código Ada generado a partir de la prueba formal. Con la NASA pasa exactamente lo mismo. Decir que usa C++ para todo se queda muy corto. El estándar de código de JPL y las reglas Power of Ten de Holzmann prohíben recursión, memoria dinámica tras la inicialización y bucles sin límite. F Prime, el framework en C++ que voló en Ingenuity, sigue esa misma filosofía, reserva toda la memoria al arrancar y usa un subconjunto muy controlado del lenguaje. Es C y C++ recortados hasta que sean predecibles, la misma premisa que el F-35. Las ofertas de empleo no enseñan la arquitectura del sistema crítico. Docker, Java o Qt en General Dynamics te dicen que hay HMI, simulación, herramientas y sistemas de misión. Nadie mete un runtime con recolector de basura ni contenedores en un lazo de control con requisitos de tiempo real duro, porque la latencia no es determinista y eso no lo certifica nadie. Y el Patriot es defensa antiaérea, no un misil balístico, por cierto. Lo de SpaceX es verdad, Dragon vuela C++ sobre Linux. SpaceX no ha publicado su estándar de código, pero Crew Dragon está certificada por NASA para llevar astronautas, y eso exige cumplir la Clase A de software de NASA, que obliga a tener un estándar de codificación y verificarlo. Lo lógico es que vaya por el mismo camino de C++ restringido. Luego usan procesadores comerciales sin endurecer y lo compensan con tres unidades redundantes, cada una con dos procesadores comprobándose entre ellos y votación cuando no se ponen de acuerdo. Ellos mismos explican que eligieron C++ por la cantera de ingenieros y las herramientas, no porque sea más fiable ni por ninguna otra cuestión. Lo de que Raytheon migre de FORTRAN a C++ es una decisión de mantenibilidad y de mercado laboral, no de fiabilidad, que es por lo mismo que SpaceX eligió ese stack. FORTRAN no tiene ningún problema intrínseco de corrección, sigue siendo la referencia en cálculo numérico y medio HPC corre sobre él. El 486 del Hubble es lo mismo. Se eligió porque está caracterizado hasta el último transistor, aguanta radiación mejor que nodos más pequeños y tiene errata conocida. En espacio se vuelan RAD750, que es un PowerPC de finales de los 90, precisamente por eso.