In questi giorni i fervori della politica italiana alzano gli scudi contro l’ordinanza presentata in Parlamento dal giudice Clementina Forleo la quale – meno male – chiede di poter utilizzare le intercettazioni telefoniche, relative alle scalata di Unipol su BNL, nei procedimenti penali.

Scudi alzati, dicevo, perchè tra gli intercettati vi sono esponenti di primissimo piano del nostro palcoscenico politico. Inutile dire che i toni – giudicati da requisitoria – del giudice, non avrebbero avuto la forza di smuovere nemmeno un sassolino se l’intera vicenda coinvolgesse solo comuni cittadini.

Invece, da apparato autoreferente quale è, l’intero nostro arco parlamentare (con ovvio maggiore impegno dei diretti interessati) giudica l’azione della Forleo quale indebita ingerenza nella vita politica italiana, una sorta di supplenza giudiziale con la quale si vorrebbe far sparire una parte importante dell’entourage dirigenziale del nostro governo.

E’ quantomeno singolare che le difese arrivino proprio da quella parte politica che non ha mai smesso di sostenere la validità, la cristallina trasparenza e la inequivocabile correttezza dell’operato della magistratura durante l’intera legislatura precedente. Tuttavia questa non vuole essere una difesa della destra (o centro-destra o come diamine si chiama): non ce ne è bisogno e sarebbe quanto meno inopportuno.

Il problema che vedo e che sempre più mi disgusta è l’eclatante utilizzo di due pesi e due misure nel giudicare l’operato dell’apparato di giustiza: se non ci riguarda o se riguarda l’avversario è tutto corretto, se ci riguarda direttamente allora si tratta di atti indebiti e di accanimento politico. Tutto questo è di uno squallore devastante: non uno dei politici coinvolti ha avuto il buon gusto – quantomeno – se non la correttezza di stare zitto dando seguito alla sempre tanto declamata fiducia nel corso della giustizia. Almeno questo, credo, è dovuto in primis ai cittadini tutti e poi al proprio elettorato di riferimento.

Non mi sognerei nemmeno di chiedere pubbliche ammissioni e scuse da parte degli interessati dal momento che ciò andrebbe direttamente contro al sacrosanto diritto alla difesa garantito ad ogni cittadino, ma almeno un po’ di sane “orecchie basse” potrebbero dare un minimo di credibilità in più ad una dirigenza di stato che ormai ne è quasi completamente priva.  Mi nausea la sola idea che si vogliano attribuire valori sarcastici a battute telefoniche (regolarmente intercettate) con gli attori delle vicende in questione (e poi perchè si telefonavano ? perchè si tenevano informati l’un l’altro ?) perchè la cosa che non riesce ad entrare nella zucca di questi nostri politicucci da 4 soldi (ormai i politicucci del quartierino) è che la loro immagine è la rappresentanza di tutti gli italiani che li hanno eletti, non la loro.

Accettare di essere attori, di primo piano, della vita politica italiana (anzi sarebbe meglio dire ambire, dato che i privilegi garantiti a costoro non configurano certo una scelta di sacrificio) significa mettere se stessi sotto una lente di ingrandimento, sotto osservazione continua da parte della pubblica opinione e, non dimentichiamolo, degli organi che controllano l’osservanza delle leggi in tema di amministrazione della res-publica.

Ed è ancora più scandaloso il fatto che, in assenza di valide motivazioni e giustificazioni che potrebbero rendere quantomeno plausibili (definirli leciti sarebbe troppo) gli atti contestati, si vogliano attribuire al GUP Forleo motivazioni di attacco che nulla hanno a che vedere con le questioni legali in corso di accertamento. Se il giudice non avesse utilizzato quelle espressioni nella documentazione presentata, non avrebbe avuto motivo di presentare alcunchè restando pacifico il fatto che in assenza di fatti penalmente rilevanti il giudice non avrebbe richiesto nessuna autorizzazione a procedere.

Mi rivolgo a Lei, giudice Forleo, formulandole tutti i migliori auguri per un sereno e tenace perseguimento della verità dei fatti: che almeno questa sia un’occasione per certificare la correttezza della nostra politica o, verosimilmente, per farci aprire gli occhi e mandare finalmente questa masnada di parolai … a casa.

Quasi tutti i programmatori che abbiano basato le loro applicazioni web su ASP (VBScript) arrivano prima o poi a porsi seriamente questa domanda nel momento in cui devono partire con un nuovo progetto. La risposta, almeno nel mio caso (o meglio per l’azienda per cui lavoro), non è proprio facile e merita un qualche approfondimento.

Innanzitutto è bene sgombrare il campo da inutili allarmismi riguardanti la prevista morte futura del supporto ASP Classico sulle piattaforme Microsoft. Dal momento che IIS 7.0 supporta ASP classico perfettamente (con qualche accorgimento come spiegato in questo Tips and Tricks for Classic Asp Developers on IIS 7) è lecito pensare che la deadline di ASP classico sarà portata in avanti almeno fino al 2017 il che, rispetto alla data attuale, mette a disposizione un’ulteriore finestra di 10 anni per prendere una decisione.

Il problema quindi si sposta automaticamente sulle differenze di contenuto tecnologico offerte dai due linguaggi, anche se, è bene dirlo, è assolutamente improprio tentare di mettere sullo stesso piano di “linguaggio” le due modalità. Sono infatti profondissime le differenze tra i due e lontanissimi i presupposti su cui si basano.

ASP classico è un linguaggio di scripting: ovvero una sequenza di istruzioni scritte su normalissimi file di testo (modificabili con un qualsiasi editor – a me piace moltissimo Crimson Editor) che vengono interpretati al volo (on-the-fly) da una dll di sistema, la ASP.dll. In quanto tale la sintassi prevista per le pagine ASP (Active Server Pages) è una qualsiasi tra quelle supportate da Microsoft ovvero VBScript, JScript e PHPScript anche se la stragrande maggioranza dei casi di utilizzo prevede l’impiego di VBScript

ASP.NET (aspx), al contrario, è una completa riprogettazione del modello Active Server Pages basato sull’utilizzo del Framework .NET (versione 1 oppure 2): il codice scritto (che può essere implementato nel linguaggio che si ritiene più consono : VB, C#, C++, J#) non è più interpretato ma “tradotto” in un linguaggio intermedio (MSIL – Microsoft Intermediate Language) le cui istruzioni vengono direttamente elaborate dal framework .NET. Molti credono che le pagine ASP.NET siano pagine compilate (ovvero dei binari in linguaggio macchina) ma ciò non è vero e può indurre a conclusioni errate. Il prodotto di compilazione di un codice .NET è, come detto, di fatto una traduzione che ha bisogno comunque di un ambiente di run-time per poter funzionare: il framework .NET appunto. Per i programmatori VB (pre .NET) è immediata l’analogia con lo pseudo-code di VB che necessitava delle librerire VBRun per poter funzionare.

Ma la vera rivoluzione copernicana, di fatto quella che crea i maggiori problemi di approccio ad ASP.NET per i vecchi programmatori ASP, sta nella completa rivisitazione della sintassi e della struttura del codice. Mentre con ASP classico si è abituati a pensare al normale flusso di programma top-down, con ASP.NET bisogna cambiare completamente il proprio approccio alla progettazione ed allo sviluppo: le classi diventano l’oggetto atomico del codice.

In aggiunta a ciò è anche utile osservare che mentre VBScript è una versione light del supporto Visual Basic con un numero molto limitato di funzioni e quasi nessun oggetto nativo (per algoritmi complessi infatti i programmatori devono spesso riferirsi ad oggetti COM esterni), ASP.NET è un VB pieno (oppure un C# pieno ecc) con tutte i modelli di oggetto (e relativi metodi e proprietà) offerti dal framework .NET: in altre parole, e semplificando all’estremo, con i linguaggi .NET praticamente non si ha bisogno d’altro. Per rendere l’idea è un po’ come avere un coltellino svizzero con solo una lama ed un paio di forbici (VBScript) contro un utensile con 5 lame diverse, forbici per la carta e per la plastica, un set completo di brugole, cacciaviti di varia natura, chiavi inglesi e chiavi tubolari, seghe, martelli e chi più ne ha più ne metta ( .NET ). Tutto questo, ovviamente, rende più difficoltoso l’approccio al linguaggio quanto meno sotto il profilo dell’apprendimento mnemonico di tutti gli spazi dei nomi. Come se ciò non bastasse ogni singolo metodo può disporre di diversi override (ovvero modi di invocare il metodo con sequenze di parametri diverse) il che ha reso, nel mio personalissimo caso, praticamente impossibile avvicinarsi alla programmazione .NET senza l’ausilio di un IDE Microsoft con tanto di intellisense: per fortuna Microsoft ha reso pubblicamente disponibili e gratuite le versioni “light” del suo celeberrimo Visual Studio grazie alle versioni Visual Studio Express.

Fatte queste debite e stringatissime premesse, è forse ora di cominciare ad analizzare i perchè di una scelta a favore di ASP Classico o di ASP.NET per l’avvio di un nuovo progetto. Ci tengo però a sottolineare che le domande e risposte che sto per proporvi si basano sull’assunto di un approccio ad un progetto di sviluppo di medio piccole dimensioni: l’analisi di un progetto di grandi dimensioni che abbia tempi di sviluppo e manutenzione molto lunghi, elevate complessità e necessità di integrazione particolarmente articolate, potrebbe (anzi sicuramente richiede) un’analisi completamente diversa.

• ASP non sarà più supportato molto presto: come visto questa affermazione non è vera e anche se non è realistico pensare che una nuova applicazione ASP potrà vivere in eterno, è sicuramente verosimile affermare che il problema, al momento, non si pone.
• ASP.NET è più potente di ASP: in linea di massima ed in via assoluta di principio questo è vero ma nello sviluppo di un progetto conta anche (forse soprattutto) la potenza del team di programmatori. Una squadra ASP già rodata e con diversi progetti alle spalle disporrà certamente di un repository di codice già bello che pronto, testato e rivisto più volte, conosciuto a menadito che li renderà molto spediti nello sviluppo. Al contrario se il team si trova alla sua prima esperienza di sviluppo allora perchè non spendere un po’ di tempo in formazione su .NET ?
• ASP.NET consente uno sviluppo visuale: questo è completamente falso. E’ possibile scrivere applicazioni ASP.NET con un semplice editor di testo anche se si potrebbero incontrare le difficoltà di cui ho detto sopra. Ciò che rende possibile lo sviluppo visuale è Visual Studio (appunto) e nel caso in cui (come vedremo oltre) non sia possibile affidarsi alle versioni Express è necessario prepararsi ad un discreto esborso di denaro per acquisire la versione full. Tra l’altro lo sviluppo visuale non è sempre un bene: il codice generato automaticamente da VS per, ad esempio, un posizionamento assoluto degli oggetti su un form non è proprio il massimo. Preferisco ancora avere il controllo dell’HTML prodotto … anzi dell’intero codice senza routine nascoste.
• ASP.NET è più veloce perchè è compilato: si e no. Innanzitutto abbiamo visto sopra come il prodotto di una compilazione ASP.NET non generi propriamente un binario eseguibile. D’altro canto è anche vero che la velocità di esecuzione di diverse routine è assai più veloce (basti pensare alla concatenazione di stringhe). Eppure mi chiedo … la velocità di una applicazione da cosa è data ? Sono molti i fattori che concorrono. Se pensiamo all’esecuzione del codice server dobbiamo anche pensare al numero di istanze da sopportare ognuna delle quali occupa memoria: un’occupazione di memoria minore (ASP) permette un maggior numero di thread prima che, ad esempio, il sistema inizi a far largo uso della memoria SWAP e quindi a far degradare in generale le performance. Con ASP.NET i processi server che sottendono alla esecuzione del codice .NET sono molto più dispendiosi e quindi raggiungono una massa critica molto prima. Inoltre è bene notare che quasi sempre i punti di criticità maggiore stanno nelle pesanti query sui database che nulla hanno a che vedere con l’adozione di un linguaggio basato su .NET o di scripting.
• Con ASP.NET si usano interfacce AJAX di ultima generazione: vero ma questo si può fare anche con ASP Classico. AJAX è una tecnica mista di codice client e di processi server che dialogano attraverso flussi XML. AJAX non è legato a doppio filo con .NET. E’ vero invece che esistono moltissimi componenti di interfaccia utente (griglie, tabs, combo ecc) implementabili dall’interno di Visual Studio con dei semplici drag-and-drop ma la quantità di codice autogenerato mi piace sempre meno e non sono sicuro che sia ottimizzato per tutte le situazioni.
• Le applicazioni ASP.NET sono compilate e quindi non manipolabili dai clienti: solo parzialmente vero. Programmatori esperti potranno sempre decompilare gli assembly generati. Anche se il vostro cliente non lo farà non è detto che il vostro codice sia al sicuro come in una cassaforte. Inoltre la “compilazione” (e relativo deploy dei soli assembly) comporta, quale rovescio della medaglia, che per fare modifiche anche infinitesimali dovrete sempre avere a disposizione l’intero codice (in ufficio), compilare il tutto, e mandare l’applicazione compilata al cliente. Con ASP classico vi basta notepad dal cliente e … voilà.
• Con ASP.NET si mantiene il controllo di stato: anche con ASP Classico. ASP.NET è solo un modo di produrre codice HTML che verrà interpretato dal browser client. Le comunicazioni HTTP non hanno cognizione di stato. Il solo “valore aggiunto” di ASP.NET in questo ambito è la memorizzazione delle informazioni di stato nel campo nascosto _VIEWSTATE: ad ogni post del form, l’intero contenuto di _VIEWSTATE viene ritrasmesso al server il quale ricreerà la situazione di stato antecedente la richiesta e quindi elaborerà i nuovi dati inviati. E’ un giochino che si può implemetare tranquillamente anche con ASP Classico (ecco qui un bel Framework per ASP Classico).
• ASP.NET fa più scena: parrebbe una considerazione inconsistente ma nella realtà dei fatti è spesso (non sempre) talmente vera da annullare tutti i “contro” elencati fino ad ora.  Un nuovo cliente (poco esperto) sarà sempre benevolmente impressionato dall’adozione di tecnologie di ultima generazione per il solo fatto che … sono di ultima generazione. Fa figo (perdonate l’espressione) sbrodolare che si sviluppa in ASP.NET anzichè in ASP Classico (magari diffamando il caro vecchio ASP che ci ha dato da mangiare per tanti anni): e questo in genere accade ogni volta che non si hanno argomenti a sostegno della bontà della propria applicazione in termini di efficacia e funzionalità.  L’esaltazione della tecnologia adottata mettendo in secondo piano le peculiarità del prodotto è sempre una pessima tecnica commerciale.

Per ora mi fermo qui … ogni commento è bene accetto.

Ormai anni fa – forse più di 15 – mio Padre mi chiese un piccolo bigino per scrivere applicazioni con MS Access. Era una guida estremamente rozza, ridotta all’osso e con quelle poche funzioni indispensabili per un programmatore quale era (nel vero e più puro senso della parola) che, arrivato dalla programmazione in RPG su sistemi IBM S/36 e S/38, creava applicazioni complesse con il solo uso di miriadi di maschere e query.

Spesso mi sono confrontato con lui sulla “eleganza” delle sue soluzioni: la lezione che ne ho ricevuto è che non importa se hai scritto in modo ineccepibile un codice, l’importante è che faccia ciò che deve fare ovvero ciò che il cliente chiede.

Probabilmente non servirà più a nessuno ma … ecco il Piccolo bigino per programmatori MS Access