<sfogo enabled="true">Poco fa ho in chat con un altro dot-nettaro ho avuto una pacifica discussione tra quale linguaggio tra C# e VB.Net fosse meglio per programmare il Framework. La mia risposta è stata ovviamente il "C#", non perché ritengo questo linguaggio meglio del VB (giammai! lo utilizzo ancora!!!), ma per questioni di gusti, nient'altro. Nel 2001 avevo mosso i primi passi con VB e solo nel 2002 ero passato al C#. Il motivo? Curiosità forse...
Ma una frase ha lasciato interdetto il mio interlocutore, ed è stato quando me sono uscito con la frase:
"Perché con il C# si evita di scrivere del codice del c***o!".
Perché questa mia affermazione? Forse sono avvelenato, ma mi sono ritrovato tra le mani alcune volte - sempre troppe - codice VB che prestazionalmente era limitato solo dalla fretta, noncuranza, ignoranza (?!?!) di chi l'aveva scritto. Se c'è una cosa che mi fa inca**are quando vedo dei progetti e nel vedere che non è stato impostato né a livello di webapplication e nemmeno a livello di pagina lo strict a true per il controllo degli oggetti o addiruttura l'Explicit impostato su False!!! (Fortunatamente questo caso l'ho incontrato solo in una community!)
Sembra una sciocchezza per i neofiti, ma l'impostazione a true dello strict aumenta le prestazioni di tutta la webapplication. Mi è stato risposto che con quell'impostazioni compaiono numerosi errori nelle pagine, e piuttosto di ricorreggere tutto si prefersce tenere tutto così com'è. Anzi, mi è stato detto perché si dovrebbe scrivere il codice, per esempio:
<%# DataBinder.Eval(Contatiner.DataItem,"nome campo")%>Quando è sufficiente, lascianto lo strict su false, scrivere il tutto nel modo più semplice:
<%# Contatiner.DataItem("nome campo")%>Be', la differenza sta tutta in una coppia di parole: late-binding. Se inseriamo nel codice una variabile senza dichirarne il tipo, sarà compito del Framework, durante l'elaborazione della pagina, ha convertirlo correttamente nel tipo adatto, ma sprecando inutilmente cicli macchina nell'esecuzione quando la dichiarazione del tipo direttamente da codice fa eseguire questa operazione solo la prima volta durante la compilazione. Un piccolo tutorial a riguardo lo si trova sull'MSDN.
Mi sembra strano che non sia impostato a true di default neanche in Visual Studio lo strict per tutte le webappliction in VB.Net. Forse perché si pensa erroneamente che questo linguaggio sia adatto ai neofiti?
Oggi non è giornata.
</sfogo>
Il ragionamento di Andrea Zani non fa una piega, ma credo che questi errori grossolani siano dovuti ad una scarsa informazione che viene fornita ai neofiti come ad esempio potrei essere io che studio asp.net un po' a singhiozzo ma cmq è una materia che mi interessa.
Ho fatto un corso di VB.NET, ho comperato un paio di manuali piuttosto grossi e ad esempio queste opzioni come lo stict sono citate ma non gli viene data la giusta rilevanza, come dire "si lo puoi usare ma anche se non lo fai è lo stesso perchè fa tutto da solo".
Corsi dove ti preparano veramente poi...non sò quanti ce ne siano, tante volte sono improvvisati e devi ricorrere a internet per documentarti, ma anche qui, spesso trovi argomenti che partono già da un certo livello di preparazione e danno per scontato tante cose.
Certo chi è interessato, ci sbatte la testa e approfondisce tutto da solo ma quanti sono disposti a farlo? Secondo me bisognerebbe puntare di più sulla spiegazione delle basi che stanno dietro un linguaggio di programmazione senza dare per scontato mai nulla.
Questo è il mio pensiero espresso in maniera un po' veloce...
Marco
Ciao Marco,
hai toccatto il punto più importante: la grossolana e scarsa informazione che viene data alla cosa. Nei libri che ho avuto a disposizione sul .Net in molte occasioni lo strict viene solo menzionata come opzione, e in alcuni neanche viene citata. Nei libri sull'asp.net della Wrox, per esempio, viene trattato l'argomento, viene spiegata l'utilità della stessa ma non viene consigliato chiaramente il suo uso per le prestazioni; anzi, nel resto degli esempi del libro tutti gli esempi vengono fatti senza questa opzione.
A riguardo dei corsi, il loro scopo nella maggioranza dei casi è darti un'introduzione e il più delle volte gli argomenti vengono toccati in modo dozzinale. Un altro problema - se così vogliamo chiamarlo - è quello che citi sulla scarsa disponibilità di tempo da dedicare allo studio, ma in una società dove lo sviluppo dev'essere veloce e il tutto si basa sulla frase "L'importante che funzioni", non possiamo lamentarci oltre.
Per vedere cosa comporti questo è sufficiente leggere il blog di Ricciolo (http://blogs.aspitalia.com/ricciolo/post545.aspx) che ha trattato l'argomento in modo più tecnico (Cristian non mi delude mai!
) per vedere che codice viene prodotto da un semplice Response.Write. Ma facciamoci la domanda: se due persone inziano a interessarsi all'asp.net, uno dedica il suo tempo allo sviluppo in C# e l'altro in VB, quale dei due dopo un periodo di formazione scriverà il codice maggiormente performante?
Ricordo nel periodo dell'avvento del Framework quando si discuteva quale dei due linguaggi fosse più prestazionale. Le risposte pendevano tutte verso il C#, e pochi - forse quelli che avevano capito come funzionava il tutto - avevano risposto che non potevano esserci differenze visto che il tutto veniva tradotto nel linguaggio unico IL o le differenze potevano essere minime per l'ottimizzazione di codice tra i due compilatori. Se poi si confronta codice in VB lasciando che tutte le operazioni di conversioni vengano eseguite in latebinding il risultato è scontato...
Modificato da andrewz il 07 agosto 2004 09.43 -
Aggiungi un nuovo commento »»»
Per inserire un commento, devi registrarti alla nostra community.
Stampa 
Download 
10annidi.ASPItalia.com: iscriviti alla competizione e vinci fantastici premi ogni mese!
Commento di Daniele Bochicchio