Newsgroup: it.comp.dotnet
Titolo: .Net e Java nel mercato del lavoro

Ciao a tutti,
avrei una semplice curiosità: in ambito lavorativo qui in Italia, le aziende 
continuano a preferire prevalentemente Java o la tecnologia .NET (in 
particolare C#) sta diventando sempre più richiesta?
Mi sembra anche che molte aziende (specie nella pubblica amministrazione) si 
stiano avvicinando verso l'utilizzo di software free e se non erro 
l'utilizzo di Java è gratuito anche se usato a scopi commerciali.
Insomma qual è la situazione attuale per quanto riguarda lo sviluppo 
software?
E nei prossimi 5-10 anni secondo voi che direzione prenderà? 

 E nei prossimi 5-10 anni secondo voi che direzione prender ?
Ciao, secondo me il mercato in Italia proseguirà sulla tendenza
attuale,
in particolare continuerà a crescere .Net, mentre per Java tutto
dipenderà dalle scelte che farà Oracle.
Personalmente penso che converrà cominciare ad investire pesantemente
sul mobile, in particolare lo sviluppo su piattaforma Android
che sarà sempre più richiesto.

 (in particolare C#) sta diventando sempre più richiesta?
*PREMESSO CHE*
- Non sono un fan-boy della MS.
- Lavoro stabilmente su piattaforma .NET da 5 anni (anche se non al1 00% 
del tempo).
- Ho lavorato in Java per 2 o 3 anni, durante l'università (e mi è 
piaciuto molto).
- Se dovessi scegliere un linguaggi "per conto mio" la scelta ricadrebbe 
su python.
*AFFERMO CHE*
Non so dove andrà il mercato del lavoro, ma dopo aver provato l'ottima 
gestione dei Generics in .NET, le Lambda expression (e roba simile), 
Linq, Extension Methods e blablabla, tornare a Java ridurrebbe la mia 
produttività di almeno un ordine di grandezza (e lo dico con la speranza 
che Oracle si metta di sana pianta a copiare le cose fatte da MS :-)).
Ciao,
Giulio
-- 

 metta di sana pianta a copiare le cose fatte da MS :-)).
Concordo dal punto di vista tecnico per quel poco che conosco di Java.
Ritengo però che il mercato si evolva in modo quasi totalmente 
disinteressato dalla bellezza tecnica.
L'uso che ho visto di Java nella pubblica amministrazione è disastroso 
(dire che funziona poco è fare dei complimenti). Non è certo colpa di 
Java ma certamente l'insieme della "developer experience" di MS 
aiuterebbe parecchio ad evitare gli strafalcioni che ho visto.
D'altra parte MS certe volte cade nel tranello di marcare stretti gli 
inseguitori invece di andare per la propria strada. Questo genera 
confusione su certe strategie e tecnologie che potrebbero evolvere in 
modo più omogeneo. Questo è il motivo per cui molti non si sentono 
sicuri di sviluppare in ambiente MS. Alludo ai diversi toolkit per 
asp.net
 tanto per citarne alcuni. Pregevoli ma hanno generato 
confusione.
A parziale rimedio la community intorno a tutto ciò sta crescendo bene 
e infatti i migliori risultati ruotano intorno alle persone che sono 
più vicino alle community (il tutto imho ovviamente).
A mio avviso se la scelta è puramente di mercato, bisogna prima andare 
a vedere quale mercato interessa a Midnightmare. Oggi è necessario 
scegliere perché ogni settore ha le sue esigenze e set specifici di 
tecnologie.
Senza questa scelta iniziale, non credo si possa decidere un 
investimento.
Se invece il gusto personale sul set di tecnologie può incidere, 
ovviamente la mia preferenza va tutta sull'ecosistema di vs.net... e 
credo di non poter essere smentito quando affermo che è il miglior 
ambiente di sviluppo/tecnologie di oggi.
-- 
Raffaele Rialdi  
http://www.iamraf.net
Weblog: 
http://blogs.ugidotnet.org/raffaele
Microsoft MVP profile 
https://mvp.support.microsoft.com/profile/raffaele
UGIdotNET - 
http://www.ugidotnet.org/

 comoda in *certe* situazioni).
Cosa intendi con dynamic  C#? 

 visto.
Che cosa intendi dire di preciso? 

 Cosa intendi con dynamic C#?
In estrema sintesi: puoi usare un oggetto .NET (cioè *statico*) come se 
fosse dinamico. Da qui la mia idea per cui a Redmond qualcuno ha 
giocherellato un po' con python e ci ha preso gusto. :-)
Ciao,
Giulio
-- 

 ambiente di sviluppo/tecnologie di oggi.
Boh... non saprei. Io personalmente sono un fan di Emacs e devo dire che 
come Emacs non esiste nulla. Ma IMHO è una questione di abitudine: alla 
fine acquisisci delle skill molto legate allo strumento, per cui usare 
uno strumento o un altro incide presantemente sul rendimento.
Ciao,
Giulio
-- 

 Che cosa intendi dire di preciso?
prova a far andare d'accordo versioni diverse di Oracle, con versioni 
diverse di Eclipse e versioni diverse della JVM, il tutto condito con 
il tentativo di sviluppare per Android :-)
Ti garantisco che fai prima ad imparare il peggio dei dialetti cinesi 
:-D
.m
-- 
Mauro Servienti
{C67C0157-5D98-4733-A75E-93CAEE4BADC8}
Microsoft MVP - Visual C# / MCTS
http://mvp.support.microsoft.com
blog @ 
http://milestone.topics.it
whynot [ at ] topics [ dot ] it

 di Java è gratuito anche se usato a scopi commerciali.
Anche il framework è completamente free e senza royalty, il compilatore 
è incluso nell'SDK e ci sono un paio di progetti open source che offono 
degli ambienti di sviluppo. Sono gli strumenti di sviluppo, quindi 
Visual Studio, prodotti da MS (versioni Express a parte) che sono a 
pagamento.



L'origine è di IronPython come dice Giulio, ma la cosa bella è che non 
è stato necessario fare alcuna modifica al CLR. Il DLR è solo una 
library.
La keyword dynamic ti permette di ottenere il late binding in C#.
Risolve tutti i casi dove vuoi forte disaccoppiamento tra layer e 
laddove lo strong-typing non sia importante (e ovviamente dove le 
performance buttate dalla finestra non sono un problema).
Per esempio è molto comodo quando fai COM Interop e vuoi evitare di 
dover tipizzare dei tipi com molto complessi come quelli di Office o 
della Shell.


 Anche il framework è completamente free e senza royalty
Free as beer, ma non Free as Freedom.
(Fermo restando che di sicuro non è questo che interessa alle PA).
Ciao,
Giulio
--


Oltre a quanto detto da Mauro, aggiungo che la comodità e la semplicità 
di Visual Studio (e tecnologie che ci sono intorno) si traduce 
direttamente in maggiore produttività è diminuito numero di bug nel 
codice.
Il concetto di fondo è che se devi perdere tempo a botte di batch, 
costruirti una UI con designer poveri, un code editor che non ti aiuti, 
e via così, alla fine farai errori (anche banali) sul codice che conta 
veramente.
Finchè non provi cosa significa sviluppare con uno strumento come 
Visual Studio non puoi capire a fondo.


 direttamente in maggiore produttività è diminuito numero di bug nel codice.
Sicuramente nel breve periodo.
A lungo termine, VS è un'arma a doppio taglio.
IMVHO.
Ciao,
Giulio
-- 

 strumento o un altro incide presantemente sul rendimento.
Mah, io non ho ancora visto uno strumento che possa cullarti così tanto 
come 
vs.net
 ... :)


 IMVHO.
In che senso?
I sorgenti sono sempre quelli, la struttura della build è evoluta in 
modo organico (msbuild lavora a fronte di file xml), nell'sdk trovi i 
tool per lavorare anche da command line, etc.
Sul lungo periodo dovresti averne ancora più benefici perché fin 
dall'inizio non ti è costato nulla strutturare bene il progetto (vedi 
il  refactoring per dirne una).


 --

 Sul lungo periodo dovresti averne ancora più benefici
Appunto: dovresti. :-)
Ora, io che ho sempre cercato di avere un approccio *spartano* alle cose 
non ho problemi. E comunque è un mio personale modo di vedere le cose: 
non credo che l'approccio IDE-based (il discorso vale anche per Netbeans 
o Eclipse) sia *sempre* conveniente, specialmente se ci si abitua a "non 
pensare".
Ciao,
Giulio
-- 

 come 
vs.net
 ... :)
E io non ho mai visto niente di più onnipotente di Emacs. :-)
Ribadisco: spesso è solo una questione di approcci/attitudini/inclinazioni.
Qualunque sia la vostra scelta: happy coding! :-)
Ciao,
Giulio
-- 

 *sempre* conveniente, specialmente se ci si abitua a "non pensare".
Usare i wizard senza pensare ovviamente ti porta a pessimi risultati.
Ma se li usi sapendo che cosa stanno facendo sono terribilmente 
produttivi.
Insomma 10 anni fa te lo scordavi di realizzare una app così 
velocemente come puoi fare oggi, almeno non con risultati paragonabili.
Ciao


 Qualunque sia la vostra scelta: happy coding! :-)
Su questo non posso che essere daccordo :)
Ciao


 l'utilizzo di Java gratuito anche se usato a scopi commerciali.
Non rispondo al resto, ma con SharpDevelop, MonoDevelop e soprattutto
Microsoft Visual Studio Express, per non dire dei vari SDK
(principalmente Windows SDK, Platform SDK e .NET Framework SDK) puoi
tranquillamente sviluppare per scopi commerciali. Con Mono, puoi anche
spaziare su un gran numero di piattaforme. Volendo puoi anche usare
Eclipse con Emonic (anche se non so se supporti 4.0).
Questo premesso, in Inglese ti risponderei che la tua domanda comunque
"miss the point". I problemi, ad oggi filosofici, relativi
all'utilizzo di .Net nulla hanno a che vedere con gli eventuali costi
degli ambienti di sviluppo (in ogni caso minimi rispetto agli altri
costi correlati allo sviluppo di software, e di sistemi informatici in
genere), ed onestamente non mi sembra che Java sia esente dallo stesso
tipo di ombre
-----
BTW, avevo dimenticato IKVM.Net, che ti permette di scrivere in Java,
produrre Java bytecode, e vederlo trasformato dinamicamente o
staticamente in CIL (
http://weblog.ikvm.net/
 e 
http://www.ikvm.net/stories.html
).
-----
E non mi stancherò mai di ripeterlo, se lavori con un ambiente di
sviluppo compatibile con JetBrains ReSharper, installa la versione di
valutazione, impara a non poterne più fare a meno nei primi 30 giorni,
e poi compralo! ;)
--
ale
http://ale.riolo.co.uk
 

 
http://www.ikvm.net/stories.html
).
Una ottima applicazione che sfrutta IKVM.Net č Simian.
Simian non č uno strumento per le masse come ReSharper, ma tante volte mi 
chiedo se non dovrebbe esserlo ;)
-- 
ale
http://ale.riolo.co.uk
 

 sviluppo/tecnologie di oggi.
Non ho un settore di riferimento, volevo solo una panoramica della 
situazione.
C# è molto più bello di Java, il quale nonostante tutti lo considerino il C# 
non Microsoft, a me sembra un C# mutilato.
Ma il mercato, come dicevi, si disinteressa alla bellezza tecnica (mi pare 
che fino ad oggi visual basic 6 sia ancora in voga...) 

 La keyword dynamic ti permette di ottenere il late binding in C#.
C# consente di fare uso di variabili a tipizzazione dinamica come avviene in 
Python ad esempio?
Le seguenti istruzioni sarebbero valide?
dynamic d = 10;
d = "stringa";
Se è così credo proprio che Java possa solo mangiare la polvere, altro che 
equivalente.
A quando l'ereditarietà multipla? :D
Sarebbe bello se MS cestinasse C++/CLI e lo "fondesse" con C#, in modo da 
avere un super linguaggio verso cui convogliare tutte le proprie energie. 

 avere un super linguaggio verso cui convogliare tutte le proprie energie.
non serve cestinare proprio nulla, il tutto è già fuso proprio perchè 
c'è l'acronimo CLI, C++/CLI è il perfetto mezzo per collegare due mondi 
che altrimenti devono subire le angherie della "platform invoke" e del 
marshaling dei tipi.


 tipo di ombre
Quoto in toto. In questo momento sto affrontando un progetto che DEVE
nascere multiplatform. Come strumento stiamo impiegando Python, ma
questo e' un dettaglio. Nello stesso momento sto affrontando un
progetto per un supervisore di macchina che deve girare su macchine
Windows. Come strumento sto impiegando .NET e C#, ma anche questo e' un
dettaglio.
Voglio dire: PRIMA si determina il dominio applicativo, l'ambiente di
riferimento e solo DOPO si determinano gli strumenti da impiegare.
Se tuttavia la domanda e' "quale strumento va per la maggiore"... beh,
tira in aria una monetina, testa ;NET, croce Java, e quel che viene
viene.
-- 
Ciao!
Luca

 e poi compralo! ;)
Bah, non so che dirti, io l'ho disinstallato di corsa (voleva fare
troppe cose lui...)
-- 
Ciao!
Luca

 troppe cose lui...)
+1, rimosso dopo meno di mezza giornata.


 avere un super linguaggio verso cui convogliare tutte le proprie energie.
Non avrebbe senso. C++ è un linguaggio con mille sfumature importanti, 
l'uso di reference, const, la visibilità delle classi base, e tutto il 
resto ne fanno un linguaggio "dotto".
C# è invece un linguaggio essenziale ed espressivo ma che per mantenere 
una certa semplicità deve rinunciare a certe finezze.
In termini pratici questo si traduce in maggiore potenza e performance 
a favore di C++ versus una maggiore semplicità e manutenibilità per C#.
Unirli sarebbe una contraddizione.
Sono semplicemente linguaggi diversi per scopi diversi. (Le estensioni 
CLI in particolare sono la "colla" tra mondo managed e nativo dalle 
performance nettamente migliori a tecniche come pinvoke o com).


 che fino ad oggi visual basic 6 sia ancora in voga...)
Io non ho mai investito nulla su vb6 (facevo solo C++ a quel tempo) e 
oggi ne sono molto contento di quella scelta.
La maggior parte del mio sviluppo di oggi è C# ma il linguaggio non è 
più così importante e passo il mio tempo di studio sulle nuove 
tecnologie che vanno da wpf a wcf, wf, etc.
Alcune di queste cose sono poco richieste ma credo che il tempo me ne 
darà ragione.


 troppe cose lui...)
+1


 +1
Sentite la mancanza di un forum con i due pulsantini [+] e [-] ? :-) 

 troppe cose lui...)
Di solito ha ragione lui, e tra l'altro puoi usare il tempo che usi
per fare le cose a cui pensa lui per altro.
BTW, per gli ultraconservatori, in realtà lo puoi anche configurare
per fargli obbedire le tue convenzioni/convinzioni ;)
--
ale
http://ale.riolo.co.uk

 Sentite la mancanza di un forum con i due pulsantini [+] e [-] ? :-)
LOL, in realtà mi mancano poche cose nell'attuale editor di 
vs.net
E quelle poche me le sono già automatizzate con piccole utility che mi 
sono costruito (es: leggere i #define di VC++ e creare il 
corrispondente enum in C#).
Dai powertools di 
vs.net
 (che ho installato, così non passo per 
cavernicolo :D) ho disabilitato l'aperta graffa/chiusa graffa perché le 
mie dita ormai fanno già tutto alla velocità della luce (grazie al 
fatto che uso solo tastiere con layout US).


 ho disabilitato l'aperta graffa/chiusa graffa
Questa odiosa caratteristica, che viene applicata anche alle virgolette e 
agli apici, c'è anche nell'ultima versione di Code::Blocks e non so come 
toglierla! :-( 

> di più EF.
domanda *non* polemica: e quale sarebbe questo approccio? Vuoi definire 
il tuo modello POCO e *poi* mapparlo creando a posteriori l'edmx 
usandolo come fossero i file xml di NH? Con EF puoi. Vuoi fare il tuo 
modello POCO e mapparlo via codice? Con EF puoi. Vuoi definire un 
modello "POCO & DDD style" (fatto di aggregate, per intenderci) e 
implementare un Repository? Con EF puoi.
Certo, se vuoi una cache di secondo livello "out of the box" o devi 
"infilarti" nella pipeline, EF è ancora indietro rispetto ad NH. Ma 
escludendo questi 2 casi, i toolkit sono ormai paragonabili. A tutto 
vantaggio di EF, invece, va detto che a tutt'oggi il LINQ provider di 
NH3 è un "giocattolo" se paragonato a quello di EF (che, a sua volta, è 
"indietro" rispetto a quello di L2SQL, ma questa è un'altra -e brutta- 
storia)
-- 
.A
GUISA - 
http://www.guisa.org
UGIdotNET - 
http://www.ugidotnet.org
Read my blog at: 
http://blogs.ugidotnet.org/pape

 E nei prossimi 5-10 anni secondo voi che direzione prender ?

 1. hai una libreria standard praticamente sterminata
A livello della BCL e di quella Java? 

 A livello della BCL e di quella Java?
IMHO assolutamente si (come pure a livello del .NET framework).
Ciao,
Giulio
-- 

 punta come punta su Java
Alla tua analisi agigungerei Ruby (in particolare con Rails).
Ah... e ci siamo dimenticati di ribadire che il C non morirà mai! :-)
Ciao,
Giulio
-- 

 IMHO assolutamente si (come pure a livello del .NET framework).
Puntualizzo perché molti con una certa età ed un certo tipo di esperienze 
quando leggono BCL traducono mentalmente Borland's Class Library, cioé OWL 
;)
Nel contesto immagino che Midnightmare si riferisse alla Base Class Library, 
con cui generalmente si intendono i namespace System*, anche se 
probabilmente una definizione più stringente potrebbe vedere soltanto quel 
sottoinsieme dei namespace System* effettivamente standardizzato come BCL in 
ISO/IEC 23271:2006. Se vedi a 
http://msdn.microsoft.com/en-us/netframework/aa569283
, nel pdf per ECMA-335, 
c'è scritto chiaramente un paio di volte che la BCL dovrebbe stare tutta in 
mscorlib.dll (non sono certo che l'implementazione di Microsoft obbedisca 
effettivamente a questo requisito!), mentre nel xml dentro lo zip sempre per 
ECMA-335 c'è la definizione formale di BCL, ExtendingNumerics, Networking, 
Parallel, Reflection, RuntimeInfrastructure, Vararg e XML.
BTW, ad ogni modo la frasi che avevi scritto era IMVHO giusta in ogni caso, 
le sterminate librerie di Python sono tranquillamente alla pari con l'FCL 
(anche se quasi certamente offrono insiemi di funzionalità con differenza 
simmetrica non vuota). :p
-- 
ale
http://ale.riolo.co.uk
 

 marshaling dei tipi.
'sta cosa ancora la devo capire (ma mi fido). :-)
Ciao,
Giulio
-- 

 Ma se li usi sapendo che cosa stanno facendo sono terribilmente produttivi.
Appunto.
L'enorme problema delle tecnologie MS è IMVHO proprio questo: la curva 
di apprendimento.
Il primo step lo fai in zero secondi.
Se fuoi approfondire... devi sudare di brutto (complice anche una 
documentazione con un approccio discutibile o almeno che a me risulta 
ostico).
Ciao,
Giulio
-- 

 cominciano i pasticci.
Ok... ma il prodotto di MS non era il .NET framework? o VisualStudio? Io 
credo che per favorire la diffusione di questi prodotti, sia opportuno 
rendere diffusissimi (perché facilmente fruibili e ben funziananti) quei 
prodotti che sono un "bene complementare" dei suddetti. :-)
Ciao,
Giulio
-- 

 NH3 è un "giocattolo" se paragonato a quello di EF
Vero. Ma anche lì, mi pare ci sia un discorso di "miopia".
Va bene usare HQL ma IMVHO la prima cosa da fare sarebbe "investire" per 
rendere perfettamente funzionante qualcosa di basato su un linguaggio 
idiomatico (va be', questione di punti di vista...).
Ciao,
Giulio
-- 


+1


 ostico).
Beh ma se ti fermi a fare RAD, sei già sistemato e questo lo trovo 
estremamente positivo. Se vuoi andare oltre è giusto dover studiare di 
più.


 prodotti che sono un "bene complementare" dei suddetti. :-)
Non credo sia un segreto che tutti i tool di sviluppo servono a creare 
le condizioni migliori per lo sviluppo di applicazioni (ergo vendere 
Windows e Office).
Esempio: Exchange vende se puoi pluggarci app di altri. Se sviluppare 
applicazioni è semplice, Exchange vende di più e lo sviluppatore è più 
contento. La cosa funziona per chi vende prodotti ma il sistema non 
funziona per quelli che ci fanno servizi e sviluppo verticale.
Se vendi servizi hai il "dovere" :) di mantenere le cose di una 
complicatezza assurda ... (ok è tirato all'estremo, ma il concetto è 
quello)


 approccio). Con EF mi è stato praticamente impossibile.
Si, puoi fare la stessa cosa con la CTP5 che è appena uscita. Ho usato 
la CTP4 da Luglio con estrema soddisfazione. A febbraio dovrebbe 
esserci la RTM.
BTW a me piace di più la "fluent api" (che credo abbia anche 
NHibernate) che ti permette di mappare senza file xml (cosa piuttosto 
tediosa) in favore di sane lambda :)
Preferisco di gran lunga la CTP5 dove puoi finalmente partire a 
scrivere le tue entity e poi decidere con la fluent-api come vorresti 
persisterlo.
Fatto questo ti crea il db e per la RTM dovremmo pure vedere una 
strategia di update dello schema (oggi lo si fa con tool di terze 
parti).
Insomma il futuro di EF lo vedo molto bene ...



Fammi aggiungere però che la BCL è una goccia nel mare rispetto a tutte 
le librerie ufficiali MS che si trovano nel framework ...


 La vera sfida non è + tra i linguaggi, ma tra i frameworks
+1
Aggiungo che l'ecosistema di linguaggi dovrà crescere e farà solo del 
bene. Prendi ad esempio F# le cui novità si fanno sentire in modo molto 
positivo anche su C#.
Per alcuni scenari F# è imbattibile e a quanto ho sentito al TechEd ci 
sono fantastiche novità in arrivo.



Lo vedrò bene anche io quando capiranno che servono degli extension 
point lungo la pipeline. Per intenderci: è sufficiente che il team di EF 
continui a fare ciò che sta facendo da anni, cioè copiare le feature di 
NH mettendoci sopra un LINQ provider funzionante <g>


 NH mettendoci sopra un LINQ provider funzionante <g>
Ecco, questo è quello che dico io: quanto si sarebbe risparmiato 
sviluppando semplicemente un provider linq per NH? <g>
Ciao,
Giulio
-- 

 Diciamo che fare al contrario è un incubo :)
Partire dal più basso per arrivare al più alto?
Può essere un approccio, no?
Ciao,
Giulio
-- 

 dichiarazioni di Ayende su questo quesry ovject idiomatico
Ayende: "Dimmi che documentazione scrivi, e ti dirò chi sei". :-)
Ciao,
Giulio
-- 

 Anche SVN mi pare faccia così.
Il rename è consentito in SVN

 Il rename è consentito in SVN
Io lo uso senza problemi. :-)
Poi credo che dietro le quinte SVN faccia un delete/add (ma potrei 
sbagliare).
Ciao,
Giulio
-- 


Il problema del rename è solitamente legato ai sc di tipo distribuito, 
non quelli 'classici'.
La disgrazia di non avere il supporto del rename è che inizia una nuova 
'storia' per il file rinominato (non c'è link prima e dopo il rename)


 sopra un LINQ provider funzionante <g>
A me da dove prendono le idee importa poco :)
Ho abbandonato l'idea di usare NH quando ho visto che le collection 
dovevi farle a modo loro. Poi so che sono cambiate molte cose ma nel 
frattempo mi ero costruito il mio piccolo engine e sono sopravvissuto 
fino ad ora.
Il provider attuale sembra più inefficiente di quello di Linq2SQL ma è 
anche vero che certe query verbose che vedo sul profiler non 
necessariamente sono più lente di quelle "compatte".



una "roba" tipo gli IUserType (cioè estendere il type system dell'O/RM) 
o poter iniettare della logica nel processo di fetch dei 
dati/materializzazione degli oggetti, utile per fare caching di secondo 
livello. Oh, e senza dover fare i "wrapponi" del provider :-)


 a me piace di più la "fluent api" (che credo abbia anche NHibernate)
http://fluentnhibernate.org/
BTW, la 1.0 RTM è di Agosto 2009, e la 1.1 di Maggio 2010.
-- 
ale
http://ale.riolo.co.uk
 

 --
Ciao

 il tentativo di sviluppare per Android :-)
Si..
Anche se l'accoppiata .net / oracle non è tutta rose e fiori da questo punto 
di vista.
Soprattutto se devi "portarla" su Mono.
Ciao.


Beh, io sto provando monodroid e devo dire che stanno facendo un lavoro 
eccellente. Con occhio lungo stanno dando il supporto prima a 
vs.net
 e 
poi arriverà per gli altri ide.
Prendi già solo il fatto che hanno dato la possibilità di condividere 
il garbage collector di java con quello di mono, ottimizzando la 
gestione di memoria ed evitando i problemi di leak dovuti a referenze 
circolari (oggetto di java che referenzia mono e viceversa).


 tentativo di sviluppare per Android :-)
Ma ti rendi conto che hai descritto uno scenario *apocalittico*? :D
Ciao,
Giulio
-- 

 Ma ti rendi conto che hai descritto uno scenario *apocalittico*? :D
ovvio :-P
.m
-- 
Mauro Servienti
{C67C0157-5D98-4733-A75E-93CAEE4BADC8}
Microsoft MVP - Visual C# / MCTS
http://mvp.support.microsoft.com
blog @ 
http://milestone.topics.it
whynot [ at ] topics [ dot ] it