Devo dire che il Learn to Code è più faticoso di quanto mi aspettassi, anche se non è la prima volta che scrivo articoli del genere, e molta della fatica in realtà viene dallo sforzo di scrivere il tutto in modo comprensibile — con un minimo sforzo — da chiunque — con un minimo di volontà.

Il rovescio della medaglia, che sarebbe meglio chiamare dritto, è il successo di folla che la cosa ha avuto, anche se negli ultimi due giorni le statistiche sono precipitate, ma se uno guardasse alle statistiche quotidiane non andrebbe mai da nessuna parte. Per la verità mi sarei aspettato qualche commento in più, magari a proposito delle lezioni, ma di nuovo: se uno guarda al breve e medio periodo non va da nessuna parte, e le lezioni sono cominciate da una settimana e quindi mi aspetto, e auspico, che chi le vuole seguire con un po’ di metodo, se le metta da parte. Certo, il rischio è che uno se le metta da parte e poi diventino troppe e gli passi la voglia, che è un po’ il motivo per cui le ho fatte a pezzi, però insomma: è passata solo una settimana e ho raccolto reazioni favorevoli ovunque le abbia pubblicizzate, quindi sono ottimista. Nell’entusiasmo della cosa c’è anche chi ha suggerito di farne una sezione dedicata del mio sito, che è una cosa che voglio fare prima o poi, ma il mio sito è in tre lingue e tradurre il tutto prende tempo. Lo farò, comunque, ma se qualche buon’anima vuole offrirsi per tradurre, io farò volentieri la revisione e darò il giusto riconoscimento. Gratis, s’intende :) Comunque tutto questo discorso per dire che siamo quasi alla fine della parte introduttiva e che quindi rallenterò un po’ il ritmo.

L’altra cosa interessante che sta succedendo è che a dicembre devo consegnare il probation report, cioè il resoconto di come, quanto e con che risultati ho fissato lo schermo da aprile in avanti. Questo significa anche che devo preparare un prototipo di qualche tipo — cartone o software va bene uguale — e quindi mi devo rimettere a programmare sul serio, che è una cosa che non faccio da… vediamo… dal 2009. L’obiettivo è un simil-gioco musicale e quindi avrei potuto cogliere la palla al balzo e darmi a Processing, ma siccome sono scemo ho colto la palla al balzo e sono tornato a C++ che, nel frattempo, è passato da C++03 a C++11 con tutta una fila di meraviglie allegate che risolvono un certo numero di magagne che non sto qui a spiegarvi perché alcune non le ho capite granché nemmeno io, ma più che altro perché non ci ho mai cozzato. Insomma, C++11 è talmente il futuro che a mala pena è supportato dai compilatori. Si distinguono ovviamente GCC e Clang: il primo è la suite di compilatori del progetto GNU sulla quale non ho niente da aggiungere se non inginocchiarmi e toccare terra con la fronte, mentre il secondo è [yadda yadda] di Apple basato su LLVM e che vorrebbe essere un rimpiazzo per GCC, e francamente devo dire che gli sta riuscendo gran bene.

Il problema è arrivato quando si è trattato di scegliere come procedere. Le strade sono sempre due: NDH [1] o librerie misteriose. Siccome sono ingegnere e siccome odio reinventare la ruota, la mia strada preferita è sempre librerie misteriose, perché se le librerie scelte sono fatte con un minimo di criterio, si può sempre contribuire a migliorarne le parti che non vanno. Insomma, escluso Processing, le librerie per il cosiddetto creative coding si sprecano — ma neanche tanto — ma due sono quelle che spiccano fra tutte: openFrameworks e Cinder.

openFrameworks è una libreria completamente open source che si basa su altre librerie open source per fornire un ambiente di sviluppo più astratto e indipendente dal sistema operativo possibile, il che garantirebbe un’elevata portabilità e tutte le cose meravigliose. Lo svantaggio è che le librerie open source non sempre sono a prova di bomba e se escono aggiornamenti, il lavoro di manutenzione per assicurare l’inclusione dell’aggiornamento e il funzionamento del tutto è notevole.

Cinder adotta l’approccio opposto, cioè impiega librerie esterne solo quando è indispensabile e per il resto fa affidamento sul sistema operativo, il che garantisce meno dipendenze e delega agli sviluppatori dei sistemi operativi sottostanti la responsabilità di aggiornamenti e correzioni.

I due approcci in teoria sono ugualmente buoni, ma la teoria va sempre verificata coi fatti, e quindi mi sono messo di lena per scegliere il vincitore. Il mio requisito fondamentale era di poter sviluppare indipendentemente su Linux, Windows e OS X, o quantomeno in Linux e OS X dato che a casa uso l’iMac e in giro posso usare il portatile con Linux.

openFrameworks in Linux funziona. Si installa senza grossi traumi e si riesce a compilare praticamente tutte le applicazioni di esempio. Per lavorare in Windows la strada ufficiale è usare code::blocks che è un IDE che non ho mai usato ma pazienza, prima volevo provare OS X. Se ora mi metto ad elencare tutte le rogne che ho avuto a compilare anche solo un’applicazione vuota non la finiamo più. Dopo un po’ di smadonnamento ho chiuso e cancellato openFrameworks.

A quel punto mi rimaneva solo Cinder. In OS X funziona. Ho dovuto tribolare un po’, lo ammetto, soprattutto perché ufficialmente l’ultimo OS X supportato è il 10.6, anche se adesso siamo al 10.8, e i 64 bit sono una pura utopia per svariati motivi, ma in qualche modo ce l’ho fatta e sono riuscito a scrivere un po’ di codice significativo oltre all’applicazione vuota. Linux ufficialmente non è supportato da Cinder, principalmente perché non sanno come gestire la parte “disegnamo sullo schermo” che non è del tutto secondaria, ma non posso neanche dargli torto perché la scelta è tra “scrivere su X11” che nel frattempo è diventato Xorg e ha cambiato un po’ le regole, oppure affidarsi a qualche libreria intermedia tipo Cairo o Mesa. Il problema con Linux è più ampio e ne ha parlato con molta lucidità Miguel de Icaza che non è uno scemo qualunque ma uno che di software engineering e sviluppo in generale ne sa più di qualcosina. Vabè, in sostanza con un po’ di sforzi sono riuscito ad usare Cinder anche con Visual Studio 2010 che però ha una pecca notevole: il supporto a C++11 è, per forza di cose, piuttosto arretrato, e quindi l’alternativa era Visual Studio 2012.

Ora, io l’ultima volta che ho lavorato con Visual Studio è stato quando aveva appena cominciato a chiamarsi Visual Studio, quindi attorno al 1998. Per svariati motivi non ho più avuto bisogno di Visual Studio — tra cui il fatto non secondario che avevo scoperto Linux — e quindi trovarmi di fronte quella specie di abominio in salsa Windows 8 non mi ha ben disposto. Peggio ancora è che Cinder ufficialmente non supporta ancora VS2012 e quindi l’unica strada sembra compilarsi Cinder e quelle quattro librerie accessorie a manina.

E quindi l’ho fatto: ho compilato Cinder, ho compilato Boost, e ho lasciato i binari delle altre librerie come sono uscite dal pacchetto ufficiale. Per qualche motivo Visual Studio 2012 insiste a cercare Boost compilata dal 2010, ma siccome né nel progetto della mia applicazione né in quello di Cinder ci sono riferimenti a Boost, il mio timore è che le altre librerie ci facciano riferimento e quindi la maledetta funzione di auto-link vada in cerca di quei binari. Le librerie accessorie non mi risultano avere Boost come dipendenza, d’altra parte stiamo parlando di roba della risma di libpng… ma non si sa mai: proverò a ricompilare tutte le librerie in questione e se non va… boh.

A peggiorare le cose il fatto che non avrò i soldi per permettermi un MacBook Pro prima di qualche mese, che sarebbe tristemente la soluzione ideale.

1. Not Developed Here.[↑]