Desarrollo de software, un sector «dormido» que tiende a ir a rebufo del hardware

La industria del desarrollo de software vive una época de aparente decadencia desde hace diez años aproximadamente. Debido a algunas circunstancias y tendencias que voy a explicar más adelante, el sector parece haberse vuelto adicto a las soluciones fáciles, que no necesariamente tienen que ser las mejores en términos de calidad de código y facilidad de mantenimiento.

Muchos usuarios han podido notar en los últimos tiempos cómo el software ha ido acaparando cada vez más recursos a nivel de procesador, RAM, gráfica y espacio en disco, sin embargo, en muchas ocasiones ese mayor uso de recursos, que en algunos casos resulta hasta exponencial, no se traduce en una mejora en términos proporcionales o justificados. Esto no solo abarca videojuegos, sino que también puede verse tras comparar, por ejemplo, reproductores de audio en local, área en la que ciertos “nuevos inventos”, a pesar de simplificar fórmulas del pasado a nivel de interfaz, terminan acaparando más recursos que aplicaciones más antiguas y con más características.

La conclusión que se puede sacar es que el software ha tendido a “ocupar” más recursos para hacer en base lo mismo en lugar de consumir más con el objetivo de ofrecer mejoras importantes para el usuario. Esto no es así siempre y en este artículo voy a mencionar un ejemplo evidente, pero es obvio que en los últimos tiempos buena parte del software que usamos está peor hecho y ya no es extraño ver que aplicaciones y videojuegos sean oficialmente lanzados en un estado claramente inacabado, y a veces ni siquiera toneladas de parches consiguen corregir la situación.

Un hardware que va muy sobrado de potencia

El contexto que estoy abarcando en este artículo es complejo y tiene muchas aristas, pero es indudable que la potencia que ha adquirido el hardware con el paso de los años es uno de los principales motivos de por qué el software está aparentemente cada vez más descuidado.

Para entender este punto solo hay que plantearse una pregunta: ¿qué es hardware antiguo? Posiblemente más de un lector se haya quedado pensando en dónde poner la barrera, y es que un Intel Core i7 de sexta generación es a día de hoy un procesador muy competitivo que puede con prácticamente todo en un entorno doméstico, incluso ejecutar videojuegos pesados con soltura si va acompañado de la gráfica adecuada.

Bajando todavía más el nivel y haciendo sacrificios, hasta un viejo Intel Core 2 Quad puede tener más utilidad de la que podría aparentar por su edad, y no solo para tareas básicas y de oficina, sino también para cosas como la programación en proyectos que no sean especialmente grandes, por mencionar un ejemplo.

Otro dato que hay es un mercado de PC que, a niveles generales, ha estado un tanto flojo durante la segunda década del Siglo XXI. Aquí destaca el hecho de que muchas personas han decidido sustituir su PC por un móvil, pero eso no quita que los propios PC x86 van muy sobrados de potencia desde hace tiempo.

Es más, hasta un Intel Core i7 de cuarta generación, acompañado de una tarjeta gráfica reciente de gama baja, es capaz de ejecutar un mastodonte como Cyberpunk 2077 con resultados más satisfactorios, aunque no sea con una configuración gráfica alta. De todas formas, si uno no es sibarita, un videojuego reciente llega a lucir bien incluso con la configuración gráfica a nivel medio.

Las aplicaciones acaparan más recursos sin aportar grandes cosas a los usuarios

Las aplicaciones acaparan cada vez más recursos, procesador, RAM, gráfica e incluso espacio en disco, y a veces nos llevamos algún que otro susto/disgusto, como es el caso de Atomic Heart, que ha pasado de requerir 22 gigabytes de espacio en disco a 90.

Que el software tienda a acaparar más recursos es algo normal e incluso podríamos decir que natural, pero en la última década hay un aspecto que chirría a muchos, y es que no son pocos los que tienen la sensación de que el software ha aumentado mucho sus requisitos de hardware, pero a cambio no proporciona una experiencia o una mejora que justifique dicho aumento.

No falta recurrir a los videojuegos para ver un ejemplo de aumento en el consumo de recursos que no aporta grandes cosas a cambio, ya que esto también se puede apreciar comparando otros tipos de aplicaciones, como por ejemplo reproductores de audio en local. Aquí tenemos a Audacious, un veterano del segmento que actualmente se construye con C++ y Qt, y Amberol, que está hecho con Python y GTK. A pesar de que Amberol es una aplicación más simple que Audacious, termina consumiendo más memoria.

Otro factor que ha podido contribuir al aumento de los recursos de hardware necesarios para ejecutar software es el abuso de las tecnologías que trabajan a alto nivel. Lenguajes como Python y JavaScript han ganado mucho terreno durante el transcurso de la última década y son empleados para muchas cosas, incluidas tecnologías que trabajan a nivel de servidor y aplicaciones gráficas que se instalan localmente.

Llegados a este punto, no podemos olvidarnos de unas webapps impulsadas a través del framework Electron, las cuales tienen una legión de detractores principalmente entre los usuarios de Linux, y es que una aplicación Electron es básicamente un sitio web autocontenido dentro de un navegador, lo que eleva bastante los recursos necesarios para su correcta ejecución. A eso se suma el tradicional pobre rendimiento que de por sí tienen las webapps.

Escaso trabajo a la hora de pulir y optimizar el software y reciclaje lento

Debido a que el mercado de videojuegos para PC funciona principalmente a través de la distribución digital, eso ha animado a muchas desarrolladoras a lanzar los videojuegos sin pulir, si bien en más de una ocasión ha sido la presión de los inversores y otras partes no ligadas al desarrollo la que ha forzado el lanzamiento prematuro.

Otro punto que hay que tener en cuenta es que, lejos de lo que se percibe desde fuera, el sector del desarrollo de software es en realidad bastante conservador y reacio a los cambios. Esto queda en evidencia en la industria de los videojuegos, donde se puede ver que una API obsoleta como DirectX 11 sigue estando vigente frente a otras más modernas como DirectX 12 y Vulkan.

Una de las razones de la vigencia de DirectX 11 frente a Vulkan y DirectX 12 es que las dos últimas requieren de aprendizaje, mientras que la API vieja ya es ampliamente conocida. Básicamente, DirectX 11 funciona, entonces, ¿para qué cambiarla? Esa mentalidad también afecta a software profesional como Blender, en el que se pudo ver cómo el desarrollo de su soporte de Vulkan acababa parado frente a un OpenGL que, a fin de cuentas, funcionaba y sigue funcionando, aunque desde la solución de creación y renderización de gráficos 3D se retomó el trabajo en torno a Vulkan tiempo después.

Desde el punto de vista del “porque funciona” parece que la existencia de Vulkan y DirectX 12 carece de sentido, pero esas API trabajan a más bajo nivel y por ende aprovechan mejor el hardware, así que la consecuencia de mantener DirectX 11 y OpenGL es un aumento de los requisitos de hardware para así “corregir” sus limitaciones. Es cierto que DirectX 12 se está empezando a imponer en la industria de los videojuegos, pero la transición está siendo bastante lenta si vemos que la API vio la luz a mediados de la década pasada.

Debido a la lentitud de buena parte de la industria del desarrollo de software a la hora de poner al día sus conocimientos, se ha creado una dinámica perversa en la que se anima a los consumidores a comprar hardware cada vez más potente para ejecutar en condiciones software obsoleto, en lugar de ponerse los desarrolladores las pilas para emplear tecnologías que aprovechen mejor el hardware.

Chrome, un caso justificado de aumento en el consumo de recursos (al menos en un principio)

Con este artículo no quiero criticar el consumo de recursos en sí, sino ciertas tendencias que se han consolidado en torno a ello, en especial el hecho de que a cambio no se aportan grandes mejoras o cosas que lo justifiquen. Sin embargo, no todos los casos son negativos, y Chrome (más bien Chromium, la tecnología base, aunque aquí me centraré en Chrome para simplificar) fue al menos en sus comienzos un caso positivo.

Chrome asomó hace catorce o quince años como huracán e impulsado por la potente maquinaria de Google. Aquel navegador, que en esencia es un Chromium con algunos aditivos de Google y con el código fuente cerrado (es privativo), destacó por el uso del multiproceso, lo que se tradujo en un notable aumento de los recursos de hardware acaparados en comparación con su competidores.

Chromium, base tecnológica de Chrome.

El uso del multiproceso permitió a Chrome aprovechar mejor unos procesadores multinúcleo que por entonces ya eran comunes. En consecuencia, el navegador de Google consumía claramente más recursos que Firefox, pero a cambio ofrecía un desempeño y una respuesta muy superiores, cosas que se apreciaban todavía más en un quad-core, y no necesariamente reciente. Es más, en el año 2016, antes de la llegada de Quantum, los navegadores Chromium mostraban un desempeño muy superior a Firefox incluso sobre un viejo Intel Core 2 Quad.

A pesar de que Chrome fue duramente criticado por la gran cantidad de recursos que acaparaba y sigue acaparando, la realidad es que la mayoría de los usuarios vieron que aquello les compensaba, así que a Mozilla no le quedó otra que ponerse las pilas e implementar el multiproceso en Firefox para intentar taponar la fuga de usuarios, algo que no ha logrado viendo cómo ha funcionado el mercado de los navegadores web desde la llegada de Quantum.

Conclusión

Las tendencias habidas en la industria del desarrollo de software en la última década han terminado por elevar artificialmente los recursos de hardware necesarios para usar el software, a veces para que este funcione correctamente, en otras porque ocupa demasiado espacio en disco, lo que en dispositivos como la Steam Deck puede forzar el uso de alguna tarjeta microSD como solución de almacenamiento adicional.

Sin embargo, no todo es pesimismo, ya que en los últimos años ha aparecido Rust, un lenguaje de programación que está haciendo mucho ruido y que desde hace unos años reclama un sitio importante en el desarrollo de software. Rust nació bajo el seno de Mozilla y actualmente opera de forma independiente. Sus entusiastas lo están empujando bastante para introducirlo en el kernel Linux y está enfocado en la seguridad de los tipos, el rendimiento y la concurrencia.

Aquí la cuestión no es tanto que Rust se extienda de por sí, sino más bien que haga de eje o se convierta en una referencia para recuperar ciertas formas de proceder que se están perdiendo en favor de elegir el camino más fácil y delegarlo todo a las capacidades del hardware.

Imagen de portada: Pixabay