6 Commenti

Neil Young direbbe "Rust never sleeps"

È ancora il tempo del C?

di

thumbnail

04

mag

2015

Il principe dei linguaggi messo sotto pressione da parte di concorrenti più giovani, svelti e di tendenza. Resiste ma vacilla.

Implementavo cose giuste, e ora sono uno splendido quarantenne. Questo probabilmente direbbe oggi il linguaggio C parafrasando una celebre battuta di Nanni Moretti. Dal 1972 in poi C ha continuato a essere IL linguaggio di programmazione. Quello imprescindibile, quello essenziale per imparare gli algoritmi, le strutture dati e i sistemi operativi.

Molti dei più importanti componenti software sono ancora oggi scritti e manutenuti in C, e perciò non è certo una sorpresa che questo linguaggio abbia ancora grande diffusione e popolarità tra gli sviluppatori.

Guardando la statistica relativa alle offerte di lavoro (conteggiate in valore assoluto) pubblicata dal portale di annunci indeed.com, C è saldamente in prima posizione, seguito da Java e dagli altri soliti noti.

 

Tutti quindi a imparare o a rinfrescare C? Non proprio. Tornando ancora alle statistiche di indeed.com, ma valutando stavolta la percentuale di crescita, sono i linguaggi più moderni come Python e Ruby a mostrare gli andamenti più interessanti. Ovviamente si tratta di linguaggi di più recente diffusione, e il loro successo è una conseguenza del tutto fisiologica, ma queste percentuali di crescita sono sicuramente sintomo di come il mercato stia lentamente cambiando.

 

C è un linguaggio low-level e soffre di una serie di problemi strutturali che non lo rendono adatto a tutti i contesti. Aziende che hanno bisogno di un time to market rapidissimo per sopravvivere – come ad esempio molte startup – o quelle che per vari motivi non si possono permettere un team di soli sviluppatori esperti, difficilmente usano C. Non è un caso che il grosso del codice dietro a Dropbox, GithubAirbnb sia scritto in Python e Ruby e che molti corsi universitari prima allineati su C per introdurre i fondamenti della programmazione abbiano fatto scelte differenti.

A differenza di altri linguaggi, C ha una soglia di apprendimento apparentemente bassa, ma è facile impararlo male e di conseguenza causare danni anche gravi. Rob Graham scrive sul suo blog a proposito dei problemi di sicurezza in C:

C è intrinsecamente pericoloso. Quando un bug scrive fuori dal suo buffer, non viene immediatamente intercalate come avverrebbe in Java o in altri linguaggi di alto livello. È solo più tardi, a volte molto più tardi, che quella memoria alterata viene usata e il programma si blocca. Questo insegna agli studenti che i bug si manifestano magicamente e sono misteri profondamente impenetrabili, incomprensibili a qualsiasi mortale.

E termina il post puntando il dito sulle modalità nelle quali il linguaggio viene insegnato:

In altre discipline ingegneristiche, si impara per prima cosa il fallimento. Chi ingegnerizza ponti impara perché il Tacoma Narrows ha fallito. […] È solo nell’ingegneria del software che il fallimento viene ignorato. Perfino dopo un decennio di fallimenti, agli studenti viene comunque insegnato a scrivere software come se il fallimento fosse una minaccia che mai affronteranno. È sbagliato in generale, ma specialmente con il linguaggio C. Non è che gli studenti debbano “prendere la sicurezza sul serio” e passare tutto il loro tempo a imparare qualsiasi tecnica di hacking di codice, ma la loro istruzione dovrebbe contemplarne almeno le basi.

Basi spesso trascurate sia dai corsi universitari di base sia dalla gran parte dei libri su C, che si limitano a illustrare i concetti base senza approfondire le corrette pratiche della programmazione.

Non mancano però alcune eccezioni. Ad esempio, 21st Century C ha una prima parte che mostra in dettaglio come dovrebbe essere l’environment di sviluppo di un programmatore C moderno, spiegando come usare il debugger, come scrivere unit test e come usare il memory checker  Valgrind. Anche l’iniziativa del docente dell’università di Strasuburgo Jens Gustedt merita di essere menzionata. Jens tiene da anni un blog sulla programmazione in C e sta lavorando a un ebook dal titolo eloquente: Modern C.

Con un approccio corretto all’apprendimento e all’utilizzo, C rimane un linguaggio di grande versatilità e con performance da primo della classe, e la sua immensa codebase garantisce che non verrà soppiantato rapidamente dai nuovi linguaggi emergenti. Rimane però il fatto che C è nato quando le potenze di calcolo erano ordini di grandezza inferiori e non c’erano da gestire processori con molti core, ed è quindi ragionevole riflettere se non sia arrivato il momento di mandarlo in pensione.

Go , NimD e Rust sono, con differenti livelli di maturità, linguaggi più moderni, intrinsecamente più sicuri e adatti per scrivere applicazioni concorrenti e high performance.

Non mi stupirebbe che uno di questi quattro ragazzini terribili nel giro di pochi anni riuscisse a soppiantare C (e ragionevolmente anche C++) come prima scelta per scrivere software sicuro e ad alte prestazioni. Tra i quattro, Rust, nato in casa Mozilla,  mi sembra quello con l’approccio più interessante e comprensivamente quello più promettente, ma Go di Google è già una realtà di fatto e vanta una comunità di sviluppatori piuttosto nutrita. Nim e D sono più di nicchia, ma comunque degni di nota.

C non sparirà a breve e mai come ora c’è bisogno di programmatori che lo padroneggino veramente per evitare il prossimo Heartbleed. Se però non avete vincoli e volete proiettarvi nel futuro, datevi un’occhiata in giro: non è più l’unica scelta possibile, c’è di meglio.




Andrea C. Granata (@andreacgranata) ha pigiato i primi tasti su un bianco VIC20 quando ancora Internet era in fasce. Un po’ sistemista un po’ sviluppatore, ha una passione per FreeBSD, programmazione in Ruby, metodologie Agile e infrastrutture cloud. Si occupa di Enterprise Architecture e di DevOps per una delle più importanti banche italiane. Nel tempo libero si divide tra la passione per la cucina, il pattinaggio di figura e i viaggi in Oriente.

Letto 5.975 volte | Tag: , , , , , , , , , , , , , , ,

6 commenti

  1. Erix

    Mi pare ci sia un equivoco di fondo: il C è un linguaggio assembly portatile, compito che svolge egregiamente, e come tale non vedo all’orizzonte traccia di un potenziale sostituto.
    Sbaglia chi lo insegna all’università come linguaggio applicativo generico, come sbaglia chi magari cerca di usare Python, C# o Java su un microcontrollore.
    In sostanza, non confondiamo chiavi inglesi e cacciaviti: a ciascuno strumento il proprio compito.
    Pienamente d’accordo invece sulla necessità di insegnare la buona programmazione fin da subito.

  2. Andrea C. Granata

    @erix sul fatto che insegnare (male) C come linguaggio applicativo generico sia un errore siamo perfettamente d’accordo visto che in quello spazio c’è di molto meglio (Ruby e Python ad esempio). Non concordo invece sul fatto che le alternative come Rust, Nim, & c. non possano scalfire lo spazio del C. Dai una occhiata a
    https://github.com/jensnockert/dueboot e a https://projects.tessel.io/projects/rust-on-tessel, non li trovi promettenti?

  3. Erix

    @andrea ci sono validi linguaggi in giro, per aggiungere un esempio ai tuoi cito LuaJIT che può in alcune situazioni essere più veloce del C ottimizzato a mano. Ma il punto è che qualsiasi linguaggio che isoli dalla macchina fisica non è la soluzione adatta se ciò che si deve fare è appunto operare direttamente, in modo deterministico e senza intermediari sull’hardware (nota ad esempio che Rust consente C binding, che non avrebbero senso se potesse sostiture il C in ogni applicazione).
    Prova a fare una cosa del genere con un linguaggio diverso dal C (a parte operare direttamente in assembly): http://www.erix.it/play-v6
    A questo proposito, qui trovi alcune mie opinioni per quanto riguarda la programmazione dei microcontrollori:
    http://www.quintadicopertina.com/enricocolombini/2015/04/18/dont-stop-at-the-arduino-libraries/

  4. Lucio Bragagnolo

    Solo per amore di battuta e di curiosità aggiungo che una ricerca su GitHub mostra la stragrande maggioranza di commenti ugly hack dentro programmi in C che non in altri linguaggi.

  5. Riccardo Meggiato

    Forse anche per un po’ di affetto nei confronti di Enrico, di cui possiede ogni libro di programmazione, devo concordare con la sua analisi. Mi occupo tra le altre cose anche di programmazione di videogame, e non esiste alternativa al C, se si tratta di andare “hard to metal”. Moltissimi motori grafici di giochi noti per fluidità e ottimizzazione, anche oggi, sono scritti in C, specie per console. Le “alternative” sono relegate a mero linguaggio di script ALL’INTERNO del motore. Questa natura di basso livello, certo, ha lo svantaggio di portarti a fare erroracci. Ma funziona come con le auto, con la differenza che passa tra correre in Mercedes e correre con una Lotus. La Lotus ha prestazioni nettamente migliori, ma al primo errore esci di strada. Se vuoi il viaggio sicuro te lo fai in Mercedes. Insomma, sono linguaggi non confrontabili e un confronto sulla base delle richieste di mercato, benché interessante, forse non si affronta dal punto di vista tecnico (le ragioni del successo di quella porcata di Java sono altre, ma credo che qui dentro lo sappiamo tutti). Saluti

  6. llde

    @erix @Riccardo

    Rust e Nim possono facilmente andare close to the metal. Quindi sono linguaggi che possono in tutto e per tutto essere usati al posto del C.
    Il commento di erix sul binding non ha alcun senso.
    Nim compila in C e non direttamente nativo, e quindi implementare il binding era molto semplice, Rust implementa il binding C per poter usare l’ecosistema esistente di librerie (nonstante molte librerie C/C++ only stanno venendo portate totalmente in Rust come freetype)

    @Andrea
    Di tutti i linguaggi nuovi che hai menzionato Go è l’unico che non ha possibilità di andare close to the metal, e di poter fare programmazione di sistema. Questo a casua del suo garbage collector obbligatorio e dell’assenza della ssiblità di rimuovere la runtime

Lascia il tuo commento