Tra ieri ed oggi sul blog di felipe si è discusso, civilmente fortunatamente, delle implicazioni filosofiche, etiche e sui possibili problemi legali legati alla sempre maggiore adozione da parte di GNOME del framework mono.
Per esplicita richiesta dell’autore non si è discusso di argomenti tecnici, mi complimento con tutti, e felipe ne dovrebbe andar fiero, di come i vari commentatori abbiamo rispettato questa pacata richiesta. Da tecnico pero’ piu’ volte mi son chiesto, daccordo etica brevetti e quando altro, ma alla fine stiam parlando di tecnologia, svisceriamola pure e cerchiam di capire il perche’ di tali scelte.
Ci son davvero motivazioni tecniche per utilizzare mono o è solo moda e comodita’ (leggasi effetto monopolio di microsoft)?
Nei limiti di un confronto, anche duro, ma pacato nei termini mi chiedo e vi chiedo, quali sono le motivazioni (squisitamente tecniche) sul perchè dovrei realizzare un nuovo progetto, open o proprietario che sia, basato su mono?
Spero ne esca un costruttivo dialogo utile a tutti con un utilizzo un po’ inproprio dello strumento blog.
Una tazza di Caffe' :) 
Mmmm… allora visto ceh dall’altra parte si escludeva il piano tecnico mi pare ceh questa volta lo si voglia considerare, tralasciando il piano etico (ok, è una forzatura, ma tanto per chiarire il concetto).
Parto dicendo che NON sono un programmatore professionista, ma che per passione ho seguito C# e .NET dalla pre alpha 1, e mono fin dalle prime bozze (dove oltre l’Hello Word non si andava) e mi pare che i motivi per sceglierli dipendano molto da cosa si vuole realizzare.
Se consideriamo il lato Web è uno dei linguaggi tra cui scegliere, diciamo ceh siamo al livello di Java, anche se IMHO ha una gestione migliore dei WebService (SOAP & c.).
dal punto di vista delle performance (per quanto ho visto io) è più prestante di Java, c’erano dei documenti in rete, penso che googlando un pò si trovino facilmente.
Dal punto di vista delle interfaccie non siamo ai livelli di ortabilità di Java, infatti per avere una utilizzazione “decente” si devono utilizzare le System.Windows.Form su Win e le GTK# su linux, se però il lavoro procedesse si potrebbe pensare di avere un unico Namespace per la realizzazione di GUI.
Per quanto riguarda la possibilità di porting da .NET a mono.. bhè, se le cose sono proprio semplici semplici potrebbe essere possibile ricompilare i sorgenti modificando solo il framework, ma se uno inizia a costruirsi classi particolari con wrapper a librerie C++ (come le ADO) la vedo molto dura. Anche qui la situazione potrebbe migliorare con lo sviluppo.
Ora, perchè scegliere mono è anche questione di gusti, IMHO trovo C# un ottimo linguaggio ad un livello intermedio tra la potenza del codice C++ e semplicità di Java, inoltre il framework di base offre molte più classi e opzioni di Java (ma adesso che è stato rilasciato con la GPL sarà da vedere), quindi trovo comodo mono come base, sefosse possibile scrivere codice in C# e compilare il codice come eseguibile seguirei questa strada (se non altro per l’incremento di performance).
Ovviamente, ripeto, molto dipende dal progetto da sviluppare e dalle conoscenze che si hanno… PHP potrebbe essere usato per scrivere un software NON web? certo, ma a che costo? Così come è vero che si possono scrivere aplicazioni Web in Pascal, ma non credo siano molti coloro che lo fanno. Si tratta di valutare i costi/benefici, un pò come si fa con qualsiasi altra cosa.
Ciao
PS: Spero di essermi espresso chiaramente e sopratutto di non aver annoiato nessuno.
ci son un bel po’ di spunti su cui riflettere … tra cui portabilita’ e performance, framework base ed accessori.
Orgomento meglio dopo pranzo, ora e’ tempu di lavura’ 🙂
@Mavimo
Trovo solo ora il tempo di argomentare il tuo post (come detto prima molto interessante).
Sul discorso performance vorrei vedere questi famosi bancmark che lo dimostrino, non e’ un attacco personale perche’ piu’ volte ho letto cio’. Spesso ci si limita a dire prestazioni bla bla … tempo fa lessi una comparativa (Java / .net) in cui avevano reimplementato da zero il PetStore (applicazione di esempio J2EE fornita da sun) in java e .net con la conclusione che in .net si sviluppa piu’ velocemente. (e qui mi aggancio anche ad un’altro tuo punto)
Java non e’ solo JSE e JEE e’ tutta una serie di liberie e componenti che la comunita’ open source ha realizzato in questi anni (apache, jboss, interface21 e molti altri), se ci si limita solo a quello i test secondo me son volutamente falsati. .net ha un insieme di utility maggiore rispetto ad una installazione di JSE ma resta chiusa li ( o almeno in parte visto il porting su .net di progetti che hanno fatto la storia su java quali hibernate e spring).
Sfortunatamente .net ha fovorito la migrazione dei programmatori fai da te in visualbasic a questo nuovo ambiente con tutte le conseguenze del caso. Cito, anche se non ricordo la fonte, “ci sarebbero molti meno programmi inutili e malfunzionanti se non ci fosse stato visul basic” (traduzione libera ed a memoria ndr.).
E’ prassi comune voler spendere poco o niente sul software salvo poi lamentarsi che le cose non funzionano.
Ok ho divagato un po’, torno in tema, un vero test su un progetto reale che dimostri le prestazioni superiori di .net non l’ho mai visto e per esperienza personale i due framework si equivalgono come prestazioni ( e son surclassati per progetti piccoli da php). Poi anche qui io pecco di superficilita’ perche’ le prestazioni a livello enterprise non son solo pagine/minuto calcolate su helloworld.
Scegliere oggi .net significa rinunciare al vasto patrimonio di librerie open e non disponibili, non la vedo una grande scelta.
Poi per carita’ c# ( che non e’ .net) non e’ male come linguaggio anche se non ne condivido alcuni aspetti di design quali la gestione dei tipi e del codice unmanaged.
Il primo, i tipi, lo avvicina ad un linguaggio di scripting e si facilita il lavoro di stesura del codice ma a mio avviso rende piu’ complesso il lavoro di debug in un ambiente composto da diversi sviluppatori.
Sulla facilita’ di accedere a codice unmanaged e nativo, come direbbe qualcuno aborro …. se scrivi per una VM per quella devi scrivere ed il codice nativo dovrebbe essere l’ultima spiaggia per quelle operazioni non effettuabili tramite VM non un modo per riciclare codice passato altrimenti addio portabilita’.
Credo che con le premesse di C# e .net codice portabile ne vedremmo ben poco, ma qui aspetto che qualcuno mi smentisca.
Diversamente il mio team lavora su windows e linux riuscendo a deployare in produzione su Solaris,Linux,True64 e windows senza cambiare una linea di codice tutto questo grazie a java.
Paragonare il due ambienti imho e’ impossibile poiche’ l’uno (.net) e’ la brutta copia dell’altro (java) [Personale opinione si capisce]
Interessante discussione, grazie di averla segnalata! Sono intervenuto direttamente sul post originale, esprimendo grosse perplessità sul futuro di Mono per quanto riguarda gli aspetti legali. Una volta passati i brevetti software anche qui in europa – e da vecchio combattente dico e temo che è solo questione di tempo – sarà bene non aver intrapreso strade che sembrano, prima ancora che incerte tecnologicamente, perigliose sul piano legale.
Inserito da GigiDN su mail di Mavimo – non ho capito perche’ il motore non accettava il commento, indagherò (scoperto l’arcano erano i (minore) inseriti ora son stati sostituiti con la parola tra parentesi
Fermo un momento, stavamo parlando di mono e sei finito a citare in continuazione .NET che NON sono la stessa cosa. Il primo è GPL e quindi se ne possono vedere le viscere e se uno ha tempo/capacità/voglia migliorarlo, mentre il secondo è closed e sviluppato solo per piattaforme windows da Microsoft^TM.
Per quanto riguarda le prestazioni avevo trovato dei paragoni ma basati su info di più di un anno fa in cui .NET (minore) Java (minore) mono come velocità di elaborazione per applicazioni abbastanza semplici (dipo disegnare degli oggetti sul from e cose del genere), ma poi non me ne sono più interessato, ma da quello ceh percepisco da programmi un pò più complessi è che Java sia più lenta che mono (su piattaforma linux, su win non uso applicativi in mono).
Vero che scegliere .NET (ma non stavamo parlando di mono?) preclude alla possibilità di usare librerie native, ma se ne avverte dale necessita si possono fare porting di librerie esterne (se sono open..) o se non si ha voglia e la necessità di usarle è tale si può realizzare un wrapper della libreria per poterla richiamare all’interno dell’applicativo (.NET o mono che sia). Per di più mono è open, e se vengono rilasciate librerie aperte queste possono essere utilizzate, quindi probabilmente si tratta solo di aspettare che le librerie vengano portate su mono.
Anche su Java (tua affermazione) la comunità open ha sviluppato una serie di librerie negli anni, la stessa cosa potrebbe avvenire per mono (che però dipende da come si “vende” al pubblico).
Premetto che Java non l’ho usato per sviluppare programmi ma mi sono limitato a giochicchiarci un pò mi pare che abbia un set standard di classi più ridotto, per questo esistono così tante librerie, al contrario mono ha un set più esteso all’interno del Framework (non è necessariamente un bene).
Pr gli sviluppatori che sono passati da VB a C# (.NET) io sono uno di quelli, semplicemente perchè mentre con VB potevi svipullare Macro per Office, usando VBA (chechhe se ne dica in ufficio si usa quello), mentre con C++ e Java la cosa era molto, ma ti garantisco molto, più complessa.
Ovviamente mi ripeto C#/mono non è la panacea di tutti i priblemi, quindi va usato con coscienza e conoscendono potenzialità e limiti (come per tutti i linguaggi).
Altro tuo punto è l’utilizzo del codice unmanaged… anche io preferisco decisamente evitarlo (se non altro perchè porta facilmente ad errori 😛 ), ma ci sono occasioni in cui è comodo nonche indispensabile (all’interno dei wrapper per classi C++ tanto per fare un esempio).
Per la portabilità del codice… bhè, non saprei, se sviluppo codice per mono (o .NET) fregandomene in partenza di avere codice portabile la cosa sicuramente è complicata, ma se creo codice pulito, ben suddiviso in classi, potrebbe funzionare tranquellamente, o (se volessi avere un maggiore integrazione) potrebbe essere sufficiente riscrivere la parte relativa alla GUI.
Poi come giustamente dicevi ogniuno ha le sue preferenze, quindi io preferisco C # a Java, ma perchè è quello che conosco meglio, non necessariamente èperchè è IL MIGLIORE in assoluto.
Haaa… dimenticavo .NET (mono) non è la protta copia di Java, per piacere non facciamo questo paragone (che mi è stato sempre sul gròp fin dalla berta 1 del framework .NET). Poi se uono ha proprio voglio può usare Java (come codice) da compilare con il framework .NET (e forse anche mono).
Ciao
PS: Scusa se rispondo in ritardo.
Hemm…. mi ha troncato il commento, solo ceh se cerco di inserirlo mi dice che è già stato messo e non me lo fa inserire… quindi lo rimetto qui sotto (eventualemente elimina il precedente e aggiusta questo 😉
===============
Fermo un momento, stavamo parlando di mono e sei finito a citare in continuazione .NET che NON sono la stessa cosa. Il primo è GPL e quindi se ne possono vedere le viscere e se uno ha tempo/capacità/voglia migliorarlo, mentre il secondo è closed e sviluppato solo per piattaforme windows da Microsoft^TM.
Per quanto riguarda le prestazioni avevo trovato dei paragoni ma basati su info di più di un anno fa in cui .NET
Edit gigidn: parte del post che non e’ riuscito ad inserire Mavimo, il post si ferma perche’ inserito un carattere (in segno minore) che fa impallare il motore di wordpress, non so se si possa risolvere … provo ad indagare. Altro post cancellato perche’ riferito allo stesso errore
non trovo la tua mail … puoi mandarmi il contenuto alla mia mail gigidn(at)hotmail(dot)com
E’ normale che quando parli di mono esce fuori il discroso .net ( mono = implementazione GPL di .net).
Per chiarezza, tra noi ed eventuali lettori estreni accordiamoci sui termini:
C#: Linuguaggio ECMA, standardizzato senza problemi di licenza etc etc, quando mi riferisco a C# prescindo da .net. C# e’ un linguaggio alla stregua del C++, C, Java, Python etc etc. Che sia compilato in linguaggio intermedio per girare su un VM da alcune implementazioni (mono e .net) e’ solo un suo utilizzo.
Java: Linguaggio, vedi sopra ad esclusione dello standard.
Per me il linguaggio e’ l’insieme delle regole semantiche e sintattiche e le parole riservate.
Es: “System” non è una parola riservata in Java mentre ma un oggetto di una delle librerie della JRE “while” invece e’ una parola riservata. Potrei fare un’implementazione che usi la sintassi Java ma che sia completamente diverso dal “Java” comunemente conosciuto. Stesse identiche considerazione per C#.
.NET = framework ( nelle sue varianti 1,2,3) ovvero un insieme di librerie per lo sviluppo di applicazioni desktop e web.
J2SE, J2EE ed i tanti JSR-XYZ, = frameworks per lo sviluppo di applicazioni, come per .net.
mono = implementazione GPL del framework .net (almeno in parte e non ho indagato a quale livello della specifica (ma sarebbe meglio parlare di release per .net) si conforma).
Altra cosa, scrivere in J# (java[linguaggio] su .net o mono) oppure utilizzare JSE/JEE son cose completamente diverse.
Quello che il framework mette a disposizione è semplicemente un compilatore da Java[linguaggio] ad IDL (spero di ricordare bene la sigla del linguaggio intermedio, se non fosse correggetemi la mia memoria vacilla).
A livello teorico, ma anche pratico visto che ne esistono diversi esempi, è possibile scrivere per la JVM in un qualsiasi liunguaggio. Basta implementare un compilatore dal linguaggi di partenza al Bytecode della JVM.
In teoria sarebbe possibile avere un compilatore da C# a JVM.
Spesso si tende a confondere, in ambienta java, VM linguaggio e framework perchè per esplicito design di Sun la VM è monoliunguaggio e tutti i framework son stati identificati con java.
Scrivere in Java per JME e’ cosa completamente diversa di scrivere in Java per JEE, il linguaggio è comune ciò che posso usare (framework) cambia radicalmente.
Dopo queste, spero utili, premesse andiamo al dunque.
Perche’ associo mono a .net, perchè mono vuol essere una implementazione di .net, ed e’ proprio in questo che critico mono.
Se mono ( ma a questo punto avrebbe senso di esistere ? ) fosse un framework a se stante non ci sarebbe nessun problema.
Le specifice C# son publiche e liberamente utilizzabili, il linguaggio è patent free.
Ma in tutta franchezza, essere solo un compilatore C# farebbe perdere tutto a mono, mono si pome come implementazione *nix di .net (con tutte le conseguenze anche legali del caso).
Quindi parlando di mono io lo associo alle specifiche a cui si rifa’ (.net) altrimenti in mono non dovrebbero esistere le windows.form asp.net e compagnia varia.
Certo mono aggiunge delle sue estensioni, come GTK# ma sinceramente questo mi fa propendere ancor di piu’ a non utilizzarlo.
E’ vero che mono esiste anche per windows, ma su windows esiste gia’ l’implementazione .net di microsoft quindi perche’ utilizzare una implementazione (incompleta) di quelle specifiche quando posso avere (gratis se ho uno dei prodotti licenziati) la specifica completa?
Se un cliente mi chiede una applicazione .net mica gli posso dare una in mono … siamo seri vorrei vedere chi riesce a vendere qualcosa del genere.
Il targhet di mono e’ e sara’ i vari *nix (osx compreso).
Poi e’ vero che posso scrivere applicazioni mono che sian portabili su tutti gli ambienti (windows compreso) in mono, che posso riutulizzare parte del codice scritto per windows bla bla bla …. tutte belle parole ma allo stato attuale:
Mono non e’ compatibile al 100% con il framework .net e GTK# che mi risulti non fa parte delle specifiche .net.
C’e’ qualcosa che non mi torna, sembra che sia entrato in un circolo vizioso se scrivo in GTK# perdo la compatibilita’ con .net se scrivo in (passatemi il temine) microfot.net non son compatibile con mono, se scrivo per mono senza GTK# e senza tutte le sue lacune ho un framework ridicolo.
Ma allora come diavolo le devo scrivere le mie applicazioni portabili tra un’ambiente e l’altro?
Se dovessi consigliare, direi din PHP in PyThon in TCL/TK (tralascio java volutamente) ma non in …. be si e’ capito e non so come definirlo.
Le ragioni “tecniche” sulla portabilita’ si scontrano con la stessa natura del progetto e sulla necessita’ di creare un porting su windows.
Se poi mono vuole essere un framework assestante, bene ma non lo si chiami implementazione di .net
Ma quello che leggo dal sito ufficiale di mono e’ il seguente:
What is Mono?
Mono provides the necessary software to develop and run .NET client and server applications on Linux, Solaris, Mac OS X, Windows, and Unix. Sponsored by Novell (http://www.novell.com), the Mono open source project has an active and enthusiastic contributing community and is positioned to become the leading choice for development of Linux applications.
Ed io perplimo (ba chi ha coniato sto temine mi sfugge).
Vabbuo ho scritto tanto, neanche rileggo quindi le cavolate le metto subito in piazza.
Solo due parole sul codice unmanaged (pecca di C#[linguaggio] in questo caso).
Ho messo troppa carne al fuoco mi sa, agevolando quella confusione che volevo fugare tra framework e linguaggio.
La possibilità offerta da C# in manira semplice di utilizzare codice nativo rende non trasportabile il codice su architetture diverse. Supponiamo per assurdo che mono fosse un’implementazione fedele di .net su linux. L’utilizzo di codice nativo renderebbe impossibile il porting di codice .net su mono e viceversa.
Ma analogo discorso potrebbe essere fatto per architetture windows differenti (esiste ancora windows per alpha?).
Ora son d’accordo che alle volte il ricorso a codice nativo è indispensabile, ma dovrebbe essere l’ultima spiaggia e si dovrebbe essere consci di cio’ che si sta facendo.
Proprio per questo motivo apprezzo piu’ la “complessita’” di gestione del codice nativo in Java che la facilita’ di C#. L’utilizzo del codice nativo dovrebbe essere ostacolato altrimenti utilizziamo il nativo con buona pace della VM.
Il problema e’ che se si lascia liberta’ ti ritrovi a dover cazziare il tuo team perche’ ha riciclato liberie native al posto di riscrive 4 metodi in croce.
Vabbuo la finisco qui … il primo canto della divina commedia volge al termine.
Baciamo le mani
Gigi
postilla … non ho riletto e non ho intenzione di rifarlo in questo momento, se presenti frasi sconclusionate e prive di significato siete pregati di farmelo notare.
[OT]
l’uso del blog per questo genere d discussione mi sembra pessimo, non si riesce a costruire discorsi ben articolati ;P
[/OT]
Allora, ottime le premesse iniziali (distinzione linguaggio Vs Framework), un pò meno sul fatto che mono = copia di .NET infatti mono non fa altro che usare la stessa struttura del namespace e delle classi per offrire continuità agli sviluppatori .NET di passare a mono senza doverlitigare con le varie classi.
Sytem.Console potevano chiamarla Mono.Shell (tanto prfare un esmpiostupido), ma a questo punto uno che conosce il framwork .NET difficielemente si mette a reimparare lastruttura perchè gli hanno cambiato il nome dei namespace, classi, metodi, … solo per differenziarlo da .NET 😐
L’intero del framework è presumibilmente differente da come è fatto .NET (non si può esserne certi, non sapendo come è fatto l’interno di .NET), ma presumibilmente…
Volendo anche C++ è portablissimo, usasolo le classi standard e vedrai che poi lo puoi compilare su *nix piuttosto che su Win.. la cosa si cmplica quando uno vole utilizzare le API del sistema operativo piuttsto che librerie che non sono portabili.
Non vedo perché s uno sviluppa un applicazione mono non la possa usare su win… di solito ti commissionano un programa (gestionale, tanto per stare sul banale) non ti dicono fammelo in C++ piutosto che in VB, ma ti dicono che deve fare questo, questo e quest’altro.. poi magari tdicno di non farlo web-based o cose del genere, ma lo basi su un framework non glie ne frega nulla se lo fai su .NET, mono o Java, purchè faccia ciò che serve all’azienda che lo commissiona.
Se io (sviluppatore) realizzo un softwara mono usando mono e GTK# ho un programma completaente portabile sia su win chesu *nix, quindi il committente lo potrà utlizzare su entrambe gli OS, senza grossi prolemi (sempre se non uso classi / librerie sviluppte fregandosene della portabilità)
Cosa che invece noto ultimamente è che mono si sta vendendo molto male, si nei confronti degli utenti che nei confronti degli sviluppatori (anche se in alcuni ambienti ciò non è propriamente vero, vedi per esempio le ultime due conferenze fatte, con tuto il seguito di utenze partecipanti).
Ultimo tuo punto mi pare sia l’uso del codice unmanaged, con me sfondi unaporta aperta, preferisco non usarlo quando si può evitare (99% dele volte), ma lo ho a disposizione se mi serve. Ti faccio un esmpio banale, prgramma c deve risolvere equazioni all derivate parziali (ODE), il core è scritto in C++ (estremamnte ottimizzato per avere perstazioni al top, alcuni pezzi sono prsino in assambly 😐 ), l’interfaccia grafica poteva essere fatta in qualsiasi modo, sia C++ che con Tlc/TK o quello che si vuole, con mono si costruisce l’interfaccia velocemente e “bene”, nel senso in modo plito, usando la gestione degli eventi, eredità tutto l blle cose della OOP, e poi in quache modobisogna collegarla al “core” del programma. Se non avevo codice unmanaged si doveva esportare i dati su file di testo/socket e usare un programma scritto in C++ per prelevare questi dati e elaborarli, procedimento inverso per avere la risposta. Usando il cdice unmanged l cose si semplificano notevolmente (ovviamente portabilità non c’è, m perchè lelibrerie usate non lo sono, non perchè l’interfaccai non sia portabile). Ripeto, il problema è essere a conoscenza delle potenzialità/limitazioni del framework, un pò come (credo) avvenga per Java.
Per quanto riguarda il cazziare il team… bhè, se il fatto di usare librerie non portabile è un problema si presume che il team lo sappia e agisca di conseguenza (altrimenti giustamente viene cazziato e credo che allaunga sia un comportamente che non paga 😉 )
Ripeto, il codice non gestito è solo uan possibilità (in più) che si da, poi sta alla coscenza del programmatore usarlo o PREFERIBILMENTE non usarlo.
Ciao
PS: non mi sembra di aver risposto a tutto, ma è tardi e l’uso di WP non aiuta molto 😛
PPS: Canto II terminato.. ma dobbiamo riscriverli tutti e 100 😛
Dimenticavo.. pelplimere è stato coniato da filipe di pollycoke 😉
Altra cosa che mi dimenticavo.. o che forse dovremmo chiarire, è il fatto se come portabilità si intende quella tra .NET e mono (ovvero prendere il codice scritto per .NET e ricompilarlo per mono) o se invece intendiamo poterlo usare su diversi OS (Windows, Linux, Unix, Solaris, ..) ma sembrpre usando come framework mono.
Ora sono di fretta, approfondirò appena ho 10 min liberi..
Ciao
Rispondo ad un po’ di cose … per le altre argomento a mente lucida che son completamente cotto dal lavoro.
Per quando riguarda l’ot – hai perfettamente ragione il blog e’ il posto peggiore per questo tipo di dialogo, ma questo si ha … magari si potrebbe continuare in altro canale ma a quel che vedo qualcuno legge questi capitoli della divina commedia, perche’ non pubblicarli?
Per quando riguarda mono = copia di .net non e’ proprio quello che volevo intendere o almeno in parte.
Se consideriamo .net (la specifica = nomenclatura delle classi loro comportamento e valori ritornati) allora mono e’ un’implementazione di .net.
Se consideriamo l’implementazione microsoft di .net mono non ha (spero) nulla a che spartire.
In parole povere mono non e’ una copia di .net ma una implementazione di .net.
Con portabilita’ intendo la possibilita’ di spostare codice da una VM ad un’altra che rispetti le specifiche (cosa che per la stessa natura di .net e’ difficile visto che specifiche complete non ne son mai state rilasciate ne tantomeno esiste un tools di compatibilita’).
Quindi si, se .net fosse realmente una specifica potre scrivere codice su windows e testarlo sull’implementazione microsoft e poi trasportalo su *nix su mono o qualunque altra implementazione futura.
Tornando al paragone Java, non esiste la sola JVM di Sun ma ne esistono altre tra cui quella di IBM e Bea. Su un server in produzione avevo problemi con l’implementazione della JVM di sun per IA64 (ed altretutto non esiste una JDK5.0) e sto utilizzando quella di Bea. Tutto questo senza cambiare ambiente di sviluppo che rimane su JVM Sun.
Questa per me e’ portabilita’, capacita’ di girare su architetture diverse e su su VM diverse che si adeguino ad un certo livello di specifica.
Tutto questo per .net (la simil specifica) non esiste e quindi quella portabilità di applicazioni da windows a *nix impossibile allo stato attuale.
Microsoft ha volutamente standardizzato solo una parte dell’architettura, brevettandone altra parte e non ha mai fornito un tools di compatibilita’ certificare una ipotetica implementazione.
Diversamente per Java dove esistono tools di compatibilita’ e certificazioni, prendi ad esempio la specifica JEE ed i vari application server certificati (jboss, oracle, ibm, bea e molti altri).
Questo processo di certificazione garantisce il programmatore che qualunque sia l’application server (o la JVM) su cui il codice verrà deployato esso continuera’ a funzionare (discorso prestazioni a parte).
Se non ci fossero le certificazioni non avremmo java sulla stragrante maggioranza di dispositivi mobili le cui implementazioni son le piu’ disparate anche in hardware.
bon mi fermo qui altrimenti scrivo solo cazzate … continuo domani sera che spero di essere piu’ fresco 🙂
[OT]Hemm.. per caso ti è arrivata la ma mail?
Cancella pure questo post “di servizio”[/OT]
Edit: Gigidn Inserito il commento come da mail … nessuna difficolta’ a farlo come era accaduto la volta scorsa.
Hai si? c’è qualche pazzo che perde tempo a leggerlo? Provo quasta
altra soluzione (citare i vari passaggi prima di rispondere, vediamo se
rende la cosa più leggibile, se non ti piace come soluzione edita pure,
non mi offendo
In questo caso mi trovo parzialmente d’accordo con te. Nel senso che è
vero ceh mono è una implementazione (per quato si riesce) di .NET, ma è
altrettanto vero che .NET non è una specifica di nessun tipo, ovvero se
un giorno decidono di cambiare il nome di tutte le
namespace/classi/metodì/proprietà nessuno potrà impedirglielo
(ovviamente perderebbero migliaia di sviluppatori, quindi non lo faranno
mai, ma potrebbero). Mono potrebbe diventare un ottimo prodotto a cui si
adatterebbe anceh .NET se venissero standardizzati i nomi di classi,
metodi etc… Il problema è che qualceh gorssa società doveva
promuoverlo e l’azienda che avrebbe dovuto farlo era Novell, ma sappiamo
benissimo cosa è successo e perchè lo sviluppo di mono si è rallentato,
ultimamente… penserò male, ma come dice un detto dalle mie parti a
pensar male non si fa peccato..
Quindi mono ora è a un buon punto, ma se vuole “sfondare” deve fare il
salto verso la standardizzazione, ora poi che Jave è rilasciata con GPL
la concorrenza si farà sempre più sentire.
Ok, non è proprio il mio concetto di portabilità, ma almeno su questo
punto ci siamo chiariti. Per me portabilità vuol dire poter scrivere un
programma, compilarlo con la VM di mono e eseguirlo su linux, windows,
dispositivi embedded (se c’è il framework) e così via. La possibilità di
portare un applicativo DIRETTAMENTE da .NET a mono è consigliabile, ma
non dovrebbe essere (IMHO) l’obbiettivo primario.
Ovvio che ci si deve muovere in quella direzione, quindi è preferibile
che la classe String (esempio) si comporti nello stesso modo su entrambi
i framework, in modo che un porting tra le tue sia il meno traumatico
possibile, ma se alcune classi sono “pericolose” dal punti di vista dei
brevetti allora usiamo un nome diverso (per esempio con le GTK#).
Proprio per il fatto che non è specifica va bene inseguirla (sulle
classi principali), ma come dicevo prima non c’è bisogno di farlo ad
ogni costo.
Verissimo, ed esistevano altre JVM (microsoft e alcune GPL) che però non
rispettavano a pieno il comportamento della JVM di SUN, e quindi alcuni
applicativi non funzionavano proprio bene con queste (almeno è quanto ho
letto e visto in alcuni casi, ma per piacere smentiscimi se ho detto
fregnacce, non uso Java, quindi sicuramente tu ne sai più di me )
Per lo stesso motivo potrebbero esistere molte altre alternative a .NET
e mono, ma fintanto non ci sono specifiche non ha senso fare un paragone
tra le due (ed eventualmente altre). IMHO il punto forte di mono è il
tipo di codice (se quindi C#) e la presenza di un certo numero di classi
(che vanno dall’uso di DB, crezioni di pagine Web, gestione XML,
creazioni di GUI, … ) già sviluppate.
Ora o sono io che non ti seguo o per me non ha molto senso quello ceh
dice, io faccio un applicazione su Mono e la compilo. Mi sposto su un
altro OS in cui ho installato mono (e GTK# se vogliamo usare GUI) e lo
stesso programma funziona nello stesso modo. Dove è il problema? Ho un
programma già scritto in .NET e voglio usarlo su Win? Bene provo a
compilarlo su mono (al ~100% non va ) e mi metto a sistemarlo per
potercelo compilare. A quel punto ho ancora un programma ceh funziona su
Win (ma basandomi su mono ) e *nix. Ora ti chiederai come mai usare
GTK# anche su win? Per mantenere la compatibilità a discapito delle
prestazioni (non si tratta più di usare le API dell’OS quindi il
processo di rendering è un pò più lento). Il fatto è che bisogna capire
se si vuole un sistema portabile (in quel caso installo mono e svilupo
con quello) o me ne frego e uso .NET (con tutte le cose belle che ha e
su mono non si hanno ancora).
Infatti SUN ha rilasciato Java e ha “spopolato”
Quindi secondo te sarebbe sufficiente avere un processo di
certificazione per codice .NET e mono? Secondo me non è una cosa che sta
in piedi perchè .NET non è uno standard e come dicevo prima se faccio un
tool di compatibilità e il giorno dopo cambiano il nome delle classi (e
possono farlo!)? VAa farsi BIIP tutto il resto. Quindi se vogliamo fare
passi in avanti standardizziamo il framework, e non solo il linguaggio
(in MS hanno spinto per la certificazione ECMA di C# ma non mi risulta
abbiano nemmeno proposto di standardizzare .NET…)
BINGO!
Certifichiamo sti stramaleddetti framework! Il fatto è che le
certificazioni arrivano solo se qualcuno spinge (leggi ha $ per
permetterselo) e quindi… fatevi due conti e capirete molte cose
Ora, sembra che io stia facendo l’avvocato del diavolo difendendo a
spada tratta mono, ma non è assolutamente così, vi assicuro che alcune
cose di mono non mi piacciono (per esempio il GC a volte fa un pò come
gli pare e non ho capito perchè), ma è un framework, accoppiato ad un
ottimo linguaggio che ha le potenzialità, ma che devono essere espresse
appieno. Se vuole fare il balzo e non essere limitato a *nix ma avere
possibilità arrivare ai livelli di Java deve essere standardizzato, ma
non vedo azienda che hanno convenienza a farlo (forse IBM, ma erano solo
voci che circolavano); quindi o cambia qualche cosa… o ciccia (ed è
veramente un gran peccato).
Se qualcuno è arrivato alla fine del cap. 3 e ha voglia di controbattere
o argomentare più a fondo…
PS: mando il link alla Mailing List di mono, spero non ti dispiaccia se
chiamo i rinforzi
[OT] Son in pieno trasloco … appena trovo 2 min liberi publico il messaggio e commenoto … scusa e scusate per l’inconveniente [/OT]
Inserito il commento 😀
Forse, anzi quasi sicuramente, mi son dimenticato a fare una premessa. Vedo di recuperare al 15esimo messaggio.
Credo che sia doveroso fare una distinzione tra:
a) Vantaggi di mono in quando framework;
b) Vantaggi di mono in quando framework che implementa .net;
Se vogliamo discutere sul punto (a) allora la discussione va spostata su argomenti quali stabilita’ del framework, manutenzione e sviluppi futuri e molto altro.
Se vogliamo discutere del punto (b) allora entrano in gioco molte delle critiche che ho fatto a mono etc etc.
Ora per quando riguarda il punto (a) per il momento escluderei mono come framework su cui basare progetti di livello enterprise. Non perche’ sia contro mono in assoluto ma perche’ come framework indipendente e’ ancora troppo giovane .. credo che per argomentare questo andrei OT pesantemente visto che tutta la discussione esula da mono in se e per se e rientra nelle tecniche di scelta, spesso individuali, di una tecnologia per un progetto. Dico solo questo e chiudo questa parte di discussione, tempo fa non scelsi JSF perche’ troppo giovane come tecnologia, oggi per alcune nuove applicazioni la stiamo usando, stessa cosa per le funzionalita’ del JDK5 a me usate in applicazioni enterprise da meno di un anno.
Tornando al punto (b) che a mio avviso e’ l’unico vero grande vantaggio che potrebbe avere mono, il porting di applicazioni scritte per M$ in maniera quasi indolore, senza tutta una serie di prerequisiti difficilmente cio’ potra accadere. Pertando il punto forte del framework ne rappresenta anche il suo piu’ grande limite sia a livello di compatibilita’ (quindi a livello tecnico) che di possibili problematiche legali.
Torno al mio trasloco 😦
Ciao, IMHO non può prescindere a) da b), nel senso che mono ha dei vantaggi nel fatto di essere un framework e altri che derivano di essere un porting (ok, per ora parziale) di .NET.
Per quanto riguarda A effettivamente è abbastanza giovane come piattaforma, ma abbastanza stabile da giustificare il team gnome a usarlo come “base”, quindi promette bene (anche IMHO), poi se fosse vero riceverebbe una spunto che sicuramente (ora come ora) serve.
Mmmm… non credo andremmo OT, stiamo sempre parlando di mono 😛
Mi interesserebbe molto una tua opinione, sinceramente non lo conosco così a fondo da dare un giudizio corretto, ma da quello che ho visto/percepito io l’unica cosa che sarebbe un pò da compilare è il GC, che non mi pare faccia un gran lavoro, anche perché mi pareva che ogni tanto andasse a cozzare con e politiche di gestione della memoria in cache del kernel, ma con le nuove versioni potrebbero (e spero lo abbiano fatto) aver sistemato o per lo meno migliorato.
Qui sono quasi d’accordo con te, è vero che la migrazione sarebbe QUASI indolore, ma già tutt’ora lo è. si tratterebbe quasi di modificare le classi GUI e se l’applicativo è sviluppato con un pò di buon senso dovrebbe andare (effettivamente dipende anche da come interagisce con il sistema/”DB MS based”).
Per i problemi legali non saprei, se il problema “grande” è l’uso di Windows.Form allora basterebbe chiamarlo Finestre e con un replace si sistema tutto.. tra le altre cose ci sarebbe da andare a capire come rientra il tutto nell’accordo MS/Novell, visto che ora è stato rilasciato,ma sinceramente non ne sarei in grado (ed esulerebbe dal tavolo “tecnico” 😀 )
Ciao e buon trasloco!
Oh, quante opinioni!
Il mondo e’ bello perche’ e’ vario 🙂
Premessa: lavoro nel team di Mono, ma sono pagato per scrivere codice, non per postare sui blog, cosa che sto facendo decisamente a tempo perso, solo perche’ vedo scritte tante cose inesatte… e comunque non ho la pretesa di far cambiare idea a nessuno.
Cio’ detto, e’ vero che Mono puo’ servire sia [a] come framework in se’ che [b] per portare software Windows su Linux.
La sua vera ragion d’essere e’ stata dall’inizio [a]: avere un framework migliore per sviluppare software su Linux/Unix, comunque in modo portabile su altre piattaforme.
Piu’ o meno casualmente, questo framework e’ specificato nello standard ECMA 335, ed un linguaggio di programmazione ben integrato col framework (C#) nello standard ECMA 334.
Ci sono varie ragioni *tecniche* per cui Mono si pone come framework “migliore”.
Intanto le specifiche su cui si basa (ECMA 335) non sono la brutta copia di Java, ma fanno dei veri passi avanti su diversi fronti: tipi generici veri, un bytecode molto piu’ versatile e potente, molto piu’ facile da compilare in codice nativo in maniera efficente anche da un JIT, un’infrastruttura di remoting piu’ generale e matura… ed anche la possibilita’ di avere codice “unsafe” (vedete dopo perche’ e’ utile).
Poi, alla base ECMA 335 e’ *veramente* neutrale rispetto al linguaggio di programmazione usato.
Un po’ quello che vuol diventare Parrot (la VM del Perl 6), ma Mono e’ gia’ qui ora.
Il problema che si cerca di affrontare e’ che ognuno ha il suo linguaggio preferito (Python, Ruby, Java, Javascript, Visual Basic… magari anche C#), ma quando si cerca di far interagire il tutto, va a finire che si devono reimplementare un sacco di infrastrutture in *tutti* i linguaggi.
L’obbiettivo di una macchina virtuale come quella implementata da Mono e’ quello di essere un ambiente efficente per tutti, in modo da poter massimizzare il riutiluzzo di librerie utili (persino Microsoft lo sta capendo, ed in Silverlight includera’ supporto per Python ed altri linguaggi “dinamici”, ma questa e’ un’altra storia).
Inoltre, il supporto alla chiamata diretta di codice nativo e’ un punto forte fondamentale tecnicamente, solo che bisogna sapere *quando* usarlo!
Facciamo il paragone con Java: se da Java voglio usare una libreria esistente in C, cosa devo fare? Ho due scelte: o la riscrivo in Java (il mito del “Pure Java”!), oppure uso JNI per fare un wrapper, che e’ una cosa *veramente* complicata. In ultima analisi, il riutiluzzo di codice esistente in C e’ decisamente scoraggiato.
Gli autori della specifica ECMA 335, invece, hanno capito che il software esistente ha un valore, e’ qui per restare, e va riutilizzato il piu’ possibile, e facilmente: fare un wrapper di una libreria C in C# e’ facilissimo proprio perche’ da C# di fatto vedo il codice nativo direttamente (con le p/invoke), e quando e’ il caso posso anche giocare con i puntatori. E’ assurdo dire “non e’ sicuro, non e’ bello, non e’ portabile…”, perche’ tanto io sto comunque usando codice C alla base! Tanto vale farlo con semplicita’… e *solo* dove serve.
La macchina virtuale capisce benissimo che se il contesto di esecuzione richiede sicurezza queste cose non sono ammesse, e non le permette.
Ora, mettiamo assieme i due punti precedenti, “neutralita’ rispetto al linguaggio” e “integrazione col codice nativo”, e vediamo come si comporta Mono rispetto ad altri framework.
Per fare un esempio concreto, vediamo cosa questo significa se si vuole scrivere software per Gnome.
Pensiamo a Java: la sua osticita’ al codice nativo fa si che i binding Java per GTK (e le librerie di Gnome in generale) siano troppo difficili da fare, manutenere, ed usare… va a finire che la gente usa SWT, che pero’ ha una API diversa ds GTK.
Con Mono, invece, il modello di oggetti del framework ed i GObject si integrano, cosi’ fare il binding e’ molto piu’ semplice, e l’API resta a livello logico la stessa, ma con tutti i vantaggi del codice managed (controllo, garbage collection…).
Questa integrazione tra GObject ed “oggetti ECMA 335” e’ una cosa tecnica, che Mono puo’ fare facilmente e con Java e’ un vero casino.
Ora, prendiamo Python, e supponiamo di creare un nuovo widget GTK in Python: pensate di poterlo riutilizzare poi in Ruby? O in Perl? O in C? Magari in C si riesce, ma a che prezzo?
Piu’ in generale, i framework esistenti sono mondi “chiusi”, che si identificano con il proprio linguaggio di programmazione, ma i loro componenti software possono vivere solo li’, ed essere usati in quel linguaggio.
Uno degli obbiettivi fondamentali di Mono, invece, e’ il riutilizzo di codice: essere una base per componenti software che interagiscono tra loro in modo ordinato.
Gia’ ora, in Mono, e’ possibile orendere una classe GTK#, estenderla in C#, riutilizzarla in VB, estenderla anche in Java (si, Java, tramite IKVM!), estenderla poi in Python (con IronPython)…
Altri linguaggi arriveranno, ma e’ la visione d’insieme che conta: siamo *stufi* di dover reimplementare un sacco di roba di base per ogni framework!
Questo per gli argomenti strettamente tecnici… quanto alla maturita’ di Mono… certo che c’e’ tanto da fare, ma se non funzionasse non sarebbe usato per indicizzare la Wikipedia, o per far girare la logica di Second Life (che sta migrando a Mono), od in progetti “enterprise” da centinaia di server e centinaia di migliaia di utenti.
E non preoccupatevi, Paolo sta riscrivendo il garbage collector, ed anche il JIT sta migliorando 🙂
Quindi le performance gia’ sono buone, e miglioreranno ancora.
L’obbiettivo dichiarato e’ di arrivare ad essere poco distanti dal C (Microsoft col suo .NET gia’ ci riesce, ma sono sicuro che il loro team del JIT ha piu’ manager di quanti ingegneri abbiamo noi, e poi loro supportano solo x86 e AMD64…).
Da ultimo, la questione [b], del porting da Windows a Linux… tecnicamente puo’ essere utile.
Commercialmente ancora di piu’, perche’ *tutte* le grandi aziende che tenteranno una migrazione da Windows a Linux hanno *almeno* un applicativo verticale, fatto in casa, assolutamente critico, che dovra’ girare anche su Linux o non possono migrare.
In questo senso Mono rischia di essere indispensabile alla diffusione di Linux in ambito enterprise, e quindi la questione [b] diventa (indirettamente) utile a tutta la community, perche’ una maggiore diffusione del sistema e’ comunque positiva.
Ma a noi a cui interessa solo Linux, bastano i vantaggi *tecnici* di Mono, e le Windows.Forms le lasciamo ad altri 😉
Spero di essere stato chiaro nelle mie spiegazioni.
Cio’ detto, fate quello che vi pare, nel mondo c’e’ posto per tutti (se si ha un minimo di amore in quello che si fa ed in come si interagisce con gli altri…).
Buon divertimento a scrivere codice!
Massi
Quoto al 90%
Nel senso che bellissimo il lavoro che state facendo su mono, solo che non si può “fregarsene” di System.Windows.Form, o per meno, ok, possiamo cambiargli nome e cose del genere per “aggirare” i problemi legali, ma la struttura delle classi dovrebbe rimanere uguale (o per lo meno molto, ma molto simile) in modo da poter riutilizzare semplicemente codice .NET, altrimenti la portabilità di applicativi “verticali” diventa inutile (o comunque molto complicata, se devo riscrivermi la GUI), soprattutto per determinati tipi di SW.
Siccome (da quasi profano del funzionamento interno) mi interesserebbe saperne di più hai sottomano qualche documento “tecnico ma non troppo” da leggere? Meglio ancora se in Italiano 😀
Ciao
[OT]Per caso sei arrivato qui dalla mail che ho mandato nella ML? :D[/OT]
@Massi
Allora siam in due che scriviamo a tempo perso, ma credo che ne esistano molti altri. Altresi’ scrivere e leggere blog o comunque confrontarsi con idee altrui non e’ proprio una perdita di tempo ma aiuta a fare il “mestiere”. Io come professione non scrivo codice, o almeno non lo faccio piu’ se non in casi eccezzionali, ma guido la scrittura dello stesso (nel mio team) e le scelte tecnologiche su cui basare i vari progetti. Per far questo spesso devo avere la “percezione della tecnologia” e riuscira a trovare il momento esatto in cui utilizzarla, troppo presto rischia di infognare un progetto, troppo tardi sarebbe arretrato. Per raggiungere questo scopo trovo estremamente utile confrontarmi con gli altri (fine divagazione).
Tornando a mono, le inesattezze che ravvisi nei vari commenti io li ritrovo anche nel tuo, ma andiam con ordine.
Premessa, molte dele cose che scrivi son sacrosante e condivisibili, e se leggi i miei commenti vedrai che diciam la stessa cosa anche se con parole diverse. Su altre invece non concordo:
ECMA 335 non e’ un framework dal mio punto di vista, esso specifica il CLI il framework per l’utente / programmatore e’ mono o .net con i suoi oggetti pronti.
Che il bytecode ECMA 335 o meglio CLI sia piu’ snello ed ottimizzato di quello java non ho dubi al riguardo, nasce molto dopo potendo contare sull’esperienza e sugli errori del primo ed altresi’ sul progresso tecnologico. Altra cosa, nella sua stesura non vi e’ la necessita’ di retrocompatibilita’, per tutte queste ragioni non ho dubi a credere che allo stato attuale il CLI abbia una struttura piu’ pulita rispetto al bytecode java. Detto cio’, miglioramenti anche significati possono essere apportati anche alla JVM ma discutere di cio’ e’ proprio OT.
Per quando riguarda la VM in grado di “accettare piu’ linguaggi” teoricamente su tutte le VM e’ possibile (esistono porting di python e php ad esempio per la JVM) e sembra la moda del momento, vedi appunto mono, parrot ma anche i modesti tentativi dello scripting in JDK1.6, ma siam sicuri che questa sia una scelta vincente??
Direi che il mito che su mono puoi utilizzare python, java o cio’ che ti pare e’ e restera’ un mito, e’ vero che puoi utilizzare il “linguaggio java” (vedere qualche commento sopra per la distinzione) ma non le API Java (o almeno non tutte), stessa cosa vale per tutti gli altri linguaggi.
A meno di rendere mono un mattone accozzaglia di mille mila API gli utenti potranno utilizzare la sintassi del loro linguaggio preferito ma le funzioni saranno quelle di mono o di qualunque altro framework.
Per esperienza le difficolta’ stanno nell’apprendere le API non nell’apprendere un nuovo “linguaggio” che alla fine come struttura sintattica / semantica non si discostano molto (da prendere con le pinze questa ultima affermazione).
Tornando al discorso piu’ liunguaggi per la stessa VM, sinceramente questa cosa mi terrorizza … mischiare piu’ linguaggi nello stesso progetto lo rende non manutenibile nel tempo e con il turn over degli sviluppatori la babele sarebbe destinata a crescere. Ok queste affermazioni son volutamente provocatorie ma non permetterei mai di mischiare codice scritto in linguaggi diversi all’interno di uno stesso progetto.
Su progetti diversi si potrebbe fare ma resto comunque scettico e contrario perche’ (supponendo l’equivalenza espressiva dei linguaggi, se non lo fossero ci sarebbe un linguaggio “privileggiato” per quella VM) limiterebbe lo spostamento di risorse da un progetto ad un’altro con tutte le conseguenze del caso.
Per quando detto non vedo di buon occhio delle VM che permettano di mischiare linguaggi tranne per i liunguaggi di scripting del client (JavaScript allo stato attuale) visto che comunque quella porzione di codice in quel linguaggio devo scriverla anche se il mio sogno e’ quello di avere un unico liunguaggio con il quale scrivere la business logic in grado di girare indifferentemene sul client e sul server e non il viceversa una VM che mi faccia girare piu’ linguaggi per adattarsi ai dialetti dei vari attori.
Per quando riguarda l’accesso al codice nativo continuo a sostenere l’approccio utilizzato da Java con JNI, scoraggiarne l’utilizzo. Dopotutto stiamo scrivendo codice per una VM proprio per evitare le complicazioni del “codice nativo” (vedi portabilita’ su architetture diverse) se ci infiliamo del codice nativo che senso ha piu’ la VM? E’ vero che ci son casi in cui cio’ non e’ possibile (vedi accesso alle funzioni di basso livello dell’hardware non direttamente disponibili alla VM o il riuso di codice ottimizzato e disponibile) ma poiche’ son casi e non la norma vedo nella complicazione di far questo un ottimo deterrente all’uso indiscriminato di codice nativo. Uno dei motivi per cui ho sempre storto il naso su C# e’ proprio la facilita’ di accesso al codice nativo, tu la vedi come una feature io ne ravviso un pericolo, preferisco non dare a disposizione, o comunque scoraggiarne l’uso, alcune funzionalita’ che metterle li belle e pronte per poi star li a perdere tempo spiegando di non utilizzarle.
Sul bind di Gnome non credo che il problema sia stato la complessita’ di JNI ma semplicemente sul supporto dato a tale progetto e sulla reale utilita’ di un tale binding. SWT e’ una realta’ ( con tutti i vantaggi e le problematiche del caso) non vedo perche’ non poteva esserlo Java/GTK.
Sul discorso “progetto giovane” le mie perplessita’ non riguardano le prestazioni ma la stabilita’ dello stesso, stiam parlando di applicazioni enterprise che non devono crashiare o almeno devono fallire raramente, e se aggiungo i difetti di un progetto giovane a quelli del mio software ho fatto la frittata. Ma ancora di piu’ un progetto giovane e’ carente in documentazione, esempi e librerie pronte all’uso …
Altro argomento dopo, il mio tempo da blog e’ scaduto.
Ritorno un pò i dietro, ma mi è capitato tra le mani questo link:
http://www.mono-project.com/Guide:_Porting_Winforms_Applications
E visto che si stava parlando di portabilità di codice tra .NET e mono…
Il Mono Migration Aalyzer dovrebbe far parte di CSharpDevelop ( http://www.icsharpcode.net/OpenSource/SD/Default.aspx ).
Devo trovare tempo dtestarlo un pò…
Ciao!