Un formato per unirli: ELF-64

Executable and Linkable Format, o più correttamente Extensible Linking Format (da cui il nome ELF) è il nome di formato del file per eseguibili, codici oggetto e librerie nato con Unix System V e successivamente mantenuto per la gran parte dei nuovi sistemi operativi del filone *nix (Linux in testa).
Non so dire di Apple perchè non ho esperienza con quella piattaforma, ma almeno stando alla carta ciò dovrebbe valere anche per quelle piattaforme.

In tempi recenti il suo supporto nativo, ossia eseguibile direttamente sul kernel e non in macchina virtuale, è stato introdotto anche su Windows 10 (tutte le versioni), su Android (compresa la versione Desktop), su Chrome OS… oltre che naturalmente sulle varie distro Linux, per le quali è sempre esistito.
Questo significa che un software scritto e compilato per questo formato sarà poi eseguibile in via diretta su tutte le piattaforma che lo supportano, il che equivale a dire pressochè tutte le piattaforme esistenti!
Questo è il sogno di ogni sviluppatore che di ogni utente, perchè rappresenta il massimo della protezione sia per ciò che concerne la parte relativa alla codifica e manutenzione del codice che degli acquisti: si compra (o si programma) una sola volta e poi ciò che si ha in mano va bene ovunque!

Una possibile obiezione, obiezione forte e mossa da me anche in passato, riguardava gli strumenti di sviluppo (ossia le IDE), perchè senza strumenti adeguati scrivere codice di grandi dimensioni ed ancor più debuggarlo e mantenerlo nel corso del tempo, rappresenta un impegno gravoso; uno dei punti di forza sul quale gli ambienti proprietari hanno costruito la propria supremazia è stata proprio la disponibilità di ambienti di testing e sviluppo molto superiori a quelli disponibili per i formati non proprietari.

Bene, oggi non è più così.
Verso il supporto allo sviluppo su ELF si sono mossi in prima persona i colossi del software, e magari un po’ contro voglia e spinti dalla necessità anche aziende totalmente rivolte alle soluzioni proprietarie si sono come Apple e Microsoft si sono viste costrette a dare il loro supporto.
Per farla in breve, adesso sviluppare su ELF è pratico quasi quanto farlo su Windows o Mac OS.
Perino le IDE “Open Source£ come quella della foto di apertura, CodeLite (in esecuzione sullo stesso desktop la versione Win32 e quella Linux, su WSL) ormai offrono supporto allo sviluppo di livello elevatissimo, più che sufficiente ad affrontare progetti professionali di medio livello.

Se poi vogliamo parlare di linguaggi di programmazione… beh, qui lavorare per ELF-64 batte a mani basse qualsiasi target proprietario!
Non esisste un solo linguaggio di programmazione che non abbia un compilatore per ELF e una IDE che lo supporti!
Ma anche qui è tempo di scelte.
Per me fino ad oggi programmare ha significato ANSI C per tutte le parti di codice per le quali fosse obbligatoria la ricerca della massima velocità di esecuzione e/o del controllo completo della macchina e C# (.NET Framework / Mono) per l’infrastruttura del programma ed in generale le parti di codice “più ragionevoli”.
Ma è una soluzione che per quanto buona e flessibile data ormai quasi un ventennio nella parte C# ed un cinquantennio (!) se parliamo del C. Un po’ tanto, no?

Storicamente il primo vero salto nel paradigma di sviluppo ed esecuzione è da attribuire a Microsoft, che con il suo .NET Framework creò il primo layer totalmente indipendente dalla piattaforma ed in grado di supportare qualsiasi linguaggio di programmazione.
Tuttavia le ali di questo progetto grandioso e molto impegnativo furono tarpate dalla mancanza del coraggio necessario a renderlo aperto.
Come risultato solo una parte del mondo dell sviluppo adottò la nuova tecnologia, perchè ciò che veniva scritto per il Framework non era poi compatibile con le altre piattaforme a mano di non affrontare un durissimo lavoro di conversione (oltretutto non sempre possibile). questo poteva essere accettabile agli inizia degli anni 2000, quando il monopolio Microsoft era incontrastato (ed incontrastabile), ma ora è tutto diverso, Micosoft si approssima a perdere il suo monopolio… e quindi è venuto il tempi di cambiare.
Non esamino neppure .NET Core, perchè rappresenta un tentativo tardivo fatto quando i buoi nella stalla non ci sono già più.

il nuovo paradigma, quello destinato a soppiantare .NET Framework superandolo in ogni aspetto è ELF-64.
Sarà anche un ritorno alle origini, perchè come abbiamo visto risale a Unix System V, ma si tratta di un oggetto qualitativamente eccellente, flessibilissimo ed in grado di adattarsi ad ogni  tipologia di impiego.
Vero che di suo non offre i meccanismi di controllo incorporati in .NET Framework, ma questo compito è demandato con successo ai moderni linguaggi di programmazione, la cui formalizzazione e l’ambiente di esecuzione sono sufficientemente potenti da assicurare la correttezza del codice e sicurezza della sua esecuzione.
Il Framework, sia nella sua formulazione iniziale (e più completa) che nella versione “open” Core, non è più necessario perchè è stato battuto, e lo è stato anche grazie alla presa di coscienza di Microsoft e Google che resesi conto della necessità di cambiamento del paradigma hanno iniziato ad offrire il supporto diretto ad ELF-64.

I linguaggi… parlavamo dei linguaggi.
I linguaggi per impieghi generali cui suggerisco di rivolgere la propria attenzione sono essenzialmente tre: Erlang, Go e Swift.

  • Erlang non è un linguaggio nuovo, tutt’altro, ma assieme ad Ada (che però è piuttosto morta, sia nella persona che nel Linguaggio) rappresenta la miglior soluzione nell’affrontare le problematiche “mission critical”, ossia quei casi in cui il software non può in alcun caso fallire. Si noti che non mi sto riferendo alla correttezza della programmazione, quella non la garantisce niente, ma al divieto assoluto di crash. Se dovete scrivere il software di governo per la parte di controllo di una centrale telefonica, dell’avionica di un aereo o di un missile da crociera, allora Erlang è il linguaggio che fa per voi. Nonostante l’età non mi risulta essere stato superato da altro.
    Ovviamente nell’ambiente ELF-64 ci sono sia i compilatori che gli ambienti di sviluppo per Erlang.
  • Go è un linguaggio molto recente, voluto e supportato da Google. Potremmo definire Go come il superamento di C, enon a caso fra i suoi padri ci sono Thompson e Pyke… immagino non serva spiegare ai miei lettori chi sono questi due signori…
    Go (in arte Golang) non offre caratteristiche realmente nuove, se non quelle orientate al rendere obbligatoria la correttezza formale del codice.
    Si può dire che Go consente tutta la libertà di C, ma obbliga il suo programmatore a scrivere del buon codice. Tutte le scorrettezze volontarie che spesso commettevamo in C usando Go sono vietate.
    Novità ne ha qualcuna, in particolar modo nella parte relativa ai dati… ma è poca roba.
    Il linguaggio Go va scelto in sostituzione del C nei progetti di ampio respiro, magari linkandolo ad una infrastruttura scritta in Java o Kolin che si occupi della gestione dell’interfaccia utente e dei compiti meno gravosi, per fare quello che eravamo abituati in C senza avere i grattacapi successivi che questa scelta spesso comportava.
  • E siamo venuti a Swift. Swift è la vera novità, il linguaggio destinato a rompere totalmente con il passato e ridefinire totalmente la programmazione ad oggetti allo stesso livello di importanza che vent’anni fa ebbe C#.
    Anche Swift ha un padre nobile, anche se non quanto Thompson: Chris Lattner, già autore di LLVM.
    In Swift tutto è diverso, a partire dalla formalizzazione delle strutture dati… è un linguaggio nato appositamente per tagliare i ponti con il passato per ridefinire in modo completo la visione che il programmatore deve avere del codice e dei dati.
    Sicuramente per chi come me viene da linguaggi “classici” del filone Pascal, C etc etc, iniziare a “pensare in Swift” è difficile, ma le potenzialità espressive che intravedo in questo linguaggio, per il quale sono solo agli inizi dello studio, sono semplicemente incredibili.

Ricapitolando il mio già troppo lungo articolo, per chi scrive software applicativi per impieghi professionali (non mi rifarisco alle “app”, ai giochi o ai programmetti creati per hobby) è venuto il momento di dar via alla migrazione sia nella piattaforma che nei linguaggi usati.
Adottare ELF-64 offre unicamente vantaggi sia per chi sviluppa che per i clienti.
Scrivete per ELF-64 e dimenticatevi del concetto stesso di “porting”, perchè ELF-64 ormai esiste ovunque a livello nativo, è velocissimo e (quando usato con il giusto linguaggio) è estremamente sicuro, è scalabile senza modifiche nel codice dalla piccola piastra embedded al grande computer aziendale, gode di un supporto ed aggiornamento costanti… e così via per altre cento ragioni.

Dal punto di vista del cliente accettare di eseguire codice ELF-64 al posto del “solito” Win32 offre la possibilità di cambiare macchina e sistema operativo come e quando vuole, di avere lo stesso programma nel server, nel PC dell’ufficio, in quello di casa, nel telefono (possibilità che sfrutto spesso grazie alle capacità Desktop offerte dal mio mate 10 Pro)… e volendo perfino nel set-top-box collegato alla TV.
E se ci tiene il vostro cliente potrà perfino usare Linux, senza che voi dobbiate cambiare una sola riga di codice.

Ultima cosa: se avete perplessità riguardo alla “resa grafica” di un software scritto per ELF-64 date un’occhiata all’immagine di apertura dove sul mio desktop Win 10 sono in esecuzione due copie dello stesso programma, una ELF-64 (WSL) e l’altra Win32.
Vi sfido a riconoscere qual è quella Linux.

Se poi il dubbio riguarda le prestazioni vi rimando alla lettura del mio precedente articolo.

Federico