Non è facile. No di certo. Avere cinque serie di esercizi obbligatorie da fare a settimana non è una passeggiata. In più si è aggiunto il mio errore di inizio semestre: avevo deciso di smettere di lavorare ogni giorno alle 5, per potere disegnare il pomeriggio, e recuperare durante il weekend lavorando almeno il sabato con orari normali (pressapoco 8-17). Smettere di lavorare non è difficile... Ma recuperare dopo, per un motivo o per l'altro, durante i primi weekend del semestre non ci sono riuscito. E così mi sono trovato indietro colle cose da fare, una situazione che più di molte altre riesce a devastarmi psicologicamente. Per la prima volta è emersa la paura di non farcela...

In poche parole, ho avuto qualche giorno di crisi, peggiorata dal fatto che un weekend intero passato a studiare non è bastato per recuperare. Il fondo l'ho toccato martedì scorso, dove sono stato sveglio fino alle 4 e mezza per finire una serie che dovevo consegnare il giorno dopo. Mi si imprimono nella memoria quegli attimi di lotta interiore: "Non capisco niente! Non ce la faccio!" e vedere che è passata un'altra ora. Non so da dove viene la forza che uno trova in quei momenti. È qualcosa di super-umano, di impietoso, che ti trascina, che se ne frega della tua frustrazione, che ti porta a riprendere in mano i fogli buttati via con rabbia, ancora e ancora.

Fortunatamente per me l'attimo peggiore era passato. Il giorno dopo ho sentito che era possibile, e ho capito che dovevo smetterla almeno per un po' di fare stupidi piani, e ho cominciato a lavorare praticamente costantemente, dalla mattina alla sera. Al momento non ho ancora raggiunto il mio obiettivo, ma sento finalmente di poter respirare di nuovo.

Ma passiamo ai contenuti. Le materie di questo semestre sono decisamente interessanti. Quelle puramente matematiche si sono ridotte ad una: Analysis II, sempre con M. Struwe. Se c'è una materia dove vado incontro ai miei limiti allora proprio questa. Di carattere sono uno che vuole capire le cose à fond, ma la mancanza di tempo mi ha già spinto diverse volte a rinunciare e a focalizzarmi su "come si fanno gli esercizi". Del resto è il modo con cui è impostata la lettura che spinge in quella direzione: le ore di esercizi si focalizzano sulla parte pratica, mentre le lezioni vere e proprie partono asintoticamente verso alte sfere empiree, e alcuni hanno smesso di andarci, e sospetto anch'io che per passare l'esame non sia veramente necessario aver visto tutte quelle dimostrazioni.

È cominciato anche il mio primo ed ultimo semestre di Fisica, che durante il liceo avevo un po' abbandonato. Il prof. J. F. van der Veen è riuscito ad interessarmi (nonché a divertirmi - dev'essere qualcosa di genetico a rendere i fisici così...). Una fortuna che alleggerisce un po' il peso del viaggio da fare per andare dal HG (Hauptgebäude) all'Höngg (L'enorme "science city" fuori città, secondo nucleo del politecnico). Penso che ogni maestro di fisica si scioglierebbe di fronte all'armamentario di utensili e oggetti dimostrativi che hanno lì all'Höngg: finora abbiamo visto (brevi) esperimenti ad ogni lezione! Al momento stiamo ancora parlando di meccanica, ma visto il nostro indirizzo ci focalizzeremo su elettrodinamica.

Design of digital circuits con S. Capkun è proprio la materia che uno si aspetterebbe di trovare immaginandosi di studiare informatica. Infatti si tratta del funzionamento del computer a partire dalle minime cose come numeri binari, transistors, circuiti, porte logiche... e andremo avanti fino a capire come funziona un processore. È il tema più low level (dopo la fisica) che affronteremo, visto che l'informatico si concentra essenzialmente sul software.

Con Parallele Programmierung comincia davvero a farsi interessante. In questa lettura impariamo le basi della programmazione parallela, la capacità cioè di eseguire più programmi o parti di un programma alla volta, appunto, parallelamente. Questa disciplina si è resa sempre più necessaria, perché la densità dei transistor all'interno dei processori sta per raggiungere il limite del fisicamente possibile, ergo la potenza dei processori non aumenterà ancora per molto. Da qui la necessità di più "cores" (quad core e via così), cioè più nuclei/processori, da far funzionare in parallelo. La buona notizia è che l'intelligenza dell'informatico si rende sempre di più necessaria e non può più essere sostituita da semplice potenza hardware: bisogna scrivere programmi che siano in grado di sfruttare le nuove possibilità di questi cores. E non è facile, ci sono molte cose da considerare, come la distribuzione dei compiti tra threads (processi), la sincronizzazione, la comunicazione ecc.

Per finire, questo semestre approfondiamo finalmente quello che si può definire l'informatica teorica: Algorithmen und Datenstrukturen (Algoritmi e strutture dati). Presentata dal prof. P. Widmayer come la "scienza della risoluzione dei problemi", l'algoritmica la vivo come una specie di secondo capitolo della "matematica discreta" (vedi Abstraction love). È la materia più interessante che ho al momento, anche se per niente facile. Essenzialmente un algoritmo è una serie di istruzioni ("esci di casa", "x := 0"...), condizioni ("se non piove", "if x < 9"...) e cicli ("continua a camminare finché non sarai arrivato", "while (x < 9) x := x + 1") che nel loro insieme servono ad ottenere un determinato risultato ("Arriva a scuola senza bagnarti", "x = 9"). Di un algoritmo si può misurare l'efficienza, e la parte difficile è proprio, dato un problema, trovare l'algoritmo più efficiente.

Un algoritmo è indipendente dal linguaggio di programmazione, e dovrebbe poter essere implementato in qualsiasi linguaggio. In generale si usa lo pseudocode, che assomiglia soltanto ad un linguaggio di programmazione, e serve solo a rendere chiara la struttura dell'algoritmo. Se poi lo si vuole vedere funzionare, un algoritmo si può poi implementare in qualsiasi buon linguaggio di programmazione. Io sto usando java (con eclipse), e per il momento mi trovo bene. Per ora i tipi di problemi incontrati sono: ordinare una lista di numeri, trovare un elemento in una lista di numeri.

A permettere di operare in modo efficiente non sono solo gli algoritmi, ma anche le strutture dati colle quali questi algoritmi operano: tipico è l'esempio linked list vs. array. Entrambe sono una lista di elementi, ma nella prima è facile accedere al primo elemento (linkedList.first), e dato un elemento accedere al prossimo (element.next), mentre nella seconda è facile accedere ad un elemento qualsiasi sapendo in quale posizione (i) si trova (array.get(i)). Quando si tratta di eliminare un elemento da una linkedlist, ci vuole tanto per trovarlo, e poi è facile eliminarlo (basta collegare il precedente col seguente). In un'array invece è facile trovarlo, mentre ci vuole tanto per eliminarlo, perché bisogna spostare di un posto tutti gli elementi successivi.

Malgrado tutto, ciò che sto studiando è molto interessante, e sono già curioso di vedere come sarà nei prossimi anni, anche se per il momento non posso permettermi di guardare troppo avanti (la famigerata Basisprüfung occupa quasi interamente il campo visivo...). Se questa settimana riesco a lavorare abbastanza da poter tornare finalmente in Ticino sono soddisfatto, almeno per un po'.