CrossTalk, ovvero il giornale di software engineering del Dipartimento della Difesa americano (DoD), ha pubblicato nel numero di gennaio uno spunto interessante riguardante gli skill dei software engineer di domani. L’intervento è firmato da due professori del corso di Computer Science della New York University, nonché esponenti di spicco della comunità Ada attraverso AdaCore, fornitore di soluzioni Ada al DoD stesso (e non solo).
L’articolo ha un tono un po’ inconsueto e di fatto ha tutti gli elementi tipici di un rant, il che personalmente mi ha fatto un po’ specie, data l’autorevolezza dei personaggi in questione. Mi ricorda un po’ le lamentazioni di Bug Barbecue, uno dei personaggi più riusciti dei Microservi, altrimenti noto come “the World’s Most Bitter Man”, perennemente in preda a crisi di nostalgia per i bei tempi andati dello Xerox PARC.
Ci sono però alcuni elementi particolarmente degni di nota che vale la pena di sottolineare:
- gli autori denunciano la scarsa preparazione teorica degli studenti tipicamente sfornati dai corsi di CS, con uno schiacciamento dell’orizzonte sui soli temi di programmazione a discapito di una migliore preparazione matematica, della conoscenza di metodi formali di specifica e verifica di correttezza, ecc.;
- l’adozione di java come primo linguaggio di programmazione viene vista come una scelta particolarmente infelice, anche se comprensibile visti i trend attuali in ambito professionale.
Da un certo punto di vista non posso che essere d’accordo con Dewar e Schonberg: ogni software engineer degno di tale nome dovrebbe avere a cuore una preparazione a tutto tondo, senz’altro multidisciplinare. Allo stesso modo, dovrebbe non trascurare i principi e le meccaniche di base che ad esempio sottendono costrutti di programmazione in linguaggi di alto livello. Il bravo software engineer è innanzitutto un generalista onnivoro, in grado di muoversi su temi diversi in modo confortevole, dato un tempo adeguato di adattamento.
D’altro canto, gli strumenti di sviluppo, sia pratici che concettuali, si spostano sempre di più verso una maggior potenza a parità di espressività. Aritmetica dei puntatori e gestione dello heap sono senz’altro temi essenziali e ogni software engineer in nuce deve essere in grado di maneggiarli. Detto ciò, ben venga ogni semplificazione che consente di concentrarsi su design e architetture in modo omogeneo, senza compromettere il codice con tecnicismi ineleganti che assomigliano più a soluzioni rappezzate che a virtuosismi.
Hai idee per un articolo? 
Io non sono un grande programmatore ma quello che è stato detto su Java lo condivido.
Mi sono ritrovato a studiarlo adesso per un progetto e rispetto al C++, cui ero abituato, è veramente molto più semplice: puntatori e riferimenti impliciti, assenza di distruttori, un garbage collector che lavora per te, etc… è una pacchia per certi aspetti.
Condivido le affermazioni sulla preparazione degli studenti: sono convinto che il un linguaggio da imparare è sempre il C, per la possibilità che ti da di conoscere le problematiche di più basso livello.
E poi sono anche d’accordo sulla preparazione matematica, che deve essere solida e ferrata.
Se volete un punto di vista diverso leggete questo:
http://www.joelonsoftware.com/items/2008/01/08.html
Io ritengo che un programmatore possa ritenersi tale solamente nel momento in cui, trovatosi ad imparare un nuovo linguaggio di programmazione, il suo unico problema è quello di capire la sintassi che le librerie).
Ho visto troppi suddetti “programmatori” che messi davanti a del codice in un linguaggio “estraneo” non erano in grado di capire cosa facesse.
E l’università non aiuta. Se penso che in Bicocca (Informatica) stanno adottando .Net e Java “perché prepariamo per il mondo del lavoro” ignorando che nel 90% dei casi quello che viene imparato è quello citato nell’articolo: assemblare più o meno a caso codice altrui.
Degno di nota comunque, sempre in Bicocca, che almeno è presente un corso di base per Lisp e Prolog. Non eccezionale, ma almeno qualcuno ci prova.
io l’unica cosa relativa a modelli formali di costruzione, derivazione & verifica del software l’ha trovata per sbaglio facendo la tesi con NesC.
Ing inf alla Sapienza, tre esami alla laurea e due ordinamenti universitari alle spalle. Ma forse ero io che ero distratto.
Un po’ dipende da come è impostato il programma di una certa università. A Padova Ingegneria, per esempio, c’è molta teoria formale, sia matematica che algoritmica e su più livelli: dalla combinatoria all’algebra, dai modelli per valutare gli algoritmi allo studio dei linguaggi formali è tutto un fiorire di teoria.
Peccato che manchi un bel corso di C/C++ (cosa che tentano di inserire a forza all’ultimo anno in un corso di sistemi operativi real-time con scarso successo).
Ciao,
Un altro punto di vista interessante è quello espresso da McConnell in Professional Software Development: ci sono aree della professione di sviluppatore che vengono spesso ignorate dai programmi universitari: testing, software configuration management ed in generale ciò che concerne il lavoro di gruppo. In generale, poter attingere ad una molteplicità di linguaggi (il più possibile diversi da loro – io su questo sono stato fortunato) per risolvere determinate classi di problemi aiuta, decisamente.
Alla fine la lezione che si impara è che nessuno ti insegna tutto, e che c’è un mare di roba “là fuori” da imparare, tra cui bisogna imparare a muoversi, in un modo o nell’altro.