Nuestra industria se colapsaría si obligáramos a todos los programadores a gestionar manualmente la memoria que usan sus programas
06 oct 2021 . Actualizado a las 05:00 h.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 tuit 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.
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 mínimamente 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.
En este contexto ¿para qué vale constatar que C es 75 veces más eficiente energéticamente 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.
Oferta de empleo que ha patrocinado La Bonilista
Creditas es una de las principales startups de Brasil -alcanzó la categoría de unicornio el año pasado- que ya cuenta con 2.800 empleados y se dedica a crear innovadores productos financieros para democratizar el acceso a los préstamos. Para seguir creciendo, buscan un/a developer que trabaje en su technical hub de Valencia o en remoto, desde España.
Buscan a alguien que aporte al menos 5 años de experiencia. Si además tienes experiencia con Kotlin y arquitecturas de microservicios mejor que mejor, pero lo que más les importa es que trabajes con buenas prácticas y tengas ganas de aprender, persiguiendo la excelencia técnica.
Además de un salario competitivo, ofrecen beneficios como Tickets Restaurant, seguro médico y de vida, ayudas económicas para el teletrabajo y hasta ayudas para cuidar tu salud física y mental.
Parece una buena oportunidad para conocer el sector Fintech y aprender desde dentro cómo se desarrolla una startup internacional de alto crecimiento. Tienes más info sobre el puesto en la página de la oferta.
Este texto se publicó originalmente en la Bonilista, la lista de correo de noticias tecnológicas relevantes para personas importantes. Si desea suscribirse y leerlo antes que nadie, puede hacerlo aquí ¡es bastante gratis!