{FONT 13}{COLOR 5} Pensieri di un coder nel Regno delle Tenebre{FONT 1}{COLOR 1} Nel mezzo del mio eterno vagabondare nel regno delle tenebre ho meditato per 17 secondi sugli articoli di Manta apparsi su Planet #5. Di solito io non esprimo pubblicamente le mie opinioni ma in questo caso voglio farlo non tanto per rispondere a Manta ma per invitare gli altri coder a riflettere bene prima di imboccare la strada che egli nei suoi articoli indica e che io considero sbagliata e pericolosa. Ci tengo comunque a precisare che non voglio scatenare sterili polemiche ma solo esprimere un opinione che non ha pretesa di essere verità assoluta. Io non sono di quelli che conoscono solo il 68K e l'assembler. Non ho imparato a programmare dal corso di Randy (per dirla tutta li ho scritti, un paio di capitoli del corso). Ho avuto modo di lavorare su diverse architetture, con svariati linguaggi e tools di sviluppo. Conosco bene "filosofie" di programmazione distanti anni luce dal coding in asm che tanto è stato usato su Amiga. Devo ammettere che non sono così aggiornato come Manta perché ultimamente faccio un lavoro un po' diverso. Però in compenso, se non altro per motivi anagrafici, penso di aver studiato queste cose prima di Manta e pertanto di averci pensato sopra più a lungo e di poter giudicare con animo meno influenzato dall'entusiasmo del neofita che si apre ad un nuovo modo di concepire la programmazione. Concordo pienamente con l'analisi fatta da Manta della metodologia di sviluppo utilizzata su Amiga e apprezzo chiarezza e lucidità della sua esposizione, che sembra ispirata in parte da testi di Ingegneria del Software e in parte dalla parodia di tale disciplina inscenata dall'immatura e incompetente industria informatica. Non ha più senso sviluppare applicazioni in assembler e in accesso diretto all'hardware e penso che siano veramente in pochi a farlo. Però qui non stiamo parlando di software applicativo o giochi o utility di sistema. Stiamo parlando di demo. E` verissimo che con la tecnologia moderna tutti i demo si potrebbero (ri)fare in C usando l'RTG con grandi vantaggi in termini di portatilità ed efficienza. Ma in base allo stesso ragionamento tra qualche anno converrà buttare alle ortiche C e RTG e usare Java e OpenGL, così i nostri demo saranno platform independent. E magari usando un tool RAD le potremo sviluppare in mezz'ora. Se ho capito bene i tuoi ragionamenti, caro Manta, non capisco perché non li porti alle estreme conseguenze e non fai come Randy che su questa linea di pensiero ti ha preceduto ed è avanti di molti passi. Un ragionamento analogo, ispirato ai medesimi principi di efficienza e portatilità, conduce alla conclusione che il concetto stesso di demo è ormai superato, perché prima o poi qualunque effetto realizzabile attraverso il codice può essere ottenuto usando Lightwave o Scala o il prossimo venturo Extreme del nostro amico Modem. A cosa serviranno allora a Manta e ai suoi seguaci le loro superiori conoscenze tecniche quando il mio lamerissimo amico Jack de lu Puje (che usa computers da 10 anni e non ha ancora capito la differenza tra un editor e un word processor) riuscirà a riprodure le loro demo sul suo squallidissimo WC cliccando goffamente tre gadget di un applicativo trovato su un CD ROM omaggio di Repubblica (già mi vedo il titolo "Anche tu artista virtuale!") ? E il bello è che il mio amico si riterrà persino cool per cotanto risultato e pretenderà di parlare con Manta di demo da pari a pari ("ho scoperto che con un comando si può appiccicare una figura su una faccia del cubo! Quanto sono bravo! Però stranamente le figure salvate da word non le carica...ho provato a cambiare le ultime tre lettere del nome da DOC a quelle che di solito gli mette paintbrush, BPM o qualcosa del genere, però non le carica lo stesso.. Fammi vedere la tua demo che ti consiglio come migliorarla")! Non auguro a Manta un amico del genere (che non puoi trattar male come meriterebbe perché gli vuoi troppo bene) e non credo che egli desideri che in futuro le demo vengano prodotte, come accade oggi per le pagine HTML, da incompetenti lamer che si ritengono esperti di informatica perché sanno usare due o tre applicativi. O forse mi sbaglio. In realtà non so quale sia esattamente il concetto che Manta ha di demo. Sicuramente è diverso dal mio. In uno dei suoi articoli Manta scrive che i mag sono "la vera anima della scena - non i demo come si crede". Non voglio commettere l'errore di dare una mia interpretazione a questo suo inciso, nondimeno mi viene il sospetto che io e Manta non intendiamo esattamente la stessa cosa per demo. Non me ne voglia Corrosion, mi piacciono i mag, ma il motivo fondamentale per cui mi interesso alla scena sono i demo. A mio parere un demo non può essere considerato alla stregua degli altri programmi. Un demo non ha uno scopo pratico, non risolve alcun problema, non frutta guadagni materiali agli autori. Oddio, chi vince i party qualcosa guadagna, ma se quello è lo scopo potrebbe investire più proficuamente il suo tempo e le sue energie in altre attività. Siccome i demo non sono programmi normali, non possono essere valutati attraverso le usuali metriche di qualità. Perché mai dovrebbe essere meglio programmare in C con la RTG? Per ottenere risultati migliori in un tempo minore? Ma lo scopo di un demo non è ottenere un risultato concreto. E nemmeno di ottenere semplicemente un certo effetto artistico. O perlomeno non è per questo che io realizzo demo. Se l'unica cosa importante fosse il risultato artistico, allora lo si dovrebbe inseguire adottando il mezzo che ci fa ottenere i risultati migliori con minor sforzo possibile. Ma allora presto o tardi si finirebbe per abbandonare totalmente la programmazione. Si finirebbe per far demo con qualche software applicativo. Ma allora non sarebbe più un demo. Sarebbe computer graphics. Io credo che i demo non siano computer graphics o che siano un genere particolare di computer graphics. Secondo me, lo scopo di un demo è di esprimere l'abilità di programmatore del coder raggiungendo al contempo un certo risultato artistico. A me non interessa ottenere il risultato visivo con qualsiasi mezzo, non sono un grafico, mi interessa ottenere il risultato attraverso la programmazione. Non solo: NON mi interessa programmare in maniera facile, la scrittura del codice deve essere un attività interessante e per essere interessante deve necessariamente presentarmi delle difficoltà che riesco a superare per mezzo del mio talento di programmatore. Ovviamente la difficoltà di un problema variano in funzione della potenza degli strumenti di cui ci si avvale per risolverlo. E' evidente anche a chi non è coder che tracciare una linea sullo schermo utilizzando solo istruzioni asm che ti consentono di manipolare i singoli pixel presenta una certa difficoltà, mentre tracciare la medesima linea utilizzando l'apposita funzione messa a disposizione dalla graphics library (o da una libreria RTG) presenta una difficoltà diversa. Quindi per poter realizzare una demo che permetta di esprimere il talento del coder è necessario specificare preliminarmente quali sono i limiti cui il coder deve sottostare, ovvero qual'è l'architettura hardware-software che intende utilizzare. Questa idea del coder che si pone da solo dei limiti può suonare un po' strana, ma è esattamente la stessa cosa che accade in molte arti. Pensiamo per esempio alla poesia: ci sono poeti che scrivono in versi liberi e altri che invece di proposito si pongono dei limiti decidendo di usare un determinato metro (ogni verso ha un certo numero di sillabe, le rime seguono schemi prefissati,...). Se Dante avesse scritto la Commedia in prosa avrebbe sicuramente impiegato molto meno tempo e sprecato molte meno energie. Ciononostante ha preferito utilizzare i versi per mostrare (prima a se stesso e poi agli altri) che il suo immenso talento letterario gli permetteva di raccontare un complicatissimo viaggio sottostando ai limiti di una forma prefissata. Mi si può obiettare che nel caso della poesia l'uso di una certa forma letteraria è visibile dal fruitore dell'opera, mentre nel caso di una demo l'uso di una certa forma di programmazione è invisibile dall'esterno. Questo non è del tutto vero perché tanti piccoli indizi possono rivelare ad uno spettatore attento i limiti che il coder si è imposto nel suo processo creativo. E poi questa obiezione non ha molta importanza, almeno per me: io non creo demo per farle vedere in giro, lo faccio per soddisfazione personale e io so benissimo quali sono i limiti che mi sono imposto. Esemplare è il caso di Beam Control che a tutt'oggi a quanto ne so rimane l'unico demo mai realizzato che permette di scegliere risoluzione e modo video di output (es. PAL, VGA, DBLPAL ecc.). Naturalmente come nel mio stile ho realizzato questo demo programmando direttamente l'hardware e non è stato per niente facile: ho dovuto studiare molto attentamente i registri BEAMCON0, HSSTxx, HBSTxx & C, ho dovuto curiosare tra le copperlist di sistema, ho dovuto fare tantissimi test su tanti diversi modelli di monitor. Inoltre, poiché la demo ha un'interfaccia utente, ho dovuto programmarmi da solo gadget e gestione eventi. Pur non essendo un espertone di Amiga come Manta sapevo perfettamente che avrei potuto ottenere gli stessi risultati con facilità estrema usando la OpenScreen di Intuition (o qualcosa di analogo RTG) e la GadTools (o la MUI !) per l'interfaccia utente. Ma a me non interessava il risultato, mi interessava cimentarmi con la difficoltà di realizzare il demo sfruttando esclusivamente le risorse messe a disposizione dall'hardware. E Beam Control, nonostante lo scarso interesse che ha suscitato nella scena, è delle mie opere quella che mi ha maggiormente soddisfatto, nonché il mio capolavoro tecnico. A mio avviso, dunque, le demo devono essere dipendenti da una particolare architettura hardware-software. Per questo motivo, a differenza di quanto sostiene Manta, non ritengo che una demo possa essere considerata obsoleta perché funziona in asm e in accesso diretto all'hardware. E' l'architettura scelta (680x0+AGA) che è obsoleta ma non il modo di programmare, che relativamente a tale architettura, è il migliore. Ciò non implica che nessuna demo è (tecnicamente) obsoleta. Per esempio considero obsoleta una demo in cui il coder utilizza una routine di rotazione vettori da 12 MUL, perché per la stessa architettura sono state sviluppate tecniche migliori. Ma una demo che si basa su tecniche di programmazione ottimali relativamente all'architettura utilizzata non è assolutamente obsoleta e tutt'altro che ridicola. Anzi è molto migliore di demo programmate male in C e RTG. Faccio peraltro notare che il concetto di dipendenza dall'architettura è parzialmente già accettato dalla scena, in quanto nei party ci sono compo separate per PC, Amiga e C=64 e credo che anche le demo PowerPC partecipino separatamente. Io non considero affatto obsoleto chi coda sul C=64. Per concludere, mi rivolgo direttamente ai coder. Se intendete realizzare un applicativo, un gioco o un qualsiasi programma commerciale fareste bene secondo me a seguire i consigli di Manta e ad utilizzare strumenti di sviluppo moderni (possibilmente RAD per gli applicativi) che vi permettano di sfruttare l'hardware più recente. Ma se invece quello che vi interessa è fare demo, se volete solo divertirvi programmando e mettendo alla prova le vostre capacità, allora dovete sentirvi assolutamente liberi di scegliere l'architettura che volete, infischiandovene di quello che pensa Manta e la massa di lamer che ha invaso il mondo dei computer (oh non intendo dire che Manta fa parte di questa massa, sia chiaro!). Anzi è fondamentale che scegliate un'architettura che vi piace programmare e che ispira la vostra creatività, perché per poter fare demo è indispensabile divertirsi a programmare. Altrimenti è solo tempo perso. Continuerò a sviluppare le mie tesi sul coding in un prossimo articolo, quindi invito chiunque abbia trovato questo articolo interessante a leggere anche l'altro. In ogni caso buon anno! {FONT 13}{COLOR 5}The Dark Coder