Si può parlare di green software, ovvero di programmi a basso impatto ambientale?
TL;DR
SENZA DUBBIO
Di primo acchito sembrerebbe di no, si direbbe che il consumo dipenda solo dall'hardware.
In realtà le cose non stanno proprio così: infatti, sebbene l'hardware sia il primo aspetto da considerare per limitare l'impatto ambientale di un sistema di elaborazione, tuttavia non è il solo elemento valutare.
Una semplice considerazione può metterci sulla giusta via. Cosa succederebbe se venisse chiesto a due programmatori (P1 e P2) di sviluppare un programma per riordinare le voci dell'anagrafica clienti?
In base alla loro esperienza potrebbero adottare approcci (o come si dice in gergo algoritmi) differenti.
P1, alle prime armi, potrebbe decidere di procedere in analogia con quanto farebbe per riordinare un mazzo di carte e finirebbe per procedere con una modalità detta insertion sort.
P2, più scafato e dal carattere prudente, deciderebbe magari per un diverso algoritmo... diciamo il merge sort.
Qui ha poca importanza comprendere come funzionano questi algoritmi, è importante capire che hanno caratteristiche completamente diverse: se, per esempio, riordinare un elenco casuale di un milione di nominativi richiedesse, con il merge sort, 30s... non sarebbe strano dover aspettare più di 57gg per ottenere lo stesso risultato con l'insertion sort.
Le scelte di progettazione determinano l'efficienza dei programmi e questa è strettamente correlata ai consumi energetici
Bene, è ovvio - direte voi. Forse - rispondo io. Tuttavia, anche eliminando la variabile progettista / sviluppatore / programmatore e considerando tutti i programmatori allo stesso livello (sic!), la storia non finirebbe qui.
Gli sviluppatori, per scrivere programmi, usano dei linguaggi di programmazione: ne esistono a centinaia e nessuno può conoscerli tutti.
Non solo, non basta conoscere un linguaggio di programmazione, per utilizzarlo in pratica c'è bisogno di un ambiente di sviluppo (un insieme di programmi) che permetta di scrivere, eseguire e verificare il codice.
Gli ambienti di sviluppo non sono equivalenti ed hanno un impatto sulla qualità del prodotto finale
Quindi, anche se P1 è equivalente a P2 ma diamo un cacciavite a P1 ed una sega a P2 con l'ordine di abbattere un albero (a proposito di green!), avremo sempre un chiaro vincitore.
Anche questo è ovvio - ribatterete voi.
Allora supponiamo che, non solo tutti i programmatori siano ugualmente capaci (sic!), ma che abbiano a disposizione il miglior ambiente di sviluppo per il linguaggio (o i linguaggi) che conoscono (non è scontato in nessun ambiente di lavoro).
Ebbene non produrranno codice energicamente equivalente.
Tutti i linguaggi di programmazione sono Turing-equivalenti, hanno cioè lo stesso potere computazionale. Per dirla grossolanamente, se posso scrivere, col linguaggio A, un programma per svolgere un compito, posso farlo anche col linguaggio B.
La situazione si chiarisce se pensiamo alle lingue: è possibile tradurle una nell'altra. Non è però detto che si possano sempre conservare tutte le sfumature senza ricorrere a perifrasi o altre forme retoriche.
Per dirla in altro modo, lo stesso concetto potrebbe essere più facile da esprimere in una lingua rispetto ad un'altra. Basta paragonare wabi-sabi (giapponese) con bellezza austera e, quasi malinconicamente, chiusa in sé (italiano).
Per di più, come la lingua madre che parliamo determina, in una qualche misura, il modo in cui pensiamo (relativismo linguistico o ipotesi di Saphir-Whorf) anche un linguaggio di programmazione determina il modo in cui affrontiamo un problema informatico.
Non tutti i linguaggi di programmazione sono green
Se tutto questo vi sembra pura teoria, potete ricredervi leggendo l'interessante studio: Energy Efficiency across Programming Languages - How Does Energy, Time, and Memory Relate?
Prima di tutto è interessante notare come non si possa affermare, tout court, che un linguaggio "più veloce" sia anche più green. L'equazione:
Energy (J) = Power (W) x Time(s)
mette in evidenza come non basti considerare il tempo di esecuzione di un programma per valutarne il dispendio energetico.
Altra aspetto interessante, seppur prevedibile, è che i linguaggi compilati tendono ad essere i più energicamente efficienti (oltre il doppio rispetto alle macchine virtuali ed oltre un ordine di grandezza rispetto ai linguaggi interpretati).
Riportiamo infine questo interessante schema tratto dalla sopraccitata ricerca (Pareto optimal sets for different combination of objectives):
| Time & Memory | Energy & Time | Energy & Memory | Energy & Time & Memory |
|---|---|---|---|
| C • Pascal • Go Rust • C++ • Fortran Ada Java • Chapel • Lisp • Ocaml Haskell • C# Swift • PHP F# • Racket • Hack • Python JavaScript • Ruby Dart • TypeScript • Erlang JRuby • Perl Lua |
C Rust C++ Ada Java Pascal • Chapel Lisp • Ocaml • Go Fortran • Haskell • C# Swift Dart • F# JavaScript Racket TypeScript • Hack PHP Erlang Lua • JRuby Ruby |
C • Pascal Rust • C++ • Fortran • Go Ada Java • Chapel • Lisp OCaml • Swift • Haskell C# • PHP Dart • F# • Racket • Hack • Python JavaScript • Ruby TypeScript Erlang • Lua • Perl JRuby |
C • Pascal • Go Rust • C++ • Fortran Ada Java • Chapel • Lisp • Ocaml Swift • Haskell • C# Dart • F# • Racket • Hack • PHP JavaScript • Ruby • Python TypeScript • Erlang Lua • JRuby • Perl |
La conclusione è che, indubitabilmente, i programmi possono (sarebbe ormai opportuno dire "debbono") essere energy-efficient ed i programmatori energy-aware.
Questo può avvenire senza sacrificare affidabilità, manutenibilità e semplicità del sistema. Purtroppo, di solito... non avviene.