Sulla nuova piattaforma, Microsoft ha scelto di creare un nuovo linguaggio, più semplice del C++, come Java, e più completo e flessibile di Visual Basic, mentre il linguaggio più immediato, si è adattato alla piattaforma, assumendo molti dei meccanismi di C# e diventando Visual basic.net.
La semantica più evoluta si è riflessa in un linguaggio maggiormente complesso, diventato ulteriormente verboso rispetto alla versione precedente. D’altra parte, Visual Basic non è mai stato un linguaggio in grado di creare una piattaforma: chi ha provato a strutturare un’applicazione con qualche centinaio di oggetti, se ne è pentito amaramente.
Il risultato è stato interessante: molte nuove possibilità per gli sviluppatori più evoluti e un piccolo ghetto per chi non ha seguito per tempo la direzione del vento. Per qualche ragione Microsoft non ha voluto creare un linguaggio limitato, con meno opzioni, adatto per lo scripting di controlli scritti da altri, ma ha tentato di rendere Visual Basic un linguaggio sullo stesso piano di C# realizzando alla fine qualcosa che non è né più semplice né più coerente del linguaggio di riferimento.
Strategie evolutive
Eric Nelson, che ha un blog su Msdn dedicato a Visual Basic dal significativo titolo di GOTO 100, suggeriva nel 2008 un modo di affrontare il problema del futuro di un’applicazione legacy: il valore di business (la specificità del problema che risolve) e la qualità del prodotto. Si crea una matrice con quattro zone: nella zona vicina all’origine, quella in cui situiamo applicazioni per uso generico di bassa qualità , l’opzione migliore è sostituire l’applicazione, trovare un altro prodotto che fa lo stesso lavoro e non ha piombo sulle ali. Se l’applicazione è generica, esiste sicuramente un ventaglio di offerte equivalenti e il cambiamento non sarà pesante.
Se ci spostiamo verso destra sull’asse della qualità , entriamo nella zona in cui conviene continuare a usare l’applicazione com’è. Se la qualità è soddisfacente, possiamo fidarci della continuità del supporto per le applicazioni legacy da parte di Microsoft e non investire fino a quando non sarà strettamente necessario.
Se invece un’applicazione è fortemente specifica, quindi ha un valore di business elevato, e la qualità è bassa, vale la pena di considerare di riscrivere l’applicativo. Prima o poi toccherà comunque riscriverlo e non conviene perdere tempo, inoltre, potendo usare l’applicativo esistente come una specifica corretta delle necessità di business, avremo un progetto ideale, quello in cui le uniche difficoltà sono quelle tecniche. Naturalmente, ci sarà da decidere in quale direzione muoversi nelle scelte architetturali.
Infine, quando la qualità è buona e il valore di business alto, può convenire, secondo Nelson, sperimentare con una migrazione dell’applicazione sulla nuova piattaforma. Se la qualità del codice è alta, incontreremo meno trappole sulla strada, ma la domanda è se e come si può considerare un processo di traduzione. Analizziamo la situazione caso per caso.
[box type=”shadow” ]Le tre strade per abbandonare Visual Basic
➜ Caso 1, non fare nulla
➜ Caso 2, riscrivere
➜ Caso 3, eseguire il porting
[/box]