Monday, July 25, 2005
Herb Sutter on C++/CLI
I have found a two-parts video interview with Herb Sutter:
part 1 part 2
For those who don't know him, Herb is one of the foremost C++ experts, and since 2002 has been working (guess what) as a program manager for Visual C++.
In the video, he talks about deterministic destruction, garbage collection, safety, and the underestimated difference between memory release and object disposal (my Italian readers may want to read my paper C++, Java, C#: qualche considerazione which also covers deterministic destruction). Maybe we'll see something better in the CLR in the future, but I won't hold my breath.
He also talks a little about the future of C++. He says that C++ has been successful, so it's now hard to change (which is partially true). He also says that C++ is a language with a tradition of trusting the programmer (true) and therefore is exposing more of the underlying platform (true). So, in his view, C++/CLI will be exposing more of the CLR than "any" other .NET language. Maybe, but I still see little value in that except as a (possibly fantastic :-) glue technology. Still, even fantastic glue is just glue. You don't build a system with a glue language.
He's also mentioning that colleges are getting back to teaching C++ from Java/C#; I've no data to back up this claim, and from what I see, I'm not so keen to believe it.
Herb is not the only guy in the video from the VC++ team, but as you listen to the others, you probably feel like you'd better uninstall Visual Studio right away :-). The final talk on Phoenix is interesting, I would definitely like to play with that in the future :-).
part 1 part 2
For those who don't know him, Herb is one of the foremost C++ experts, and since 2002 has been working (guess what) as a program manager for Visual C++.
In the video, he talks about deterministic destruction, garbage collection, safety, and the underestimated difference between memory release and object disposal (my Italian readers may want to read my paper C++, Java, C#: qualche considerazione which also covers deterministic destruction). Maybe we'll see something better in the CLR in the future, but I won't hold my breath.
He also talks a little about the future of C++. He says that C++ has been successful, so it's now hard to change (which is partially true). He also says that C++ is a language with a tradition of trusting the programmer (true) and therefore is exposing more of the underlying platform (true). So, in his view, C++/CLI will be exposing more of the CLR than "any" other .NET language. Maybe, but I still see little value in that except as a (possibly fantastic :-) glue technology. Still, even fantastic glue is just glue. You don't build a system with a glue language.
He's also mentioning that colleges are getting back to teaching C++ from Java/C#; I've no data to back up this claim, and from what I see, I'm not so keen to believe it.
Herb is not the only guy in the video from the VC++ team, but as you listen to the others, you probably feel like you'd better uninstall Visual Studio right away :-). The final talk on Phoenix is interesting, I would definitely like to play with that in the future :-).
Comments:
<< Home
Dovrebbe essere chiaro il tuo punto di vista da alcune "sfumature" che si possono cogliere nei tuoi blog, ma vorrei che lo esplicitassi meglio con un commento. Anche l'informatica non fa eccezione: ci sono cose che vanno e cose che vengono e non tutte restano. Che ne pensi della piattaforma .NET (Non ti chiedo di fare contro-pubblicità per i tuoi corsi ;-) ? C'é del buono e anche del meno buono. Cito ad esempio un sw di Lantronix per la configurazione dei suoi device che richiede .NET framework: per certi versi carino ed occupa solo 1.5MB; peccato che mandarlo per posta agli installatori sul campo sia impossibile per i 20MB circa del framework mentre invece analogo in C + SDK non arriva a 100KB (per non parlare di altre considerazioni sulle prestazioni). Non voglio poi sminuire tutta la "pappa pronta" che indubbiamente può far comodo usando .NET, ma programmare mi sembra altra cosa che assiemare pezzi uno con l'altro: non dovrebbe essere qualcosa di più creativo? Ed il rischio che si corre con questi strumenti è molto forte. Paradossalmente dopo la comparsa di tools che facilitano la vita del programmatore, ci tocca leggere le lamentele di Bill perché è sempre più in calo il numero degli iscritti nelle facoltà dove queste scienze s'insegnano. (Scusa la sbrodolata)
Qui dietro intuisco una quantita' di domande :-) che provo a dettagliare meglio:
- Che futuro ha il C++ in generale?
- Che futuro ha il C++ sotto Windows
- E il C++/CLI?
- E chi ha scritto codice con (es) MFC?
- Ma .NET in generale com'e'?
(da notare che le risposte in alcuni casi sono interessanti anche per chi usa, ad es., Delhi).
Su questi argomenti gradualmente scrivero' qualcosa. Invece un paio di cenni a questioni piu' specifiche che citi posso darli subito:
- sulla questione del conflitto di interessi :-))) con i corsi: in realta' chi ha partecipato a qualcuno dei miei corsi sa bene che non esito a sparare a zero :-) su tutto cio' che non funziona bene, in UML come in .NET ecc. Peraltro i miei corsi .NET sono "selettivi", nel senso che ci cerca il solito corsetto dove ti aprono il Visual Studio, in quattro click ti fanno una applicazione web e ti illudono che la storia sia tutta li', trova senz'altro frotte di docenti volenterosi :-) e non viene certo da me, anche perche' io quel tipo di corso non lo faccio :-).
- sulla questione dimensioni del run-time e invio sul campo, e' comunque ovvio che si tratta di un problema "transitorio", nel senso che prima o poi i tuoi installatori si troveranno il framework gia' installato... che lo vogliano o meno:-).
- sulla "pappa pronta" Vs. creativita' non condivido, almeno non se leggo la cosa in ottica "banale". Ovvero, non trovo creativo farsi la propria toolbar, la propria classe per accedere ai file, ecc, soprattutto se quelle che mi forniscono in libreria sono buone. Gia' potrei sollevare qualche dubbio su classi come FileSystemWatcher, ma in fondo la probabilita' che il programmatore "medio" che non conosce granche' della programmazione di sistema si crei una classe profondamente migliore e' piccola (ovviamente il mio FileSystemWatcher scritto in C++ e' piu' bello :-)))).
- esiste invece un grosso problema di creativita' architetturale, di creativita' nella risoluzione dei problemi prettamente applicativi anziche' tecnologici, ecc. Se la libreria e' buona ci aiuta a spendere il tempo qui, ovvero dove serve.
- invece, quello che un po' rattrista e' che la "pappa pronta" di cui sopra sia appunto "pappa" e non un piatto un po' piu' elaborato :-). Per quanto la FCL di .NET sia anni luce da MFC, e' ancora molto primitiva, indubbiamente instabile (non tanto nel senso dei bug quanto delle modifiche che apporteranno) e conserva lo stesso peccato originale di essere progettata "da dentro" e non "da fuori", mancando cosi' di astrazioni e concetti molto utili.
- che poi gli strumenti RAD portino facilmente i programmatori a scrivere codice ripugnante e' risaputo ma anche qui il rimedio non puo' essere quello di fargli/farci posizionare i controlli alle coordinate x,y via codice scritto a manina :-).
- sulla questione del calo degli iscritti, premesso che non ritengo ci sia correlazione con la pappa pronta di cui sopra, e premesso che in generale per i prossimi 4-5 anni probabilmente fanno anche bene a non iscriversi, sarebbe un discorso piu' lungo, che coinvolge necessariamente anche elementi di mercato, di business, di carriera, di globalizzazione :-), del nerd come commodity, ecc. Pur sapendo che si tratta di argomenti che faranno rizzare i capelli a qualcuno, prima o poi qualcosa in proposito dovro' proprio scriverla...
- Che futuro ha il C++ in generale?
- Che futuro ha il C++ sotto Windows
- E il C++/CLI?
- E chi ha scritto codice con (es) MFC?
- Ma .NET in generale com'e'?
(da notare che le risposte in alcuni casi sono interessanti anche per chi usa, ad es., Delhi).
Su questi argomenti gradualmente scrivero' qualcosa. Invece un paio di cenni a questioni piu' specifiche che citi posso darli subito:
- sulla questione del conflitto di interessi :-))) con i corsi: in realta' chi ha partecipato a qualcuno dei miei corsi sa bene che non esito a sparare a zero :-) su tutto cio' che non funziona bene, in UML come in .NET ecc. Peraltro i miei corsi .NET sono "selettivi", nel senso che ci cerca il solito corsetto dove ti aprono il Visual Studio, in quattro click ti fanno una applicazione web e ti illudono che la storia sia tutta li', trova senz'altro frotte di docenti volenterosi :-) e non viene certo da me, anche perche' io quel tipo di corso non lo faccio :-).
- sulla questione dimensioni del run-time e invio sul campo, e' comunque ovvio che si tratta di un problema "transitorio", nel senso che prima o poi i tuoi installatori si troveranno il framework gia' installato... che lo vogliano o meno:-).
- sulla "pappa pronta" Vs. creativita' non condivido, almeno non se leggo la cosa in ottica "banale". Ovvero, non trovo creativo farsi la propria toolbar, la propria classe per accedere ai file, ecc, soprattutto se quelle che mi forniscono in libreria sono buone. Gia' potrei sollevare qualche dubbio su classi come FileSystemWatcher, ma in fondo la probabilita' che il programmatore "medio" che non conosce granche' della programmazione di sistema si crei una classe profondamente migliore e' piccola (ovviamente il mio FileSystemWatcher scritto in C++ e' piu' bello :-)))).
- esiste invece un grosso problema di creativita' architetturale, di creativita' nella risoluzione dei problemi prettamente applicativi anziche' tecnologici, ecc. Se la libreria e' buona ci aiuta a spendere il tempo qui, ovvero dove serve.
- invece, quello che un po' rattrista e' che la "pappa pronta" di cui sopra sia appunto "pappa" e non un piatto un po' piu' elaborato :-). Per quanto la FCL di .NET sia anni luce da MFC, e' ancora molto primitiva, indubbiamente instabile (non tanto nel senso dei bug quanto delle modifiche che apporteranno) e conserva lo stesso peccato originale di essere progettata "da dentro" e non "da fuori", mancando cosi' di astrazioni e concetti molto utili.
- che poi gli strumenti RAD portino facilmente i programmatori a scrivere codice ripugnante e' risaputo ma anche qui il rimedio non puo' essere quello di fargli/farci posizionare i controlli alle coordinate x,y via codice scritto a manina :-).
- sulla questione del calo degli iscritti, premesso che non ritengo ci sia correlazione con la pappa pronta di cui sopra, e premesso che in generale per i prossimi 4-5 anni probabilmente fanno anche bene a non iscriversi, sarebbe un discorso piu' lungo, che coinvolge necessariamente anche elementi di mercato, di business, di carriera, di globalizzazione :-), del nerd come commodity, ecc. Pur sapendo che si tratta di argomenti che faranno rizzare i capelli a qualcuno, prima o poi qualcosa in proposito dovro' proprio scriverla...
La dettagliata replica ha tutto sommato confermato che le mie intuizioni sul tuo pensiero erano giuste. Se non abuso della tua pazienza, ma francamente penso di no altrimenti perché mai avresti aperto un Blog, avrei ancora un paio di questioni su cui confrontarmi.
Sui banchi di scuola ho appreso che quanto si guadagna in estensione si perde in intensità. Per usare bene .NET dal mio punto di vista vuol dire avere buona familiarità con le sue classi, ma la vastità è tale e la documentazione di Visual Studio non impeccabile nel senso che non mi sembra concepita "lato utente" (argomento ultimamente a te molto caro). Concordi?
In secondo luogo che mi dici riguardo ai mercati emergenti, Cina in testa che a breve ci sommergeranno di tecnici e sw come e forse più del tessile?
Grazie per il tuo prezioso contributo.
Per mero narcisismo La mia foto
Sui banchi di scuola ho appreso che quanto si guadagna in estensione si perde in intensità. Per usare bene .NET dal mio punto di vista vuol dire avere buona familiarità con le sue classi, ma la vastità è tale e la documentazione di Visual Studio non impeccabile nel senso che non mi sembra concepita "lato utente" (argomento ultimamente a te molto caro). Concordi?
In secondo luogo che mi dici riguardo ai mercati emergenti, Cina in testa che a breve ci sommergeranno di tecnici e sw come e forse più del tessile?
Grazie per il tuo prezioso contributo.
Per mero narcisismo La mia foto
In risposta ad alcuni punti della tua replica a romano:
-Io ho partecipato alla conferenza su uml di programmazione.it, ricordo in quell'occasione un commento poco lusinghiero sui CASE tool...:-))
- Dubito che sia una semplice classe il FileSystemWatcher. Se ti conosco bene sarà un bel framework con almeno una 20 di classi :-)) Ma che sia meglio di quella del .NET ci posso scommettere la casa senza neanche averla vista :-))
-Perchè dici che per i prossimi 4-5 anni farebbero meglio a non iscriversi. Prevedi qualche cambiamento nelle cose?
-Io ho partecipato alla conferenza su uml di programmazione.it, ricordo in quell'occasione un commento poco lusinghiero sui CASE tool...:-))
- Dubito che sia una semplice classe il FileSystemWatcher. Se ti conosco bene sarà un bel framework con almeno una 20 di classi :-)) Ma che sia meglio di quella del .NET ci posso scommettere la casa senza neanche averla vista :-))
-Perchè dici che per i prossimi 4-5 anni farebbero meglio a non iscriversi. Prevedi qualche cambiamento nelle cose?
Per Romano: indubbiamente usare una libreria (MFC, STL, tutte le J* che nascono come funghi :->, ecc) richiede un investimento per apprenderla. Investimento che a volte siamo restii a fare, vedi il ruolo ancora marginale degli algoritmi / contenitori standard in molti programmi C++.
La FCL di .NET non e' diversa dalle altre, e' piuttosto estesa ma tutto sommato ragionevolmente partizionata in namespace, salvo alcuni concetti sparpagliati come la serializzazione.
In effetti il mio suggerimento e' prendere confidenza con i namespace della libreria e con qualche classe all'interno, poi di approfondire on-demand, perche' non siamo ancora ai livelli di stabilita' necessari per giustificare uno studio di dettaglio upfront.
Documentazione: se intendi MSDN e' vero che non e' un tutorial, molti mi dicono che in MSDN le cose si trovano solo se si sanno gia'. Tuttavia resta fondamentale la capacita' di cercare qualcosa di cui si ipotizza soltanto l'esistenza :-). Io tradizionalmente mi sono sempre trovato bene con i "reference manual" e quindi anche MSDN non mi dispiace troppo, ma e' comunque vero che studiarsi ad es. i Context Attribute su MSDN sarebbe assurdo.
E' per questo che esistono i libri e gli articoli :-)). Credo di aver accumulato 60-70 libri su .NET, la maggior parte dei quali non merita affatto una lettura completa, ma ognuno ha alcune parti ben scritte su uno specifico argomento, magari da studiare on-demand quando serve...
Tornando un attimo alla questione estensione / intensita'. E' qualcosa a cui dobbiamo in qualche modo abituarci. Se guardo molto indietro negli anni, le informazioni erano scarsissime e si approfondivano moltissimo argomenti molto ristretti. Anche in tempi "recenti", si potevano prendere ad es. le API di Windows 3.0 e studiarsele tutte a fondo (a me sembrava persino doveroso :-), incluse quelle non documentate. Quei tempi sono finiti, probabilmente "per sempre", e bisogna cambiare approccio per mantenere una buona efficacia / efficienza...
La FCL di .NET non e' diversa dalle altre, e' piuttosto estesa ma tutto sommato ragionevolmente partizionata in namespace, salvo alcuni concetti sparpagliati come la serializzazione.
In effetti il mio suggerimento e' prendere confidenza con i namespace della libreria e con qualche classe all'interno, poi di approfondire on-demand, perche' non siamo ancora ai livelli di stabilita' necessari per giustificare uno studio di dettaglio upfront.
Documentazione: se intendi MSDN e' vero che non e' un tutorial, molti mi dicono che in MSDN le cose si trovano solo se si sanno gia'. Tuttavia resta fondamentale la capacita' di cercare qualcosa di cui si ipotizza soltanto l'esistenza :-). Io tradizionalmente mi sono sempre trovato bene con i "reference manual" e quindi anche MSDN non mi dispiace troppo, ma e' comunque vero che studiarsi ad es. i Context Attribute su MSDN sarebbe assurdo.
E' per questo che esistono i libri e gli articoli :-)). Credo di aver accumulato 60-70 libri su .NET, la maggior parte dei quali non merita affatto una lettura completa, ma ognuno ha alcune parti ben scritte su uno specifico argomento, magari da studiare on-demand quando serve...
Tornando un attimo alla questione estensione / intensita'. E' qualcosa a cui dobbiamo in qualche modo abituarci. Se guardo molto indietro negli anni, le informazioni erano scarsissime e si approfondivano moltissimo argomenti molto ristretti. Anche in tempi "recenti", si potevano prendere ad es. le API di Windows 3.0 e studiarsele tutte a fondo (a me sembrava persino doveroso :-), incluse quelle non documentate. Quei tempi sono finiti, probabilmente "per sempre", e bisogna cambiare approccio per mantenere una buona efficacia / efficienza...
Per Romano e Fulvio:
la questione 4-5 anni e' legata a doppio filo con la questione India / Cina, ma e' un po' lunga e coinvolge profondamente un argomento ancora piu' ampio, ovvero la necessita' di trascendere la natura-nerd :) tipica di molti softwaristi - prima o poi scrivo qualcosa di specifico.
Post a Comment
la questione 4-5 anni e' legata a doppio filo con la questione India / Cina, ma e' un po' lunga e coinvolge profondamente un argomento ancora piu' ampio, ovvero la necessita' di trascendere la natura-nerd :) tipica di molti softwaristi - prima o poi scrivo qualcosa di specifico.
<< Home





