Como afecta o recibo da luz a linguaxe no que programas

O mesmo código, consome 35 veces máis enerxía se o escribes en Ruby no canto de con Xava, aínda que non nos importe unha merda.

Hai algúns meses, Alex Ballarín lanzoume un anzol en forma de chío incendiario no que afirmaba que o mesmo código escrito en PHP consumía 29 veces máis enerxía ao ser executado que se estivese escrito en C e expuña se non é algo que talvez deberiamos expornos en plena crise climática.

A miña primeira reacción foi enarcar unha cella ante o enésimo flame sobre o bo ou malo que é este ou aquela linguaxe -unha translación ao mundo adulto das absurdas pelexas que tiñamos de nenos para determinar se era mellor SEGA ou Nintendo-, pero cando lle pedín a fonte que sostiña dita afirmación e envioume oun estudo universitario investido dunha mínima rigorosidade, o tema deixou de captar a miña atención para espertar a miña curiosidade. 

E a verdade é que si, que o estudo é moi interesante, pero non especialmente significativo. Para executar un algoritmo que xera cadeas aleatorias de ADN, Perl necesita 100 veces máis enerxía que Rust. Unha barbaridade, se non fose porque o gasto é de 2.684 xullos, o 0,00001% do que consome a nosa neveira nun mes. Molesteime en calculalo. 

O que parece que os investigadores non tiveron en conta é que -fose do laboratorio- é imposible determinar que linguaxe de programación é máis eficientemente energeticamente sen considerar o factor humano, as horas que empregará un programador en desenvolver e manter o código. De nada serve medir que o acceso indexado a unha secuencia de 12 números enteiros consome 309 xullos con Lisp e 414 en JavaScript sen ter en conta o tempo que empregarán os programadores en implementarlo con cada un... e a eficiencia coa que o farán. 

A maior utilidade do informe é sacar á palestra o consumo enerxético do software nunha época na que moitos programadores profesionais nin sequera exponse que, usen a linguaxe que usen, ao final todo o seu traballo se converte ceros e uns -transistores apagados e acesos- na CPU dun computador. Falando en prata, chegamos a tal nivel de abstracción que perdemos a perspectiva do que realmente estamos a facer. 

Esa abstracción do hardware que o executa democratizou o desenvolvemento de software, pero unha cousa é abstraerse do mesmo e outra ignoralo ou desprezalo.

O doado sería botar a culpa aos bootcamps, escolas que prometen «ensinar a programar en 3 meses» -prazo no que apenas se pode albiscar a lóxica detrás da «majia» que fai funcionar un programa- , pero parece máis o zeitgeist ou espírito do tempo que nos tocou vivir: Node.js é rápido, Xava é lento e dedicar unhas horas a entender como funciona o garbage collector no canto da facer un «Ola Mundo» co último framework de JavaScript, unha perdida de tempo. Con este andamiaje intelectual e uns adhesivos na tapa do portátil, hoxe en día pódese gozar dunha frutífera carreira na industria do software. 

É significativo que roadmap.sh, un popular sitio onde se suxiren os currículos formativos máis adecuados para entrar na industria do software, no rol de Backend Developer marque como recomendado, pero «opcional» todo o que toque minimamente o hardware. Aínda chama máis a atención que no perfil de Frontend Developer nin sequera apareza como recomendación. Coma se o código front executásese no Mundo da Piruleta no canto de en o computador dos nosos usuarios. 

Neste contexto para que vale constatar que C é 75 veces máis eficiente enerxeticamente que Python? A nosa industria -e, con ela, todo o sistema- se colapsaría se dun día para outro obrigásemos a todos os programadores a xestionar manualmente a memoria que usan os seus programas. Unha industria onde se nos anima a aprender o «suficiente» no canto do «necesario». O xusto para ser pezas útiles da engrenaxe, pero non para cambialo. 

Se cadra pasámonos toda a vida programando aplicacións web ou para móbiles, sen ningunha limitación computacional ou enerxética, pero se mañá tivésemos que programar o software que controla o sistema de navegación dun nanosatelite cuxas placas solares apenas xeran 2W de enerxía, deberiamos saber que -por moita produtividade que gañásemos- non seriamos capaces de alimentar os ciclos de procesador que devora a máquina virtual de Erlang. 

Poida que nunca teñamos a posibilidade de programar o sistema de navegación dun satélite, pero sería estúpido que nola negásemos nós mesmos. Por iso nunca debemos esquecer que a nosa proxección profesional non a determinará o noso dominio dunha ferramenta senón usar a máis adecuada para cada tarefa. Na estratosfera ou na web da froitería da esquina. 

Non hai que ir ao espazo para atopar exemplos que sosteñan esa afirmación. Podemos ensinar a alguén a programar con PHP e axudarlle a dominar a súa sintaxe, pero se non sabe que é unha linguaxe interpretada e o que iso implica, xamais entenderá por que lle pedimos que use un acelerador/compilador -máis aló do «porque hai que facelo»- nin tampouco os casos nos que se xustifica non facelo. 

Nun mundo que parece querer infantilizar a figura do programador, se cadra hai que lembrar que unha cousa é aplanar curva de aprendizaxe da informática e outra limitala. Nun mundo que pon cada vez máis distancia entre os desenvolvedores e o hardware que executa o seu código, se cadra hai que lembrar que un profesional debe coñecer como funcionan as ferramentas e tecnoloxías que usa. Se non fóra así como podería estar seguro de usar as máis adecuadas para cada tarefa? 

Non Alex, non imos acabar co cambio climático programando en C no canto de con Python. Que o noso código consuma 8 ou 80 xullos ao executarse é irrelevante. O verdadeiramente importante é saber por que e cando deixa de selo.

 Este texto publicouse orixinalmente na Bonilista, a lista de correo de noticias tecnolóxicas relevantes para persoas importantes. Se desexa subscribirse e lelo antes que ninguén, pode facelo aquí ¡é bastante gratis!

---

---

---