Luis David de la Fuente

hace 2 semanas · 4 min. de lectura · visibility ~10 ·

chat Contactar con el autor

thumb_up Relevante message Comentar

Como afecta al recibo de la luz el lenguaje en el que programas

El mismo código, consume 35 veces más energía si lo escribes en Ruby en vez de con Java, aunque no nos importe una mierda.

Hace algunos meses, Alex Ballarín me lanzó un anzuelo en forma de tweet incendiario en el que afirmaba que el mismo código escrito en PHP consumía 29 veces más energía al ser ejecutado que si hubiera estado escrito en C y planteaba si no es algo que quizás deberíamos plantearnos en plena crisis climática.

Mi primera reacción fue enarcar una ceja ante el enésimo flame sobre lo bueno o malo que es este o aquel lenguaje —una traslación al mundo adulto de las absurdas peleas que teníamos de niños para determinar si era mejor SEGA o Nintendo—, pero cuando le pedí la fuente que sostenía dicha afirmación y me envió un estudio universitario investido de una mínima rigurosidad, el tema dejó de captar mi atención para despertar mi curiosidad.

Y la verdad es que sí, que el estudio es muy interesante, pero no especialmente significativo. Para ejecutar un algoritmo que genera cadenas aleatorias de ADN, Perl necesita 100 VECES más energía que Rust. Una barbaridad, si no fuera porque el gasto es de 2.684 julios, el 0,00001% de lo que consume nuestra nevera en un mes. Me he molestado en calcularlo.

Lo que parece que los investigadores no han tenido en cuenta es que —fuera del laboratorio— es imposible determinar qué lenguaje de programación es más eficientemente energeticamente sin considerar el factor humano, las horas que empleará un programador en desarrollar y mantener el código. De nada sirve medir que el acceso indexado a una secuencia de 12 números enteros consume 309 julios con Lisp y 414 en JavaScript sin tener en cuenta el tiempo que emplearán los programadores en implementarlo con cada uno... y la eficiencia con la que lo harán.

La mayor utilidad del informe es sacar a la palestra el consumo energético del software en una época en la que muchos programadores profesionales ni siquiera se plantean que, usen el lenguaje que usen, al final todo su trabajo se convierte ceros y unos —transistores apagados y encendidos— en la CPU de un ordenador. Hablando en plata, hemos llegado a tal nivel de abstracción que hemos perdido la perspectiva de lo que realmente estamos haciendo.

Esa abstracción del hardware que lo ejecuta ha democratizado el desarrollo de software, pero una cosa es abstraerse del mismo y otra ignorarlo o despreciarlo.

© Ilustración original de Hugo Tobio, tarugo y dibujolari profesional de Bilbao.

Lo fácil sería echar la culpa a los bootcamps, escuelas que prometen «enseñar a programar en 3 meses» —plazo en el que apenas se puede atisbar la lógica detrás de la «majia» que hace funcionar un programa—, pero parece más el zeitgeist o espíritu del tiempo que nos ha tocado vivir: Node.js es rápido, Java es lento y dedicar unas horas a entender cómo funciona el garbage collector en vez de a hacer un «Hola Mundo» con el último framework de JavaScript, una perdida de tiempo. Con este andamiaje intelectual y unas pegatinas en la tapa del portátil, hoy en día se puede disfrutar de una fructífera carrera en la industria del software.

Es significativo que roadmap.sh, un popular sitio donde se sugieren los currículos formativos más adecuados para entrar en la industria del software, en el rol de Backend Developer marque como recomendado, pero «opcional» todo lo que toque minimamente el hardware. Aún llama más la atención que en el perfil de Frontend Developer ni siquiera aparezca como recomendación. Como si el código front se ejecutara en El Mundo de la Piruleta en vez de en el ordenador de nuestros usuarios.

Nuestra industria se colapsaría si obligáramos a todos los programadores a gestionar manualmente la memoria que usan sus programas.

En este contexto ¿para qué vale constatar que C es 75 veces más eficiente energeticamente que Python? Nuestra industria —y, con ella, todo el sistema— se colapsaría si de un día para otro obligáramos a todos los programadores a gestionar manualmente la memoria que usan sus programas. Una industria donde se nos anima a aprender lo «suficiente» en vez de lo «necesario». Lo justo para ser piezas útiles del engranaje, pero no para cambiarlo.

A lo mejor nos pasamos toda la vida programando aplicaciones web o para móviles, sin ninguna limitación computacional o energética, pero si mañana tuviéramos que programar el software que controla el sistema de navegación de un nanosatelite cuyas placas solares apenas generan 2W de energía, deberíamos saber que —por mucha productividad que ganáramos— no seríamos capaces de alimentar los ciclos de procesador que devora la máquina virtual de Erlang.

Puede que nunca tengamos la posibilidad de programar el sistema de navegación de un satélite, pero sería estúpido que nos la negáramos nosotros mismos. Por eso nunca debemos olvidar que nuestra proyección profesional no la determinará nuestro dominio de una herramienta sino usar la más adecuada para cada tarea. En la estratosfera o en la web de la frutería de la esquina.

No hay que ir al espacio para encontrar ejemplos que sostengan esa afirmación. Podemos enseñar a alguien a programar con PHP y ayudarle a dominar su sintaxis, pero si no sabe que es un lenguaje interpretado y lo que eso implica, jamás entenderá por qué le pedimos que use un acelerador/compilador —más allá del «porque hay que hacerlo»— ni tampoco los casos en los que se justifica no hacerlo.

En un mundo que parece querer infantilizar la figura del programador, a lo mejor hay que recordar que una cosa es aplanar curva de aprendizaje de la informática y otra limitarla. En un mundo que pone cada vez más distancia entre los desarrolladores y el hardware que ejecuta su código, a lo mejor hay que recordar que un profesional debe conocer cómo funcionan las herramientas y tecnologías que usa. Si no fuera así ¿cómo podría estar seguro de usar las más adecuadas para cada tarea?

No Alex, no vamos a acabar con el cambio climático programando en C en vez de con Python. Que nuestro código consuma 8 u 80 julios al ejecutarse es irrelevante. Lo verdaderamente importante es saber por qué y cuándo deja de serlo.


Artículo publicado por David Bonilla en La Bonilista el 3 de octubre de 2021

group_work en La Bonilista

thumb_up Relevante message Comentar
Comentarios

Más artículos de Luis David de la Fuente

Ver blog
hace 1 semana · 5 min. de lectura

El desapego

Hace un par de semanas, un tarugo me envío un text ...

hace 1 mes · 3 min. de lectura

Cinco antipatrones de software que puedes encontrar en la vida diaria

Desarrollar software es una actividad compleja. Po ...

hace 1 mes · 8 min. de lectura

Hastings, el hombre que fundó Netflix con una regla: al diablo con las reglas

El éxito de la compañía es el resultado de una bue ...