La roadmap per i client passa da Acropolis
Questa settimana è stata rilasciata la prima CTP di Acropolis: si tratta di un framework che andrà a fornire una piattaforma di sviluppo per i "rich-client" basata su WPF (oggi, ma supporta diverse UI - potenzialmente anche ASP.NET e Windows Forms) e orientata alle applicazioni business. Chi a DevCon ha seguito la sessione "WPF per il gestionale" avrà visto che WPF offre molte funzioni importanti per un'applicazione "business" (come il data binding) ma lascia molta libertà (senza offrire particolari strumenti e/o un pattern ben definito) per aspetti come l'interfaccia utente, la navigabilità, ecc.
Acropolis affronta molti temi, come la navigabilità e in generale lo stato dell'interfaccia utente, il disaccoppiamento tra "azioni" e "interfaccia", la separazione dalla "business logic" e molto altro ancora. L'aspetto interessante è che tutto l'approccio è molto dichiarativo, sfruttando xaml come "grammatica" descrittiva di elementi e operazioni ma senza legarsi indissolubilmente a una libreria particolare (come può essere WPF) come elemento portante dell'interfaccia utente.
L'elemento che mi preme sottolineare è la caratteristica di "programmazione dichiarativa" che emerge in questo framework. Stessa caratteristica che contraddistingue WPF, WF e LINQ, tanto per fare un esempio di tecnologie già rilasciate o prossime al rilascio. Una sessione (a TechEd) di Chris Anderson faceva riflettere sull'avvento di questo paradigma, che consente di avere una forma descrittiva di un programma a un livello più modulare e facilmente "manipolabile" di quella offerta dal codice. Oggi ci sono i mattoni fondamentali per intraprendere questa strada, in Microsoft ci sono molti team che stanno lavorando per costruire qualcosa intorno a questi punti di partenza, si può intuire come in un futuro a medio/lungo termine (5/10 anni, direi) il modo di scrivere il software evolverà in ambienti dove il "codice" come oggi lo conosciamo sarà sempre più legato a piccoli componenti, estremamente specializzati, eliminando di fatto la necessità di scrivere quel "plumbing code" che tiene insieme gli strati dell'architettura.
In realtà potrebbe tornare in auge il "programmatore VB6" con i programmi "all-in-one", creati però all'interno di un ambiente in grado di discernere a monte quello che è interfaccia utente da quello che è business logic da quello che è accesso ai dati. Sarebbero ambienti in cui non si scrive molto codice e soprattutto lo si scrive solo per compiti/operazioni assolutamente circoscritte e limitate. In realtà, non è impossibile pensare a un modello di programmazione in cui (stando all'interno di determinate regole e pattern) il "programmatore" non conosce al 100% l'ambiente in cui opera, ma riesce a realizzare il suo applicativo in maniera piuttosto immediata, senza però rinunciare a un'architettura sottostante in grado di evolvere nel tempo senza crolli improvvisi.
Per quanto possa sembrare strano, questo effetto non sarebbe un obiettivo primario ma piuttosto un effetto collaterale di una serie di evoluzioni che, sempre appoggiandosi a una forma di programmazione più dichiarativa che imperativa, offriranno la possibilità di:
- distribuire le operazioni di calcolo (dove il codice risiede diventa meno fondamentale)
- parallelizzare il carico di lavoro (scalabilità sia verticale che orizzontale, grazie al punto precedente)
- modularizzare l'architettura
Tutte cose che si possono (anzi devono) fare già oggi, ma a un prezzo ancora relativamente alto. E' un peccato che la PDC di ottobre sia stata rimandata, ma a questo punto il "salto" a cui assisteremo più avanti (se devo scommettere, direi entro un anno...) potrebbe essere ancora più grande. Il .NET Framework (e il CLR in particolare) resta in tutti questi scenari una colonna portante imprescindibile, più dello stesso sistema operativo (come Silverlight insegna).