Il conservatorismo e il provincialismo dell'università italiana sono purtroppo arcinoti. Per chi ha voglia di leggere c'è abbondanza di saggi in materia, da "Le mani sull'Università" di Felice Froio al recentissimo "Chi sono i nemici della scienza" di Giorgio Israel, il quale peraltro con cadenza regolare pubblica preoccupanti articoli su tali questioni (e non è certo il solo).Originariamente inviata da MItaly
In Italia esiste e resiste il mito atavico dell'ingegnere come supertecnico tuttofare buono per tutte le stagioni, anche a causa della presenza degli Albi e della relativa tradizione di impartire una preparazione eccessivamente generalista. La laurea in "ingegneria informatica", assieme ad un paio di altre specializzazioni, è stata introdotta a livello nazionale solo nel 1993: in regime di Vecchio Ordinamento, ma molto di recente. Le reali differenze tra un ingegnere rispettivamente elettronico, informatico e TLC andavano cercate col lanternino di Diogene: alcune specializzazioni ed orientamenti erano praticamente sovrapponibili dal primo all'ultimo esame. Il passaggio alle lauree triennali ha poi ulteriormente appiattito molte differenze. Il che è ovviamente assurdo!
L'ingegneria è un insieme di discipline applicative basate sulla conoscenza di risultati scientifici, ma soprattutto su vasti "body of knowledge" e "best practices", insiemi di esperienze pragmatiche e regole empiriche approssimate, accumulati dalla disciplina nel corso degli anni. Nelle specializzazioni "classiche" dell'ingegneria (edile, civile, navale...) la singola opera è unica e non serializzabile, non si possono apportare migliorie per tentativi o test distruttivi, si applicano solo simulazioni in scala e modellazioni approssimate, ed è richiesta la progettazione totale. Ovviamente le cose sono ben diverse parlando di ingegneria elettronica, informatica, controllistica... ma questo banale dato di realtà non pare riuscire a permeare le torri d'avorio del mondo accademico, quantomeno non in modo massiccio ed uniforme.
Allo stesso modo, è inconcepibile ammannire a degli ingegneri informatici interi corsi sulla teoria del controllo ancora concettualmente impostati come il manuale del Morris di buona memoria: quaranta lezioni su PID e sistemi continui, e nell'ultimo quarto d'ora un accenno all'esistenza dei sistemi di controllo logici. Non sembri un'iperbole: in Italia le facoltà che erogano davvero corsi di automazione incentrati (prevalentemente) sul controllo logico si contano sulle dita di una mano. Questo non significa certo trascurare i fondamenti teorici, ma semplicemente adeguarsi alla realtà.
Fino a pochi anni fa gran parte degli sforzi della formazione interna nelle aziende più grandi ed organizzate era rivolta a smantellare e ricostruire, in una infelice e costosissima maieutica socratica, la forma mentis di ragazzotti supponenti che sbarcavano in azienda con la tronfia convinzione che l'aver sostenuto obbligatoriamente esami inutili (spesso perfino deleteri) come scienza delle costruzioni e fisica tecnica in seno ad una laurea in elettronica o informatica avesse loro "aperto la mente". Taluni arrivavano ad ostentare perfino soddisfazione ed orgoglio una volta messi di fronte alle loro spaventose lacune specifiche in ambito logico, algoritmico e discretistico e perfino nell'ambito del controllo logico e delle reti di Petri, scimmiottando dai loro docenti più ottusi un'attitudine di albagia e sufficienza davanti a tali saperi, snobbati come "secondari" (evidentemente rispetto agli intricati quanto inutili sistemi di PDE o a quelle due/tre dozzine di trasformate, appresi con fatica) o addiruttura declassati al rango di "mero sapere applicativo", in una distorsione cognitiva tanto assurda quanto diffusa. Oggi, più che altro, si lavora formativamente per colmare lacune e misconcezioni.
Il problema dei linguaggi di programmazione, nello specifico, si riconduce facilmente ad un problema più generale: chi insegna determinate materie? Ad esempio, l'insegnamento della matematica nelle scuole di ogni ordine e grado è un disastro anche perché solo una risicatissima frazione del personale docente possiede una vera preparazione in didattica e filosofia della matematica (ebbene sì, è praticamente impossibile insegnare davvero in modo completo ed efficace l'essenza della matematica senza possedere una idea, magari anche informale ma solida, di cosa sono davvero gli enti matematici).
Allo stesso modo, l'economista o il fisico matematico, il biologo molecolare o il filologo messi ad insegnare C++, Java, Python o anche solo SPSS/Systat senza una specifica preparazione in software engineering e progettazione producono danni con probabilità p tendente all'unità. Scrivere software (vogliamo ripeterlo qui?) non significa certo arronzare insieme un po' di codice alla bell'e meglio per risolvere un problema contingente, ma saper scegliere la migliore soluzione algoritmica e di codifica in relazione alle specifiche, all'ambiente, ed ai parametri ingegneristici classici (es. robustezza, stabilità, mantenubilità, prestazioni...).
Rispondi quotando
