Newsgroup: it.comp.lang.visual-basic
Titolo: [!][LONG][Informale]Cos'e' .NET?

Premessa
--------
Ho acquistato "Programmare Microsoft Visual Basic .NET" di Francesco Balena.
Inutile dire che mi ci sono gettato a capofitto.
Per la cronaca ho gia' preparato la lettura successiva: ho acquistato anche
"Programmazione avanzata con Microsoft Visual Basic .Net" di Jeffrey Richter
e Francesco Balena.
Del primo libro sono arrivato alla fine della seconda parte, in pratica ho
"studiato" cio' che riguarda il funzionamento del framework e le specifiche
del linguaggio (
VB.NET
). Del secondo ho letto i primi due capitoli
(riguardanti alcuni principi di funzionamento del framework).
Questo post non ha alcuna pretesa e probabilmente contiene alcuni (molti!)
errori che auspico saranno evidenziati e corretti dalle "autorita'" del NG
in merito a .NET.
Nel mio piccolo propongo una "summa" dei capisaldi di .NET a chi ancora non
ha avuto modo di affrontare questo nuovo "mondo".
Here we go!
--------
.NET e' un nuovo "sistema" di programmare che si basa sull'utilizzo di una
base comune di specifiche, tipi, classi e chi piu' ne ha piu' ne metta ;).
Tale base comune e' detto framework .NET che e' costituito da una marea di
sigle :-)
I vari linguaggi di programmazione si "appoggiano" sul framework non
produrranno codice compilato, ma codice (cosiddetto) "gestito", ovvero
codice in un linguaggio intermedio (IL, Intermidiate Language) di basso
livello, ma che conserva ancora informazioni su nomi, tipi, costrutti, ecc.,
che verra', appunto, gestito dal CLR (Common Language Runtime), il cuore del
framework, che si occupa di eseguire i programmi scritti in IL.
Lo IL e' prodotto seguendo le specifiche comuni del linguaggio (CLS, Common
Language Specifications), questo viene compilato al volo dal JIT (Just In
Time) compiler al momento in cui viene eseguito.
L'unita' minima che costituisce un programma e' un assembly (che puo' anche
costituire un programma e quindi un eseguibile). Se un programma e'
costituito da piu' assembly (magari prodotti con linguaggi diversi)
l'Assembly Linker (AL) si occupa di linkare tali assembly in un unico
eseguibile.
Gli eseguibili sono comunque costituiti da IL e vengono detti Portable
Executable (PE) in quanto vengono per l'appunto compilati e linkati al volo
sul PC sul quale vengono eseguiti. Una breve nota sulla compilazione: la
compilazione al volo sfrutta le potenzialita' della macchina e le istruzioni
specifiche dei processori (ad es. Pentium4 o K7), non viene mai compilato
"tutto il programma insieme" e quindi, tendenzialmente, non ci sono tempi di
attesa "lunghi", anzi.
Addio a conflitti di versione: infatti gli assembly che che costituiscono un
PE vengono salvati nella GAC (Global Assembly Cache, ovvero una serie di
cartelle sull'Hard Disk ;)) marcate a fuoco dal proprio numero di versione.
Un PE si rifiuta di funzionare se gli assembly che lo costituiscono non
hanno tutti il numero di versione corretto :).
Ovviamente si possono "tranquillamente" integrare gli assembly in codice
gestito con "vecchie" DLL compilate (codice non gestito) per chi non si puo'
permettere il lusso di "riscrivere tutto da capo".
Ma la parte piu' "portentosa" del Framework e' la sua libereria di classi
(BCL o FLC, ovvero Base Class Library o Framework Class Library) che ricorda
tanto le MFC di VC++ e le librerie Java, e soprattutto un sistema di
specifiche dei tipi comune (CTS -> Common Type Specification) a tutti i
linguaggi, che permette di poter definire un tipo in 
VB.NET
, usarlo in una
classe in C#.NET, da cui derivare un classe in C++.NET nuovamente ereditata
(udite udite) in 
VB.NET
.
Eh si, perche' 
VB.NET
 e' diventato a tutti gli effetti un OOPL (Object
Oriented Programming Language) per mettere finalmente a tacere i
C-piu'-piu'-isti che consideravano VB un linguaggio-giocattolo.
Scegliere un linguaggio di programmazione in .NET e' solo una scelta
funzionale, in quanto (a parte sottili differenze che *speriamo* saranno
appianate in futuro) tutti i linguaggi hanno le stesse potenzialita'.
--------
E con questo concludo il pippone sperando di aver dato un quadro generale a
chi (come me) decidera' di passare a questa nuova metodologia di
programmazione e, soprattutto, di non aver detto troppe castronerie.
Happy Coding a tutti =)
Lokar
--
Sito Comune: 
http://www.it-lang-vb.net/
Manifesto: 
http://www.it-lang-vb.net/docs/Manifesto.txt

: Scegliere un linguaggio di programmazione in .NET e' solo una scelta
: funzionale, in quanto (a parte sottili differenze che *speriamo* saranno
: appianate in futuro) tutti i linguaggi hanno le stesse potenzialita'.
:
: --------
:
: E con questo concludo il pippone sperando di aver dato un quadro generale
a
: chi (come me) decidera' di passare a questa nuova metodologia di
: programmazione e, soprattutto, di non aver detto troppe castronerie.
:
: Happy Coding a tutti =)
:
: Lokar
Si, le potenzialitŕ di .NET sono moltissime, ma č veramente avvilente
perdersi nella sua guida in linea...
Una qualsiasi pagina risulta essere farcita di un' infinitŕ di link a
classi, collection e oggetti vari...per non parlare della struttura del
nuovo ADO.NET...
In questo periodo sto riscrivendo da capo un applicazione VB6 con 
VB.NET
,
giusto per "impratichirmi" e non so se ridere o se piangere...!!!
Ciaomandi.

 
VB.NET
, giusto per "impratichirmi" e non so se ridere o se
piangere...!!!
Io ho gia` fatto diversi porting, ma ho scelto come linguaggio target
il c# ed il motivo e` che a parita` di esperienza in VB ed in Java, mi
sono reso conto che le conoscenze in Java mi aiutano di piu` con .Net.
Ora non voglio affermare che questa debba per forza essere una regola
generale e valida per tutti, ma IMHO la Microsoft non ha rispettato
granche` quelli che avevano puntato decisamente su VB (cioe` su un
prodotto della stessa MS).
--
ale
www.sen.it

 prodotto della stessa MS).
Beh, per dirla tutta la microsoft ha detto
Udite Udite! Questo è il fantasmagorico, mirabolante,.NET!!!
Udite Udite! questo è il fantasmagorico, mirabolante C#!!
.....
Cosa? Vb.NET? si si, beh a dire il vero c'è anche quello.
è stato quasi come se si fossero dovuti portare appresso una bisaccia tanto
per dire che c'è...
Ero Milano alla presentazione ufficiale di .NET
In 8 ore di presentazione non ho mai sentito pronunciare insieme le parole
"Visual" e "Basic".
Però da mangiare era buono... complimenti a microsoft per la scelta della
ditta di catering.. :-)

 un linguaggio-giocattolo.
Beh, molti passi avanti sono stati fatti, ma non bastano
ancora per metterci a tacere...
Ciao.
--
BSD is for UNIX-lovers -- linux is for Windows-haters.

 ma non bastano ancora per metterci a tacere...
Quoque tu, H.P.L.!
Al di la' dell'overloading degli operatori (che auspico sia implementato
asap da ms in vb), quali sono i passi mancanti, a tuo avviso?


 a tuo avviso?
Non è questione di passi... I due linguaggi sono totalmente
differenti e mai potranno essere solo che paragonati. Io
sinceramente *non* considero valido per un utilizzo realmente serio
*nessun* linguaggio che abbia un garbage collector (la presenza del
quale è causa -o conseguenza- di caratteristiche limitanti del
linguaggio)...
Con questo non voglio dire che non sia possibile sviluppare
programmi "affidabili" e "stabili" anche in VB(.NET) od in C# od in
Java, ma questo è possibile solo con una maggiore complessità del
codice che non può certo avere effetti positivi.
A dispetto di quello che vogliono fare credere un GC riesce a
semplificare *solo* i programmi banali, semplici e fatti male, ma
complica notevolmente il codice di quelli seri e complessi...



ciao,
.A
UGIdotNET - 
http://www.ugidotnet.org

 (credo) svilupparla.
Credo che l'affermazione di H.P.L. sia in generale un po'
estremistica, pero` non priva di un fondamento di verita`, che la fa
diventare profondamente attuale in molti ambiti applicativi (ed in
alcuni di questi e` praticamente vangelo, vedi sistemi RT).
Detto questo, e` probabile che la classe dei programmi realizzabili
utilizzando un GC sia molto ampia, e che in questo insieme ve ne siano
molti nei quali un GC semplifica notevolmente la realizzazione senza
per questo introdurre apprezzabili controindicazioni.
Una piccola curiosita`: il runtime di .Net (o quello di Java) utilizza
internamente un GC? Spero proprio di no :-)
--
ale
www.sen.it

 (credo) svilupparla.
Tra l'altro, ci sono altri vantaggi del C++ sul VB (e altri
linguaggi), come essere multiparadigma, e supportare la
programmazione strutturata, object oriented e generica. In
particolare utilizzando assieme OOP e programmazione generica
si ottengono risultati impensabili in altri linguaggi.
Tornando al GC...
Il discorso è molto lungo, qui puoi trovare un'articolo
scritto da Carlo Pescio che spiega proprio la differenza fra
C++, Java e C#, discorso che vale perfettamente anche per
VB.NET
:
http://www.eptacom.net/pubblicazioni/pub_it/iso_12.html
, dove
puoi notare che codice "serio" scritto con la presenza di un
GC è circa *tre* volte il codice scritto senza un GC.
P.S.
Eventualmente, se non conosci il C++ e volessi chiedere
qualche chiarimento, sono a disposizione.


 (credo) svilupparla.
Tra l'altro, ci sono altri vantaggi del C++ sul VB (e altri
linguaggi), come essere multiparadigma, e supportare la
programmazione strutturata, object oriented e generica. In
particolare utilizzando assieme OOP e programmazione generica
si ottengono risultati impensabili in altri linguaggi.
Tornando al GC...
Il discorso è molto lungo, qui puoi trovare un'articolo
scritto da Carlo Pescio che spiega proprio la differenza fra
C++, Java e C#, discorso che vale perfettamente anche per
VB.NET
:
http://www.eptacom.net/pubblicazioni/pub_it/iso_12.html
, dove
puoi notare che codice "serio" scritto con la presenza di un
GC è circa *tre* volte il codice scritto senza un GC.
Altro aspetto, che forse non è abbastanza chiaro
nell'articolo, è che l'idioma RAII lì citato (e spiegato)
risolve il problema della gestione della memoria *esattamente*
come un GC, senza però introdurre nel codice gli effetti
collaterali che invece implica la presenza di un GC.
P.S.
Eventualmente, se non conosci il C++ e volessi chiedere
qualche chiarimento, sono a disposizione.
Ciao.


 no :-)
Sì, e non potrebbe essere altrimenti.


collaterali che invece implica la presenza di un GC.
La riflessione condotta dall' autore e' chiara, eccome!
Un riassunto potrebbe essere questo:
<citazione>
Il vero punto di frattura con il C++ e' comunque la rinuncia
all'idioma "resource acquisition is initialization", che richiede
oggetti con lifetime automatico. Questo significa, come accennavo
sopra e come vorrei ora approfondire, barattare la gestione "gratuita"
della memoria con la gestione "manuale" di tutte le altre risorse
(file, handle, finestre, lock, qualunque cosa). 
[cut]
Viceversa, in Java/C# non e' teoricamente necessario progettare il
lifetime degli oggetti. Ma questa e' una falsa sicurezza, in quanto in
molte situazioni (non necessariamente in tutte) dovremo comunque
gestire a mano acquisizione e rilascio delle risorse.
[cut]
Mediamente, e qui sta una sorpresa per molti, il codice C++ ben
scritto sara' piu' breve, perche' la stessa piccola astrazione verra'
probabilmente riusata in molti punti diversi, e conterra' una parte di
logica che in Java/C# andra' replicata in tanti blocchi finally
diversi (da questo, chi vuole potra' trarre un giudizio su quale sia
la tecnica migliore dal punto di vista dell'ingegneria del software). 
</citazione>
Ho trovato molto interessante anche l'analisi sulla distinzione fra
linguaggi a uno e due livelli, che, francamente, non conoscevo.
-- 
ciao, hal

 un articolo davvero "illuminante".
http://www.fawcette.com/vsm/2002_08/online/santanna/

 francamente, non conoscevo.
Sì, è un articolo molto interessante (come tutti quelli
pubblicati dall'autore).


 
http://www.fawcette.com/vsm/2002_08/online/santanna/
L'ho letto velocemente (molto velocemente), e mi pare non
faccia altro che ribadire (implicitamente) che la presenza di
un GC di solo l'illusione di semplificare la stesura del
codice, ma che in realtà le cose siano diverse...


infatti
"H.P.L." <u...@vaila.ble> ha scritto


 infatti
Chissà perché quando si vogliono illustrare i vantaggi della GC la
gestione degli errori misteriosamente sparisce, ed il codice non
"GCed" è sempre C e mai C++ (o almeno C++ scritto alla C).


 pubblicati dall'autore).
Di cui ho letto anche degli articoli su qualche rivista
di infomedia, se non sbaglio.
--
ciao, hal
che non basta una vita per fare tutto...
--------------------------------
Inviato via 
http://usenet.libero.it

 di infomedia, se non sbaglio.
Sì, esatto. E trovo anche che dopo che le ha abbandonate la loro
qualità sia scesa notevolmente...
