E' tutto così semplice ?
In questo post, Shawn Van Ness sottolinea come spesso l'idea di sviluppare codice che gira nelle amorose braccia di un runtime intelligente produca nel programmatore una sorta di "abbandono": ci pensa il CLR, quindi perchè preoccuparsi tanto ?
Vero nel 90% dei casi (la percentuale la butto lì, comunque vero molto spesso), ma in alcune situazioni di qualcosa bisogna anche prendersi carico.
L'esempio di Shawn evidenzia la necessità di analizzare il valore di ritorno delle funzioni Win32 invocate con P/Invoke. Secondo me la problematica è molto più generale.
Sviluppare in .NET è semplicissimo.
O no ?
Vi racconto la storia di Pino, vecchio programmatore C++ ma vero novizio di .NET. (Pino è un nome inventato !)
Pino deve sviluppare un gestionale e, per ragioni diverse che non sto ad elencare, lo vuole fare in C#.
Apre VS.NET e scopre l'editor stile VB6. Pino è abituato a message pump e WM_PAINT, e non gli sembra vero quello che vede.
Mette un paio di controlli, fa doppio click su un bottone e gli si apre la finestra di codice con un handler già bello e pronto, insomma, facilissimo !
Così in 4 e 4 8 fa un sacco di form (coloratissime, di solito la prima cosa che si fa è iniziare a cambiare colore ai controlli, e viene fuori un guazzabuglio che fa venire la nausea solo a guardarlo ...), fa un paio di chiamate al provider dati e ottiene un Dataset pieno di roba, due tocchi di databinding ed ecco che il gestionale che doveva essere pronto dopo 1 mese è già fatto, e in soli 4 giorni di lavoro ! Chissà il capo di Pino quanti complimenti che gli farà ... bravo Pino, sapevo che potevo contare su di te, ti darò più responsabilità all'interno del gruppo, eccetera eccetera.
Poi Pino inizia a testare un po' meglio il suo applicativo. La ditta è piccola, il reparto di test non esiste (qui non vorrei aprire un capitolo che meriterebbe non un post, ma un libro intero, e magari lo hanno già scritto. Intanto date un'occhiata qua), quindi ci pensa lui.
Funzionicchia, però Pino si accorge che la memoria occupata sale un po' troppo, diciamo che va oltre ai 100Mb e continua a crescere, piano piano.
Che fare ? Una rapida occhiata all'MSDN e Pino trova la documentazione della classe System.GC, vede il metodo Collect, gli piace e lo chiama. Niente da fare, non funziona.
Pino iniza a preoccuparsi. La colpa è sicuramente di quest'accidenti di gestione automatica della memoria. Almeno in C++ si facevano delle belle new e le realtive delete, tutto sotto controllo, nessun problema, nessun consumo. Questo .NET proprio non funziona, è mal fatto, non va bene per applicazioni critiche (notate che Pino sta sviluppando un "critico" gestionale !).
Basta, Pino rinuncia.
Riapre VS6, usa MFC. "Però, che brutto rispetto alle Form .... ma in compenso ho controllo su quello cha faccio", pensa Pino mentre inizia a sbattersi con la MESSAGE_MAP e le DDX.
Pino, alla fine, ha consegnato il suo gestionale, fatto in MFC e ADO, con pochi giorni di ritardo, quelli persi a provare a farlo in C#. Il suo capo è stato comprensivo, ma ben lontano da fargli i complimenti: l'interfaccia è scarna e al cliente potrebbe non piacere granchè.
"Però almeno funziona", pensa Pino, che si mette a studiare sul Prosise come migliorare l'aggiornamento di una ListView.
Qui finisce la storiella di Pino.
Pino non esiste, o meglio, credo esistano diversi Pini in giro per il mondo.
Alcuni desistono ai primi problemi e ritornano sui propri passi. Sono quelli un po' più esperti, che sono abituati a fare anche un po' di profiling durante lo sviluppo. Ma noi sappiamo che Pino era un esperto programmatore C++, quindi non ci stupiamo della sua scelta.
Altri scrivono quintalate di righe di codice. Di solito se ci dai un'occhiata trovi 4 o 5 metodi che si chiamano button1_Click o simili, con 1000 righe di codice procedurale per ciascuno. Non sto neanche a dire cosa succede quando si inizia ad incartare qualcosa.
Comunque hanno in comune il fatto di non aver studiato le nuove tecnologie prima di usarle, e di aver pensato che sarebbe bastato leggersi un po' di documentazione durante la codifica per far funzionare tutto con prestazioni ottimali.
Morale della storia: le ditte che hanno dei Pini fra i loro dipendenti hanno avuto un'esperienza negativa nel passaggio alla tecnologia .NET (alla fine Pino era uno dei migliori sviluppatori che avevano, chissà cosa possono combinare quelli un po' più mediocri), quindi il salto non lo effettuano. Il C++ va benissimo, funziona bene da che mondo e mondo, perchè cambiare ?
Credetemi, non è così inverosimile.
CUNext