Newsgroup: it.lavoro.informatica
Titolo: Diffusione del Framework .net in italia

Secondo voi questa tecnologia serve veramente?

> Secondo voi questa tecnologia serve veramente?
No,
nel senso che neanche java serviva veramente...eppure e' stato inventato :)
Adesso e' quello che va per la maggiore quindi serve conoscerlo (.NET
intendo..)
Lem

 Secondo voi questa tecnologia serve veramente?
Espongo le mie idee su dotNET. Sono ovviamente sensazioni/opinoni
personali, del tutto discutibili, ma *mie*.
Non sono un "espertone" del framework, le eventual imprecisioni sono
dovute alla conoscenza imperfetta dello strumento di cui si discute,
oppure a semplice dimenticanza :-)
Per cominciare, bisogna un attimo capire *cosa è* effettivamente il
dotNET framework, altrimenti non si arriva da nessuna parte.
DotNET, di base, è un insieme di strumenti software che ti consente di
scrivere codice in diversi linguaggi senza preoccuparti minimanente del
linguaggio utilizzato per scrivere le classi che utilizzi.
Quindi, in pratica, puoi usare qualunque classe dotNET da qualunque
linguaggio compatibile. Questo è realizzabile perché quando si
compila un programma con un linguaggio compatibile, esso non viene
trasformato subito in linguaggio macchina ma in un linguaggio intermedio
chiamato MicroSoft Intermediate Language(MSIL). Quando poi viene
effettivamente eseguito, il codice MSIL viene tradotto in codice
nativo e quindi eseguito in un ambiente protetto, il Common Language
Runtime.
Questa è una descrizione sommaria del perché, in teoria, è vantaggioso
utilizzare dotNET. Come al solito, però, la teoria è un pò diversa dalla
pratica :-)
I motivi tecnici sono tanti, specialmente considerando la struttura
attuale del framework: anzitutto, la "traduzione" del codice in
forma nativa avviene *ad ogni avvio* dell'applicazione, quindi, se
avvio un software dotNET 4 volte avrò 4 compilazioni, con i relativi
ritardi in fase di start-up.
Secondo: sotto Windows c'è sempre stata la (buona) cosa che il
codice delle DLL veniva condiviso tra le diverse istanze che lo
richiamavano. Adesso non è più così, o meglio: il codice MSIL è
condiviso, ma quello nativo no. Quindi si risparmia da una parte ma
vieni giocato su un'altra: in pratica per ogni DLL hai una
duplicazione del codice allucinante e questo vale anche per gli
assembly "di base". Non è un fattore da sottovalutare, secondo me.
Terzo aspetto: le funzionalità sono limitate all'ambiente run-time.
Se detto ambiente non supporta una caratteristica, tramite dotNET
liscio non puoi averla. Puoi ottenerla tramite altri strumenti,
come ad esempio l'integrazione con le API Win32 in modalità "unmanaged"
cioè non gestita dal CLR. Ovviamente, le implicazioni sono che
fare debug in una situazione del genere diventa abbastanza complicato,
senza contare la necessità comunque di conoscere bene le API, quindi il
senso di dotNET come "piattaforma per velocizzare lo sviluppo" viene
meno in qualche modo. Considera anche che la stessa libreria WinForms,
base costituente delle applicazioni dotate di finestra in dotNET, è
stata sviluppata interfacciandosi alle API.
Infine(non che siano finiti i "problemi", ma mi sono scocciato di
scrivere <g>) l'ultimo aspetto che, quasi nessuno, sottolinea è che
dotNET andrà, con estrema probabilità, a fornire il lato software di
TCPA.
Saluti :-)
Andrea


Direi che il salto dai vecchi linguaggi tipo VB6 è davvero notevole. A
pensarci bene non serve neanche un granchè la conoscenza di questo o di quel
linguaggio specifico.
Nell'ambito dello sviluppo web, poi, mi sembra che sia stata intrapresa la
direzione corretta, quella della convergenza degli ambienti di sviluppo e
delle metodiche di programmazione (anche se c'è ancora parecchia strada da
percorrere ...)
Va scomparendo quella stortura masturbatoria dell'architettura COM, che ha
regalato molti più problemi di quanti ne abbia realmente risolti.
Scompare anche, finalmente, quello'obbrobrio di ADO, concepito male ed
implementato persino peggio.
Per utilizzare la nuova architettura serve *solo* una solida mentalità ad
oggetti, il che con tutta probabilità metterà in crisi chi è abituato a
scrivere il codice prima di farne un'analisi corretta in termini di classi.
E questo, forse, anzi spero, decreterà la selezione naturale di chi fino ad
oggi si è millantato *informatico* perchè sa spippolare con i puntatori, ma
che va in crisi, ancorchè con quello di classe, con il concetto di tipo.
Mi sembra l'unico vero passo avanti degli ultimi dieci anni. Un po mi rode
che sia stata mamma Microsoft a farlo, ma tant'è ...
Ciao, Sandro.
 
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 che sia stata mamma Microsoft a farlo, ma tant'è ...
Ho letto con interesse il vostro forum.
Volevo un'info esiste un software opensource tipo VISUAL STUDIO .NET 2005?
Buone feste
luca


Va bè, qui entriamo nell'OT ma diamo a Cesare ciò che è di Cesare. 
Visto che .NET è, a livello di idea ed architettura, una copia spudorata di
Java e del suo ambiente J2EE non mi sembra poi tanto giusto considerarlo
l'unico passo avanti degli ultimi 10 anni.
Microsoft prima ha snobbato Java, poi ha tentato di reinterpretarlo a modo
suo scatenando le ire di Sun. Persa la battaglia legale con Sun, Microsoft
ha passato gli anni successivi a sputtanare Java fino a proporre .NET,
fatto a perfetta immagine e somiglianza di quello che fino al giorno prima
aveva sputtanato (in pratica l'ammissione implicita del reale valore
innovativo di Java).
Se c'è stata davvero una cosa innovativa negli ultimi 10 anni di certo non
è stata .NET.

 che sia stata mamma Microsoft a farlo, ma tant'è ...
Ho letto con interesse il vostro forum.


 è stata .NET.
Concordo anche su questo, con qualche piccola "aggiunta" di cui
magari non siete al corrente, ma che può aiutare a capire un pò di
"background" di certe cose... dunque, qualche anno fa Borland
provò a fare un compilatore che generasse bytecode java a
partire dai sorgenti Pascal. Tutto questo, mi sembra avvenisse
prima della partenza di AH.
Fa molto piacere notare, comunque, come i post riguardo dotNET siano
molto pochi in questo thread e nessuno che fa considerazioni di
carattere squisitamente tecnico.
Ciao,
Andrea


http://www.icsharpcode.net/OpenSource/SD/
Mi sembra abbastanza usabile.
Forse ne esistono degli altri.


 ha scritto nel messaggio 
news:cqedhl$5ii$1...@carabinieri.cs.interbusiness.it...



 
Ni.
Java mirava ad essere cross-platform. .Net mira ad essere cross-language.
Mi sembra che, se convergenza c'è stata (e c'è stata senza dubbio), questa
sia arrivata da prerogative del tutto differenti.


 Mi sembra abbastanza usabile.
Ho intenzione di usare SharpDevelop  oppure è meglio 
VS.NET
 2002?


Ciò non toglie che l'ex principal architect di Delphi si sia ispirato
pesantemente al J2EE per sviluppare il framework .NET. Questo per dire che
in realtà .NET non è nulla di innovativo ma è l'affinamento di un'idea che
altri hanno avuto. Si potrebbe al massimo obiettare che anche Java a sua
volta si ispirava ad altro (vedi Smalltalk) ma comunque lo ha fatto in
maniera molto ma molto meno spudorata di MS.
 

 sia arrivata da prerogative del tutto differenti.
Il cross-language, per quanto utile, è infinatamente meno importante del
cross-platform. La complessità architetturale di Java e del J2EE ha un
senso nella complessità del problema che vuole risolvere, quello del "write
once, run anywhere". Forse la portabilità completa non è stata raggiunta ma
c'è da dire che Java c'è arrivato molto vicino.
Meno comprensibile, almeno dal mio punto di vista, la scelta di Microsoft
di risolvere un problema meno importante e meno sentito, quello del
cross-language, con una struttura altrettanto complessa di quella della
Sun, che però è nata con ben altre ambizioni. Con la conseguenza di creare
un mare di problemi agli sviluppatori che da un giorno all'altro si sono
trovati in ambiente operativo totalmente incompatibile con quello
precedente (provate a dare in pasto un sorgente VB6 al nuovo 
VB.NET
) senza
ben capire il perchè.
Della necessità reale di MS di avere un .NET ho molti dubbi dal punto di
vista tecnico, l'unica spiegazione che mi so dare sta nel marketing ma qui
mi addentro in campi a me oscuri...

 mi addentro in campi a me oscuri...
Secondo me invece il motivo è molto semplice( e tecnico, oltre che di
marketing ): realizzare e diffondere il lato software di TCPA.
Ciao,
Andrea

 ben capire il perchè.
Io mi metto fra questi. C'è da dire che, nel mio caso, sono stato molto ben
lieto di trovare realizzati i delegates, le interfaces, un buon meccanismo
di inheritance, una gestione di eventi ed eccezioni raffinata e moderna. Per
me che i vecchi progetti vb6 non fossero compatibili è una garanzia assoluta
del netto passo in avanti che tali strumenti di sviluppo hanno fatto: meno
male che non c'è compatibilità.
Poi, che la cosa possa creare problemi agli sviluppatori è davvero tutta da
vedere. Certamente ne crea all'inizio, e non pochi. E sono problemi, imho,
derivanti da una forte differenza filosofica che esiste fra un giocattolo ed
un environment orientato agli oggetti.


un environment orientato agli oggetti.
...sebbene perfino in vb potevano essere realizzati programmi
piuttosto oo che implementassero design patterns, componentizzazione
spinta etc.