PNL02 - Discussione sul futuro di CLR
Interessante panel di discussione con questo gruppetto di esperti (in ordine da sinistra a destra nella foto):
- Anders Hejlsberg
- George Bosworth
- James Miller
- Jonathan Hawkins
- Patrick Dussud
- Chris Brumme
- Sean Trowbridge
- Brad Abrams
Tanti argomenti interessanti, riporto alcune delle cose che mi hanno più colpito.
CLR nel sistema operativo: non è una cosa di Longhorn, la si valuta più avanti... L'idea (siamo solo a questo stato) è di avere due versioni del CLR, una nel kernel (bassa latenza, utile anche per scrivere i driver!) e una "normale" per le applicazioni. Se ho capito bene, è un progetto che qualcuno in Microsoft Research sta valutando. Brad Abrams è intervenuto sull'argomento affermando che in futuro (ma non ancora in Longhorn!) il sistema operativo potrebbe essere completamente managed, affidandosi per compatibilità con Win32 a VirtualPC (immagino un VirtualPC che opera a livello di singolo processo, ergo di singola finestra di primo livello sul desktop...).
Problema di scaricare gli assembly senza tirare giù AppDomain: non è una cosa che prevedono nel breve termine, le implicazioni sono troppo grandi e ci sono troppi problemi correlati; la soluzione resta il caricamento di un assembly in AppDomain separati, con la relativa comunicazione cross-AppDomain.
Jim Miller ha ribadito le priorità che hanno, nell'ordine:
- Performances
- Security
- Features
Opinione di Anders Hejlsberg su AOP (aspect oriented programming): ok per Debug, Trace e Instrumentation, ma non va bene come sistema generico di programmazione, è difficile capire cosa sta facendo il codice, che diventa (paradossalmente!) difficile da debuggare.
Chris Brumme segnala l'esistenza un'interfaccia (unmanaged) per consultare i lock impostati sugli oggetti del CLR. Può essere utilizzata per realizzare sistemi per aiutare l'individuazione di un deadlock, ma non è un sistema da usare sistematicamente.
A mia domanda sul supporto di thread logici su fiber, Chris Brumme ha risposto che un CLR host in Whidbey può implementare controllo scheduling su Thread .NET, per esempio usando i fiber del sistema operativo. Questo è esattamente ciò che fa Yukon, ma è un sistema sconsigliato a meno di avere seri problemi di performance causati da molti thread in esecuzione in parallelo. Non viene comunque citata l'esistenza o l'idea di implementare una logica di scheduling nel CLR.
Infine, a domanda su Reflection "Perché non si può fare browse di IL da Reflection?" James Miller ha risposto "Non abbiamo avuto il tempo di farlo - potreste vedere qualcosa in futuro" (ma non ha specificato quando e in che forma).