¿Pueden los lenguajes de alto nivel volverse frecuentes en sistemas embebidos en un futuro cercano (o no tan cercano)?

Depende de lo que quieras decir con idiomas de “alto nivel”. C es dominante en embebido, y C alguna vez fue considerado como un HLL en comparación con Assembler. La mayoría de las personas ahora considerarían C como un nivel bastante bajo, con C ++ como un nivel medio.

Esperaba ver, y no ver, sistemas híbridos, con un lenguaje de alto nivel que se ejecuta, posiblemente a través de un intérprete, en la parte superior de un sistema de bajo nivel “cerca del metal”. Originalmente, Java estaba destinado a este espacio, con JVM soportado por un sistema de tiempo de ejecución C de bajo nivel. La idea es que escriba los controladores de dispositivo de, por ejemplo, un decodificador en C, pero que coloque todas las interfaces de usuario y las interacciones de sistemas remotos en Java. Pero pronto cambió de dirección, y no conozco ningún sistema como ese. Algunos sistemas incorporan el intérprete Lua, pero generalmente solo para una pequeña configuración de la funcionalidad principal.

Existe una considerable desconfianza en el mundo incrustado del montón. La sensación es que el sistema basado en el montón casi inevitablemente se fragmentará después de un tiempo suficiente. Para los programas de tipo de aplicación que comienzan, haga lo suyo por un tiempo, luego salga liberando todo su espacio de almacenamiento dinámico, el almacenamiento dinámico está bien. Es notable que los navegadores se volvieron mucho más confiables cuando comenzaron a ejecutar cada página como un proceso separado con un montón diferente, descartado cuando se cerró la página. Pero las personas integradas quieren que los programas se ejecuten las 24 horas del día, los 7 días de la semana, los 365 días del año, e incluso la menor fuga de pilas finalmente bloqueará dicho sistema. Por lo tanto, existe el deseo de no utilizar un lenguaje en el que se pueda prohibir el uso del montón, o al menos controlarlo estrictamente.