sviluppare applicazione desktop cross-platform: java o .net con mono?
Generale Cluster
vorrei svilupare un'applicazione desktop di tipo gestionale, che possa
girare su windows e su linux.
In passato, circa 6 anni fa, avevo sviluppato un'applicazione desktop in
java con database mysql e non mi ero trovato benissimo: lentezza nello
sviluppo se paragonato a strumenti come Visual Basic e prestazioni
veramente scadenti.
Da allora ho lavorato con java soltanto lato server con grande
soddisfazione, scegliendo altri linguaggi per lo sviluppo desktop sotto
windows.
Questa volta, approfittando della necessitￜ di compatibilitￜ con win e
linux, sto cercando di fare il punto della situazione, ma pare che come
al solito il mondo sia equamente diviso tra javisti e .nettisti :-)
Quali sono stati negli ultimi anni i mglioramenti di java lato desktop
(se ci sono stati) e perchￜ eventualmente preferirlo a .net con mono?
Grazie
Bye!
--
elimina unsampdoriano per rispondere via email
Pablo
> Questa volta, approfittando della necessitￜ di compatibilitￜ con win e
> linux, sto cercando di fare il punto della situazione, ma pare che come
> al solito il mondo sia equamente diviso tra javisti e .nettisti :-)
Sul fatto che sia "equamente" diviso ho i miei fondati dubbi:
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
e se provi a fare un conteggio dei framework, librerie con annessi e
connessi la situazione ￜ ancora piￜ sbilanciata.
> Quali sono stati negli ultimi anni i mglioramenti di java lato desktop
> (se ci sono stati) e perchￜ eventualmente preferirlo a .net con mono?
Miglioramenti su Java e su Swing ce ne son stati parecchi e sul sito
della Sun puoi ben documentarti a proposito [0].
Certo Java ha i suoi limiti [1] che perￜ sono anche ben noti (quindi
aggirabili) e conta su una gargantuesca comunitￜ di sviluppatori.
.net/mono ha sostanzialmente molti limiti in comune ma ha un, a mio
parere enorme, difetto in piￜ: ￜ "proprietￜ" di un'azienda.
Si puￜ raccontare che mono ￜ open source e che C# e CLI sono standard
ECMA ma resta il fatto che mono esiste perchￜ microsoft lo permette [2],
che ￜ sempre almeno una versione indietro rispetto a .net, che microsoft
supporta gli standard fin tanto (e quanto) le fa comodo e che ha giￜ
dimostrato decine di volte il suo scarso rispetto per gli sviluppatori
imponendo "conversioni" non indifferenti [3].
IMHO andarsi ad impelagare con ambienti di sviluppo che tra due giorni
potrebbero cambiare, con poche librerie disponibili e fortemente legati
ad un SO [4], mi sembra a dir poco avventato.
Tra l'altro basta fare un semplice raffronto: prendi uno sviluppatore
Visual Basic (linguaggio e IDE che 10-15 anni fa in molti settori era
considerato il "miracolo") e uno Java, dal 1997 ad oggi: lo sviluppatore
Java sostanzialmente usa lo stesso linguaggio (pur con le sue
evoluzioni) e gli stessi strumenti di base (dal compilatore a JDBC,
dalle classi per il File System a quelle per la rete), lo sviluppatore
VB ￜ passato dalla versione 4 alla 5 (esclusivamente 32 bit,
robetta...), poi alla 6 (nuovo sistema di connessione coi DB, nuova
reportistica. Solo per citarne due), poi a .net [5] 1.0, 1.1, 2.0, 3 e
ora 3.5. Ognuno di questi passaggi ￜ stato imposto e, sostanzialmente
(con i debiti distinguo), inevitabile. Con un costo non sempre enorme ma
certo piￜ pesante di quello tra le varie versioni di Java.
Tralascio questioni progettuali come il "dll hell" o la fortissima
integrazione tra strumenti di sviluppo e SO per non dilungarmi troppo.
Concludo dicendo che, "assolutamente IMHO ma non troppo" :), partire con
un progetto in .net, oggi, ￜ un po' come mettersi a fare gli
equilibristi legandosi la corda di sicurezza attorno al collo invece che
alla cintura ;)
> Da allora ho lavorato con java soltanto lato server con grande
> soddisfazione [...]
Una curiositￜ: visto che giￜ usi con soddisfazione Java lato server,
perchￜ non usarlo per fare un gestionale web o, al limite, "ibrido" (es.
Web Services / REST)? Avete particolari esigenze grafiche?
Ciao,
Pablo
[0] faccio riferimento solo a swing, vedi anche Java 2D e AWT:
http://java.sun.com/j2se/1.5.0/docs/relnotes/features.html#swing
http://java.sun.com/developer/technicalArticles/J2SE/Desktop/javase6/#Swing
[1] tendenza a un eccessivo overhead, pesantezza di molte librerie,
frequente sovradimensionamento, eccessiva prolissitￜ e linguaggio non
completamente OOP. Solo quest'ultimo e, parzialmente, il precedente sono
"difetti" del linguaggio, gli altri -IMHO piￜ gravi- dipendono
dall'"approccio", peraltro sempre sostenuto da Sun. Fortunatamente negli
ultimi anni sono nati molti strumenti e librerie piￜ "agili" e leggeri.
Tutte cose di cui qui abbiamo discusso, anche "intensamente" ;) , piￜ volte.
[2] evitando di massacrare novell con i suoi brevetti. Link a caso:
http://punto-informatico.it/1736070/PI/Brevi/microsoft-suse-linux-insieme.aspx
[3] cosa che genera incompatibilitￜ, nel caso .net cito la microsoft
stessa: http://msdn.microsoft.com/it-it/library/47a587hk.aspx
[4] e tecnologie collegate (IIS in primis): http://go-mono.com/status/
[5] cambiamento inevitabile visto il cessato supporto del preesistente:
http://msdn.microsoft.com/en-us/vbrun/ms788708.aspx
Generale Cluster
> Generale Cluster ha scritto:
>> Questa volta, approfittando della necessitￜ di compatibilitￜ con win e
>> linux, sto cercando di fare il punto della situazione, ma pare che
> Concludo dicendo che, "assolutamente IMHO ma non troppo" :), partire con
> un progetto in .net, oggi, ￜ un po' come mettersi a fare gli
> equilibristi legandosi la corda di sicurezza attorno al collo invece che
> alla cintura ;)
mi sembra un paragone un po' esagerato :-)
Ti do' ragione sul fatto che ￜ antipatico vedere divenire obsoleto un
ambiente di sviluppo cosￜ velocemente, ma non ￜ obbligatorio dover
passare immediatamente alle nuove versioni.
Guardando un po' in giro pare comunque di capire che .NET nativo sotto
windows sia piￜ performante di java, mentre java prevale rispetto
all'esecuzione di .net attraverso mono.
>
> > Da allora ho lavorato con java soltanto lato server con grande
> > soddisfazione [...]
>
> Una curiositￜ: visto che giￜ usi con soddisfazione Java lato server,
> perchￜ non usarlo per fare un gestionale web o, al limite, "ibrido" (es.
> Web Services / REST)? Avete particolari esigenze grafiche?
Principalmente perchￜ sarￜ un prodotto indirizzato a piccole imprese,
per cui vorrei sviluppare un prodotto che si installi in maniera
indolore con un semplice installer, senza bisogno di installare
application server o altri componenti aggiuntivi.
In secondo luogo, vorrei proteggere la mia proprietￜ intellettuale,
evitando di rilasciare i sorgenti, e cercando di evitare la possibilitￜ
di decompilare il programma.
Sotto questo aspetto mi pare di capire che sia una battaglia persa in
partenza, sia usando java, sia usando .net.
D'altra parte ho paura che in Italia i consumatori non siano ancora
abbastanza maturi per comprendere i principi dell'open source: il
rischio di rilasciare codice aperto e farsi scroccare l frutto di
giornate e giornate di duro lavoro ￜ altissimo.
Non ho una visione precisa sul panorama open source in Italia, per cui
se qualcuno avesse elementi per smentirmi gli sarei molto grato.
> Ciao,
> Pablo
[CUT]
bye!
spazza
> Principalmente perchￜ sarￜ un prodotto indirizzato a piccole imprese,
> per cui vorrei sviluppare un prodotto che si installi in maniera
> indolore con un semplice installer, senza bisogno di installare
> application server o altri componenti aggiuntivi.
Ma qualcuno ha visto le piccole aziende usare Linux sui desktop e nel
contempo non essere in grado di installare application server o cose del
genere? Penso che i due soli casi siano:
- o hanno competenza e motivazione zero e usano Windows
- o hanno skill elevati e forte coinvolgimento e non solo usano Linux ma
lo sanno rivoltare come una frittata
> In secondo luogo, vorrei proteggere la mia proprietￜ intellettuale,
> evitando di rilasciare i sorgenti, e cercando di evitare la possibilitￜ
> di decompilare il programma.
Stessa questione, se uno ￜ in grado di decompilare e pensa che sia un
buon investimento di tempo fare il reverse engineering del tuo prodotto,
sa anche trovarsi delle soluzioni alternative. Chi lo vuole a scatola
chiusa ￜ perchￜ non ha tempo da perdere.
> Sotto questo aspetto mi pare di capire che sia una battaglia persa in
> partenza, sia usando java, sia usando .net.
> D'altra parte ho paura che in Italia i consumatori non siano ancora
> abbastanza maturi per comprendere i principi dell'open source: il
> rischio di rilasciare codice aperto e farsi scroccare l frutto di
> giornate e giornate di duro lavoro ￜ altissimo.
> Non ho una visione precisa sul panorama open source in Italia, per cui
> se qualcuno avesse elementi per smentirmi gli sarei molto grato.
IMHO la questione ￜ un po' diversa: chiunque fornisca applicazioni
strategiche ha il dovere di fornire anche il codice, caso mai con una
clausola contrattuale che ne permette eventuali manipolazioni al solo
licenziatario, senza diffusione e per uso interno, e solo dopo un
congruo periodo di tempo. Cosa succede se la tua azienda dovesse
chiudere o, semplicemente, non essere piￜ interessata a portare avanti
il prodotto? I tuoi clienti si troverebbero con un'applicazione che non
possono aggiornare, non possono migrare e, spesso, da cui non possono
neanche estrarre i dati.
Sono ancora scottato dai problemi che ci ha causato un'applicazione di
contabilitￜ di cui non possedevamo i sorgenti e con il fornitore fallito
da tre anni, al momento del passaggio all'Euro.
Io un'applicazione del genere non la comprerei, a prescindere dal fatto
di essere in grado di persona di metterci le mani.
Ciao.
Enrico 'Henryx' Bianchi
> Quali sono stati negli ultimi anni i mglioramenti di java lato desktop
> (se ci sono stati) e perché eventualmente preferirlo a .net con mono?
Le migliorie sono state pesanti, e nel tuo caso e` preferibile a
Mono/.NET in quanto utilizzeresti una tecnologia a te conosciuta. Se poi
non ti interessa usare Java lato desktop, dai uno sguardo anche a Python
o a Ruby (sono tutti e due integrabili in Java per mezzo di
implementazioni ad hoc)
Enrico
Enrico 'Henryx' Bianchi
> .net/mono ha sostanzialmente molti limiti in comune ma ha un, a mio
> parere enorme, difetto in più: è "proprietà" di un'azienda.
Concetto interessante. Considerando che Java e` proprieta` di Sun, che
Sun non ha mai standardizzato il linguaggio con ECMA e che Sun e`
un'azienda, il maggior difetto di .NET e` l'essere proprieta` di
un'azienda???
Enrico
Pablo
> Concetto interessante. Considerando che Java e` proprieta` di Sun, che
> Sun non ha mai standardizzato il linguaggio con ECMA e che Sun e`
> un'azienda, il maggior difetto di .NET e` l'essere proprieta` di
> un'azienda???
Uno dei maggiori, sì.
Sia perché javac, hotspot e circa il 99% della standard library sono
rilasciate con licenza GPL [1], sia perché per Java esistono almeno
mezza dozzina di compilatori e VM alternative (alcune rese superflue e
quindi abbandonate dopo il rilascio di openJDK):
gcj e GNU Classpath (FSF), Jikes (IBM), IcedTea (Red Hat), SableVM,
Kaffe. Per citare solo i progetti che ho avuto modo di provare negli
anni, credo ce ne siano diverse decine.
Stesso discorso si può fare per IDE, AS, ORM, framework... Un nome per
tutti: apache foundation [2].
Mi riferisco sia al tipo di licenza sia al non indifferente problema dei
brevetti: FSF, IBM e Red Hat (in parte anche Sun) hanno "concesso" molti
dei loro brevetti alle comunità di sviluppatori (anche se nel frattempo,
soprattutto IBM e Sun -certo non FSF ;)-, facevano lobby a favore
dell'introduzione dei brevetti sw in Europa).
Non mi risulta che microsoft l'abbia fatto e la standardizzazione ECMA
riguarda solo parti di C# e CLI. Inoltre ha senso solo finché parliamo
di sw proprietario: Python o Ruby sono standard ECMA? Eppure credo
concorderai nel dire che sono più "liberi" e "sicuri" (scusa la
genericità dei termini) di .net. Sbaglio?
Sintetizzando: se domani Sun decidesse di "chiudere" (bloccare sviluppo,
download, documentazione, licenze, brevetti) Java ci sarebbero già
disponibili varie alternative; se Microsoft facesse lo stesso con .Net
domani gli sviluppatori C# sarebbero tutti a casa.
Questo, IMHO, è un problema non indifferente.
Ciao,
Pablo
[1] http://openjdk.java.net/groups/hotspot/
[2] il raffronto è rapido:
http://projects.apache.org/indexes/language.html#C#
http://projects.apache.org/indexes/language.html#Java
Generale Cluster
> Il Sat, 19 Dec 2009 13:21:14 +0100, Generale Cluster ha scritto:
>
>> Ciao a tutti,
>> vorrei svilupare un'applicazione desktop di tipo gestionale, che possa
>> girare su windows e su linux.
>
> considerazione Mac OSX. A mio avviso se consideri le tre piattaforme
> invece che quelle due solamente, focalizzi meglio la piattaforma più
> idonea.
mi chiedo più che altro se esistano molte aziende mac-only in Italia.
Dove si potrebbero trovare statistiche al riguardo?
Se si trattasse di una grossa fetta di mercato in effetti la scelta
sarebbe quasi obbligata.
grazie
Enrico 'Henryx' Bianchi
> Sia perché javac, hotspot e circa il 99% della standard library sono
> rilasciate con licenza GPL [1], sia perché per Java esistono almeno
> mezza dozzina di compilatori e VM alternative (alcune rese superflue e
> quindi abbandonate dopo il rilascio di openJDK):
Ok, pero` la JVM di Sun e` stata rilasciata GPL nel 2006, ovvero quasi
10 anni dopo la sua prima release. Lo standard ECMA di C# e di .NET e`
stato approvato nel 2003, ovvero tre anni prima del rilascio FLOSS di
Java. Per quanto riguarda invece il discorso VM, per .NET ho tre
progetti distinti, oltre alla VM Microsoft (Mono, DotGNU e
DotNetAnywere)
> gcj e GNU Classpath (FSF), Jikes (IBM), IcedTea (Red Hat), SableVM,
> Kaffe. Per citare solo i progetti che ho avuto modo di provare negli
> anni, credo ce ne siano diverse decine.
Per quanto riguarda le JVM implementate, basta vedere la pagina apposita
su Wikipedia[1] . Per quanto riguarda le JVM da te citate, fatta
eccezione per Jikes, si basano tutte su GNU ClassPath o sono progetti
abbandonati (in particolare, SableVM)
> Non mi risulta che microsoft l'abbia fatto e la standardizzazione ECMA
> riguarda solo parti di C# e CLI.
Microsoft ha rilasciato sotto OSP molte delle sue tecnologie, siano esse
coperte brevetto, siano esse implementazioni di qualcosa di gia`
esistente. Inolter, per quanto riguarda la standardizzazione, se non
ricordo male ci sono anche parti di .NET . Se poi si legge il sito di
Mono, vi e` riportato chiaramente come ci si sta comportando con le
tecnologie coperte da brevetti, ovvero, si tengono separate dal core
le tecnologie "problematiche" e, parallelamente, si implementano
tecnologie equivalenti ma libere (e.g. Gtk#)[2]
> Inoltre ha senso solo finché parliamo
> di sw proprietario: Python o Ruby sono standard ECMA? Eppure credo
> concorderai nel dire che sono più "liberi" e "sicuri" (scusa la
> genericità dei termini) di .net. Sbaglio?
Ni. E` vero che linguaggi open source non sono certificati come
standard, ma e` vero anche che vi e` una gestione ed una "cultura" del
progetto ben differente da quella che vi e` dietro Java o .NET . Per
esempio, un utente Python prendera` sempre come riferimento
l'implementazione in C, nonostante vi siano varie implementazioni
disponibili. Inoltre, nessuno mi vieta di creare una VM che implementi
un subset della libreria standard o che implementi dei comandi
proprietari, ma questo non significa che la mia implementazione sara`
utilizzata d'ora in poi come implementazione di riferimento
In definitiva, gli strumenti e le possibilita` per lavorare con
Mono/.NET sotto linux ci sono. L'unico motivo per non scegliere tale
piattaforma e` perche` non si adatta alle nostre esigenze, e non perche`
vi sono dei remoti problemi di licenza (problemi che gli sviluppatori di
Mono stessi si sono fatti fin dall'inizio e che hanno affrontato,
secondo me, in modo abbastanza soddisfacente)
Enrico
[1] http://en.wikipedia.org/wiki/List_of_Java_virtual_machines
[2] http://www.mono-project.com/FAQ:_Licensing
Pablo
> 10 anni dopo la sua prima release.
Certo, però io parlo della situazione attuale. In passato, proprio per
motivi di licenza, ho usato compilatori e VM non Sun (gcj, con risultati
più che decorosi). Anche ora uso prevalentemente OpenJDK.
Questo solo per dire che non sono certo un fan di Sun e che se ho una
forte diffidenza verso microsoft è per problemi concreti riscontrati
utilizzando prodotti di questa azienda.
> Per quanto riguarda invece il discorso VM, per .NET ho tre
> progetti distinti, oltre alla VM Microsoft (Mono, DotGNU e
> DotNetAnywere)
Su Mono ho già espresso i miei dubbi, DotGNU mi risulta fermo alla
release 0.1 da anni [1], DotNetAnywere credo sia inutilizzabile.
Lato Java hai citato tu la lista delle alternative esistenti [2]: è
esattamente quanto affermavo precedentemente (una alternativa
"vincolata" contro varie alternative "libere").
> Per quanto riguarda le JVM da te citate, fatta
> eccezione per Jikes, si basano tutte su GNU ClassPath o sono progetti
> abbandonati (in particolare, SableVM)
Avevo dichiarato esplicitamente come mi riferissi, a scopo di esempio,
solo a progetti che conoscevo direttamente e come alcuni fossero
abbandonati.
> Se poi si legge il sito di
> Mono, vi e` riportato chiaramente come ci si sta comportando con le
> tecnologie coperte da brevetti, ovvero, si tengono separate dal core
> le tecnologie "problematiche" e, parallelamente, si implementano
> tecnologie equivalenti ma libere (e.g. Gtk#)[2]
Quello che mi lascia perplesso è che in Mono/Ximian vi sono già stati
cambiamenti di rotta e l'attuale proprietà (Novell) non mi suggerisce
grande affidabilità sul fronte dell'autonomia da microsoft. Tutto qui.
> Ni. E` vero che linguaggi open source non sono certificati come
> standard, ma e` vero anche che vi e` una gestione ed una "cultura" del
> progetto ben differente da quella che vi e` dietro Java o .NET . [...]
Su questo non potremmo essere più d'accordo ;)
Personalmente però vedo riguardo a Java (sicuramente anche per pregressi
problemi organizzativi e finanziari di Sun) un approccio più "open"
rispetto a .Net. Ho cercato di argomentare obiettivamente i motivi di
questa mia convinzione (per farlo dettagliatamente dovrei scrivere un
libro... ;) ) anche se è inevitabile che nelle convinzioni si
intromettano delle pregiudiziali "ideologiche" :)
> Inoltre, nessuno mi vieta di creare una VM che implementi
> un subset della libreria standard o che implementi dei comandi
> proprietari, ma questo non significa che la mia implementazione sara`
> utilizzata d'ora in poi come implementazione di riferimento
No, ma il mio discorso era leggermente diverso: se domani Guido van
Rossum "impazzisse" e decidesse di chiudere Python, pochi giorni dopo ci
sarebbe un altro CPython realizzato da tutti (o buona parte de) gli
altri sviluppatori che non hanno con lui vincoli contrattuali o simili.
Presumo che per Sun e Java la situazione sarebbe abbastanza simile
mentre per .Net credo che i risultati sarebbero molto diversi
essenzialmente per due motivi:
- i sorgenti di .Net sono proprietari microsoft;
- i sorgenti di Mono sono GPL ma gestiti da una società fortemente
legata a microsoft e creati quasi esclusivamente da sviluppatori
dipendenti della stessa.
Anticipo una possibile critica: anche Java è sviluppato in gran parte da
dipendenti Sun ma quello che fa la differenza è che molte competenze non
sono concentrate in azienda ma distribuite anche tra tutti gli
sviluppatori indipendenti che hanno portato avanti i vari progetti di
compilatori e VM alternative.
> In definitiva, gli strumenti e le possibilita` per lavorare con
> Mono/.NET sotto linux ci sono.
Questo non l'ho messo in dubbio.
> L'unico motivo per non scegliere tale
> piattaforma e` perche` non si adatta alle nostre esigenze, e non perche`
> vi sono dei remoti problemi di licenza (problemi che gli sviluppatori di
> Mono stessi si sono fatti fin dall'inizio e che hanno affrontato,
> secondo me, in modo abbastanza soddisfacente)
Probabilmente questa è l'unica cosa in cui siamo sostanzialmente e
concretamente in disaccordo.
I problemi non sono così remoti e non riguardano solo le licenze [3] ma
anche lo stato delle implementazioni (una major version indietro,
costantemente, sommata alle incompatibilità tra versioni) e di brevetti.
Non entro nel merito degli accordi microsoft-novell e conseguenti
dichiarazioni, né dei vari interventi di Miguel de Icaza a sostegno di
(IMHO discutibili) operazioni di microsoft né dei suoi frequenti
"scontri" con Stallman e FSF.
Concordo invece che la scelta dovrebbe essere guidata da esigenze
concrete ma non dimentichiamo i casi (chi ci ha sbattuto il naso li
ricorda bene) in cui progetti potenzialmente validi e apparentemente
molto solidi sono finiti sostanzialmente in fumo: visual basic, J++,
delphi, kylix, J++.
Ciao e buone feste! :)
Pablo
[1] Tra l'altro è indicativo ed esplicativo il link in home page:
http://www.gnu.org/software/dotgnu/danger.html
[2] http://en.wikipedia.org/wiki/List_of_Java_virtual_machines
[3] faccio notare che, come indicato nel link che suggerisci:
http://www.mono-project.com/FAQ:_Licensing
alcune componenti sono rilasciate sotto Microsoft Public License,
incompatibile con la GPL.
Pablo
> ricordo male ci sono anche parti di .NET .
P.S.:
Se a qualcuno interessasse la lista completa è riepilogata qui:
http://msdn.microsoft.com/en-us/netframework/aa569283.aspx
Morde
> Concordo invece che la scelta dovrebbe essere guidata da esigenze concrete ma
> non dimentichiamo i casi (chi ci ha sbattuto il naso li ricorda bene) in cui
> progetti potenzialmente validi e apparentemente molto solidi sono finiti
> sostanzialmente in fumo: visual basic, J++, delphi, kylix, J++.
Mi permetto di entrare in discussione in virtￜ del fatto che provengo
da anni di programmazione professionale con delphi.
Piￜ che essere finito in fumo, *di fatto* delphi ￜ ormai relegato in
una nicchia. Ben solida, ma pur sempre nicchia. E questo e' il motivo
per cui da ICLD mi sono messo in mare e sono sbarcato qui, su ICJ. :D
Borland in questi anni con politiche discutibili (tra le quali un
tentativo di rilasciare un IDE per compilare cross platform win + linux
(Kylix) ha via via abbandonato delphi, per arrivare poi a venderlo e
dedicarsi ad un altro settore.
Delphi poi passￜ di mano da borland ad codegear, e in ultimo finalmente
a embarcadero. Attualmente embarcadero sta investendo moltissimo su
delphi 2010 (13 release di un'IDE ￜ un percorso di tutto rispetto ;)) e
gli investimento sono stati premiati con la colossale vendita di 1
milione di licenze alla russia l'anno scorso.
Comunque tutte queste info le potete trovare su wikipedia oppure, se
interessati, venite a fare quattro chiacchiere su ICLD ;-)
Esiste anche un "cugino" opensource di delphi, il progetto Lazarus:
un'IDE opensource che si basa su un compilatore object pascal
(freepascal) open anche quello. La qualitￜ della community ￜ veramente
impressionante, il supporto ￜ in tempo quasi reale e i bug segnalati
vengono fixati anche in 10 minuti dagli sviluppatori: quella ￜ una
community opensource dove veramente si respira aria di software libero,
di qualitￜ e condivisione totale della conoscenza. :-)
Ero tentato di rispondere all'OP che e' indeciso tra .net e java che
per i gestionali delphi e' veramente un linguaggio adatto allo scopo,
ma onestamente parlando se dovessi partire da zero oggi per scrivere un
gestionale, non me la sentirei di partire con delphi..
Saluti a tutti e buone feste.
--
Morde
Enrico 'Henryx' Bianchi
> Certo, però io parlo della situazione attuale.
La situazione attuale e` che Java e` open source e Mono e` open source.
Punto. Scegliere uno o l'altro "per motivi di licenza" non e` un
discorso sensato, in quanto in tutti e due i casi ci potrebbe essere una
chiusura da parte delle aziende che lo sviluppano (Novell/Ximian per
Mono, Oracle/Sun per Java) ma, grazie proprio al fatto che e` stato
compiuto il passo di rendere open source il linguaggio (con o senza
standardizzazione), nessuno vieta un fork e la continuazione del
progetto[1]. Inoltre, Mono ha fatto un passo avanti proprio per evitare
qualsiasi problema legale: ha isolato le parti del framework
potenzialmente pericolose a livello di brevetti ed ha fatto in modo che
siano facilmente rimpiazzabili con parti open source e libere da
qualsiasi problema (e.g. Windows.Forms e` completamente rimpiazzabile da
Gtk#)
> Su Mono ho già espresso i miei dubbi, DotGNU mi risulta fermo alla
> release 0.1 da anni [1], DotNetAnywere credo sia inutilizzabile.
Personalmente non uso nessuno dei tre, ma da quello che ho capito
DoNetAnywere e` dedicato ai sistemi embedded
> Lato Java hai citato tu la lista delle alternative esistenti [2]: è
> esattamente quanto affermavo precedentemente (una alternativa
> "vincolata" contro varie alternative "libere").
Teniamo presente che le varie alternative o implementano parte delle
funzionalita` dell'implementazione Java di Sun, o utilizzano lo stesso
framework per implementare la libreria standard. Mi riferisco in
particolare a tutte quelle JVM che utilizzano la GNU Classpath, che di
conseguenza soffrono tutte degli stessi problemi (e.g. un bug nella GNU
Classpath si ripercuote su tutte le JVM che la utilizzano)
> Quello che mi lascia perplesso è che in Mono/Ximian vi sono già stati
> cambiamenti di rotta e l'attuale proprietà (Novell) non mi suggerisce
> grande affidabilità sul fronte dell'autonomia da microsoft. Tutto qui.
Non e` importante, in quanto allo stato attuale Mono e` una realta`
consolidata e poco dipendente dall'attuale sviluppatore (leggi: fork se
ce ne fosse bisogno)
> Personalmente però vedo riguardo a Java (sicuramente anche per pregressi
> problemi organizzativi e finanziari di Sun) un approccio più "open"
> rispetto a .Net.
Perche` Sun interpella direttamente la comunita` per eventuali modifiche
al linguaggio e alla piattaforma, mentre Mono si appoggia a cio` che
Microsoft implementa nella sua versione di .NET . Di contro, pero`,
quello che a molti non sembra chiaro e` che Microsoft non e` interessata
ad affossare il progetto Mono, in quanto le permette di erodere
posizioni al concorrente piu` diretto (ovvero Java). Se cosi` non fosse,
allora sarebbe stato molto piu` sensato far chiudere il progetto fin da
subito
> Presumo che per Sun e Java la situazione sarebbe abbastanza simile
> mentre per .Net credo che i risultati sarebbero molto diversi
> essenzialmente per due motivi:
Sarebbero uguali per il motivo che citi sotto
> - i sorgenti di Mono sono GPL ma gestiti da una società fortemente
> legata a microsoft e creati quasi esclusivamente da sviluppatori
> dipendenti della stessa.
Come hai appena detto, sono GPL. Personalmente ho sempre criticato tale
licenza, ma non posso negare che, come tutte le licenze OSI/FLOSS, ha
l'indubbio vantaggio di mantenere in vita un progetto indipendentemente
dalla decisione dell'azienda e dalle competenze di coloro che
prenderanno in mano l'eventuale fork. Nell'ambito FLOSS si e` visto con
la storia di Interbase, che ha creato Firebird e che, nonostante fosse
portato avanti da persone estranee alla Borland, ha permesso al progetto
di prosperare e di essere apprezzato dagli addetti ai lavori (nonche`
dalle aziende utilizzatrici)
> Anticipo una possibile critica: anche Java è sviluppato in gran parte da
> dipendenti Sun ma quello che fa la differenza è che molte competenze non
> sono concentrate in azienda ma distribuite anche tra tutti gli
> sviluppatori indipendenti che hanno portato avanti i vari progetti di
> compilatori e VM alternative.
Personalmente non lo reputo un grosso vantaggio, in quanto non e` detto
che tali persone sappiano mettere mano al codice scritto da Sun. Prova
ne e` il fatto che, fino al momento in cui Sun non si e` decisa a
rendere Java FLOSS, tutte le varie implementazioni non Sun (o non
certificate da essa) erano in uno stato di arretratezza abbastanza
marcato
> I problemi non sono così remoti e non riguardano solo le licenze [3] ma
> anche lo stato delle implementazioni (una major version indietro,
> costantemente, sommata alle incompatibilità tra versioni) e di brevetti.
E` ovvio che siano indietro, in quanto attualmente l'atteggiamento di
Microsoft nei confronti di Mono e` neutro (ovvero, non ostacola il
progetto ma nemmeno lo aiuta). Di conseguenza, Mono si ritrova ad
inseguire eternamente le implementazioni di Microsoft, visto che queste
ultime sono disponibili solo al momento del rilascio della nuova
versione
> Ciao e buone feste! :)
Buone feste anche da parte mia
Enrico
[1] Per fare un esempio concreto e vicino a molti in questo
gruppo, e` previsto che Oracle abbandoni qualsiasi attivita` su
NetBeans, in quanto ha gia` un IDE di sua proprieta` e in quanto fa
parte dell'Eclipse Foundation. In altre realta`, questo avrebbe
significato la totale chiusura del progetto, cosa che probabilmente non
avverra` in quanto NetBeans e` open source
Enrico 'Henryx' Bianchi
> onestamente parlando se dovessi partire da zero oggi per scrivere un
> gestionale, non me la sentirei di partire con delphi..
Giusto per capire, perche`? Se ho un prodotto funzionante ebuono per
quel lavoro, perche` non sfruttarlo in tal senso?
Enrico
Pablo
> Punto. Scegliere uno o l'altro "per motivi di licenza" non e` un
Non è un mio discorso: ho più volte ribadito che parlo di scelta basata
su licenze E implementazioni E strumenti disponibili E conoscenze E
brevetti.
Ognuno di questi fattori ha un peso diverso a seconda delle esigenze
soggettive di chi compie la scelta.
> Personalmente non uso nessuno dei tre, ma da quello che ho capito
> DoNetAnywere e` dedicato ai sistemi embedded
Credo che anche DotGNU stia andando in quella direzione: l'unico
(sotto)progetto che vedo procedere è Portable.Net...
> Non e` importante, in quanto allo stato attuale Mono e` una realta`
> consolidata e poco dipendente dall'attuale sviluppatore (leggi: fork se
> ce ne fosse bisogno)
Dici? Non ne sono molto convinto: tempo fa (metà 2007) curiosavo tra i
sorgenti e il 90% abbondante dei contributi arrivava da dipendenti
Ximian. Può essere che la situazione sia cambiata.
Chi sarebbe in grado di portare avanti un fork, e in quali tempi?
Nel caso di Java sia IBM che Red Hat (per rimanere in ambito aziendale)
hanno programmatori competenti che portano avanti le rispettive
implementazioni alternative a Sun JDK (IBM JDK e IcedTea).
Anche GNU Classpath continua a procedere (ed è ben utilizzabile) e la
lista di sviluppatori (indipendenti) che partecipano è nutrita.
> Perche` Sun interpella direttamente la comunita` per eventuali modifiche
> al linguaggio e alla piattaforma, mentre Mono si appoggia a cio` che
> Microsoft implementa nella sua versione di .NET . Di contro, pero`,
> quello che a molti non sembra chiaro e` che Microsoft non e` interessata
> ad affossare il progetto Mono, in quanto le permette di erodere
> posizioni al concorrente piu` diretto (ovvero Java).
Su questo siamo più che d'accordo.
Però parlando solo di questo trascuri il fatto che la stragrande
maggioranza dei progetti "di contorno" (dalle librerie per XML agli
application server agli IDE, dagli strumenti per la reportistica alle
implementazioni di JSP agli strumenti di gestione) in ambito Java sono
portati avanti da terzi (in particolare Apache Foundation) e Sun ha
limitata voce in capitolo.
Microsoft invece propone .Net e tutte le tecnologie per impiegarlo: IIS,
Visual Studio, una standard library più estesa. Vero che esistono anche
le alternative (es. Sharp/MonoDeveloper) però, come dicevo, sono sempre
o una versione indietro o parziali.
Detto più in sintesi: in ambito Java (e ancor più J2EE) è la comunità
open source che "detta legge", in ambito .Net è microsoft.
> Come hai appena detto, sono GPL.
Però ho anche detto che le competenze sono tutte in casa Novell, era
questo il punto debole della questione.
> Personalmente non lo reputo un grosso vantaggio, in quanto non e` detto
> che tali persone sappiano mettere mano al codice scritto da Sun. Prova
> ne e` il fatto che, fino al momento in cui Sun non si e` decisa a
> rendere Java FLOSS, tutte le varie implementazioni non Sun (o non
> certificate da essa) erano in uno stato di arretratezza abbastanza
> marcato
Sull'arretratezza non mi pronuncio: ho usato implementazioni libere e
gli unici limiti erano nelle prestazioni (problema anche di Sun JDK fino
alla 1.4.2, passando da sistemi windows a *NIX), "aggirabili" con minime
modifiche al codice.
E' d'altronde anche comprensibile quando da un lato hai centinaia di
sviluppatori stipendiati, dall'altra poche decine che ci lavorano part-time.
Java inoltre è stato rilasciato sotto GPL da ormai 4 anni, se anche gli
sviluppatori "indipendenti" fossero stati "arretrati" di certo ora hanno
recuperato. Almeno per mia esperienza personale.
> E` ovvio che siano indietro, in quanto attualmente l'atteggiamento di
> Microsoft nei confronti di Mono e` neutro (ovvero, non ostacola il
> progetto ma nemmeno lo aiuta). Di conseguenza, Mono si ritrova ad
> inseguire eternamente le implementazioni di Microsoft, visto che queste
> ultime sono disponibili solo al momento del rilascio della nuova
> versione
IMHO questo è un buon motivo per escludere .Net dalla lista degli
ambienti di sviluppo da usare per partire con un nuovo progetto: o ti
vincoli a un fornitore oppure usi tecnologie "obsolete"? Non mi pare il
massimo.
A questo punto l'unica cosa certa, IMHO, è che possiamo parlarne per
mesi e non ci troveremo mai d'accordo... ;-)
Ciao,
Pablo
Pablo
> quel lavoro, perche` non sfruttarlo in tal senso?
Domanda un po' tautologica ;) : � evidente che se il prodotto �
funzionante e buono lo usi. Bisogna per� capire SE � funzionante e
buono... :)
Pablo
> Mi permetto di entrare in discussione in virtￜ del fatto che provengo da
> anni di programmazione professionale con delphi.
Se ti consola ho usato, per studio e lavoro, Pascal per quasi dieci anni
e Delphi per due (quando era uno dei "pezzi da 90", parlo del '96-'98) :)
Tutt'ora per certi mini-progetti uso freepascal e uno dei miei
principali clienti sviluppa un'applicazione in Delphi, ora in fase di
passaggio a Java.
> Ero tentato di rispondere all'OP che e' indeciso tra .net e java che per
> i gestionali delphi e' veramente un linguaggio adatto allo scopo, ma
> onestamente parlando se dovessi partire da zero oggi per scrivere un
> gestionale, non me la sentirei di partire con delphi..
Se non per altro per il fatto che il supporto ai 64 bit, annunciato n
volte, ancora non esiste.
Stesso problema/approccio che ha "affossato" il Turbo Pascal (ottimi
ambiente e linguaggio) quando si "crogiolava" nei 16 bit mentre il resto
del mondo passava ai 32: Delphi (evoluzione di TP) ￜ arrivato ai 32 bit
piￜ di un anno dopo rispetto a Visual Basic in un periodo in cui c'era
una vera e propria "corsa agli armamenti", perdendo enormi quote di mercato.
Da dire anche che il supporto per il web ￜ molto limitato (problema
condiviso anche da freepascal), altra cosa che IMHO indica un approccio
un po' "a rilento".
Veramente un peccato perchￜ, secondo il mio modestissimo parere, Pascal
ￜ uno dei migliori linguaggi di sempre. Non entro nei dettagli delle
motivazioni :)
Ciao,
Pablo
Enrico 'Henryx' Bianchi
> Non è un mio discorso: ho più volte ribadito che parlo di scelta basata
> su licenze E implementazioni E strumenti disponibili E conoscenze E
> brevetti.
Potrebbe essere, in effetti mi sono un po' perso da questo punto di
vista del discorso, andando a coprire solo i punti piu` scottanti della
vicenda Mono/.NET: la licenza e i brevetti
> Dici? Non ne sono molto convinto: tempo fa (metà 2007) curiosavo tra i
> sorgenti e il 90% abbondante dei contributi arrivava da dipendenti
> Ximian. Può essere che la situazione sia cambiata.
Te l'ho detto, personalmente la vedo alla stessa maniera di quello che
e` successo con Firebird: se qualcuno ha interesse, il progetto verra`
portato avanti indipendentemente dai tempi per riprendere dal punto in
cui si sono fermati i vecchi sviluppatori (e qua sto parlando in
generale, non nello specifico)
> Microsoft invece propone .Net e tutte le tecnologie per impiegarlo: IIS,
> Visual Studio, una standard library più estesa. Vero che esistono anche
> le alternative (es. Sharp/MonoDeveloper) però, come dicevo, sono sempre
> o una versione indietro o parziali.
Non metto la mano sul fuoco riguardo alle tecnologie web, ma Sun offriva
(ed offre) a pagamento la propria IDE, prima basata su Forte for Java ed
ora basata su NetBeans. La differenza con .Net e` che le alternative
sono diventate piu` concorrenziali rispetto al prodotto ufficiale
> o ti
> vincoli a un fornitore oppure usi tecnologie "obsolete"? Non mi pare il
> massimo.
Dipende da cosa intendi per obsoleto. Per dire, Mono supporta le
funzionalita` di Vb.Net e C# dalla 2.0 alla 4.0, mentre per l'intera
piattaforma non sono implementate alcune caratteristiche di .Net 3.0 .
Infine, per LINQ (una delle tecnologie piu` interessanti di .Net) non e`
implementata solo una caratteristica sfruttata (e, probabilmente,
sfruttabile) solo con SQL Server.
Insomma, a livello di linguaggio ci siamo, mentre a livello di
libreria ci stanno lavorando. Allo stato attuale l'utente finale ha
tutte le funzionalita` di .Net ma non ha tutti i framework implementati
nell'ultima major release (framework che, da quello che vedo, non sono
essenziali nel normale utilizzo della piattaforma)
> A questo punto l'unica cosa certa, IMHO, è che possiamo parlarne per
> mesi e non ci troveremo mai d'accordo... ;-)
Beh, direi che questo e` lapalissiano :)
Enrico
Pablo
> e` successo con Firebird: se qualcuno ha interesse, il progetto verra`
> portato avanti indipendentemente dai tempi per riprendere dal punto in
> cui si sono fermati i vecchi sviluppatori (e qua sto parlando in
> generale, non nello specifico)
Sì, è verosimile.
Da dire però che le "traversie" di Interbase/Firebird di certo non hanno
giovato alla sua diffusione e/o reputazione.
> Non metto la mano sul fuoco riguardo alle tecnologie web, ma Sun offriva
> (ed offre) a pagamento la propria IDE, prima basata su Forte for Java ed
> ora basata su NetBeans. La differenza con .Net e` che le alternative
> sono diventate piu` concorrenziali rispetto al prodotto ufficiale
Da un lato, non usando IDE se non quando sono "obbligato" (arrivando
dalla vecchia scuola apprezzo più un buon editor e un decente prompt dei
comandi), la considero una differenza poco rilevante; pensando in
termini più generali mi sembra sostanziale, soprattutto se estendiamo il
discorso non alla sola IDE ma a tutte le varie implementazioni di (parti
di) J2EE.
Tanto per fare un esempio concreto, per quanto soggettivo: ho un paio di
applicazioni, non banali, che girano sotto Tomcat (5.5.28) su JVM
1.6_13, scritte con Java (1.3, poi ricompilato per 1.4.2) quando Tomcat
era praticamente appena uscito.
Ritengo che difficilmente mi troverei nella stessa situazione se avessi
scritto codice .Net (fingiamo fosse già uscito o slittiamo tutto avanti
di 6 anni) e, sinceramente, ho seri dubbi che scrivendo codice .Net oggi
riuscirei a riutilizzarlo/mantenerlo "intatto" per 10 anni.
> Dipende da cosa intendi per obsoleto. Per dire, Mono supporta le
> funzionalita` di Vb.Net e C# dalla 2.0 alla 4.0, mentre per l'intera
> piattaforma non sono implementate alcune caratteristiche di .Net 3.0 .
> Infine, per LINQ (una delle tecnologie piu` interessanti di .Net) non e`
> implementata solo una caratteristica sfruttata (e, probabilmente,
> sfruttabile) solo con SQL Server.
Ammetto che la mia ultima verifica approfondita sullo stato di Mono
risale a oltre un anno fa, per cui non posso ribadire dettagliatamente.
Certo quando controllo (sulla pagina dello "status" di Mono) vedo sempre
una discreta lista di "lavori in corso", cosa di cui sento ancora
lamentarsi (vagamente, non ho approfondito oltre la "chiacchiera da
macchina del caffè") alcuni colleghi .nettisti.
> Beh, direi che questo e` lapalissiano :)
D'altronde non si discute per arrivare a un terrificante pensiero unico
ma per imparare qualcosa di nuovo ;)
Varie informazioni che hai fornito durante il dibattito di certo mi
torneranno utili e te ne ringrazio :)
Alla prossima,
Pablo
Enrico 'Henryx' Bianchi
> Da dire però che le "traversie" di Interbase/Firebird di certo non hanno
> giovato alla sua diffusione e/o reputazione.
Non che prima avesse una grossa reputazione eh, Interbase, secondo me,
e` sempre stato un progetto sottovalutato rispetto alle potenzialita`
che offre
> Ritengo che difficilmente mi troverei nella stessa situazione se avessi
> scritto codice .Net (fingiamo fosse già uscito o slittiamo tutto avanti
> di 6 anni) e, sinceramente, ho seri dubbi che scrivendo codice .Net oggi
> riuscirei a riutilizzarlo/mantenerlo "intatto" per 10 anni.
Non credo, uno dei pregi maggiori di Microsoft e` che non ha mai
abbandonato del tutto le vecchie tecnologie e non penso che incomincera`
a farlo con .Net (e.g. ancora oggi e` possibile sviluppare con GDI, MFC
o COM+, mentre solo con l'avvento delle versioni a 64bit e` stato
abbandonato definitivamente il supporto all'architettura a 16bit)
> Certo quando controllo (sulla pagina dello "status" di Mono) vedo sempre
> una discreta lista di "lavori in corso", cosa di cui sento ancora
> lamentarsi (vagamente, non ho approfondito oltre la "chiacchiera da
> macchina del caffè") alcuni colleghi .nettisti.
Boh, da quello che vedo ci dovrebbero essere tutte le strutture "core",
mentre dovrebbero mancare tutte quelle strutture che per qualche motivo
richiedono piu` tempo a reimplementarle correttamente (e.g. WPF) oppure
sono dipendenti per una specifica piattaforma (e.g System.Management,
che e` implemetata solo per Windows e non per le altre piattaforme
supportate). Da questo punto di vista, un riassunto e` riportato in
questa pagina: http://www.mono-project.com/Compatibility
> Varie informazioni che hai fornito durante il dibattito di certo mi
> torneranno utili e te ne ringrazio :)
A dire il vero sono informazioni che anch'io ho imparato durante la
discussione, personalmente programmo in Java e in Python, in .Net non ho
mai scritto nemmeno una riga di codice (falso, l'ho usato per replicare
un test di memoria fatto alla carlona) :)
Enrico
P.S. non nego pero` che vorrei scrivere qualcosa in .Net, quasi quasi
riscrivo un progetto lavorativo su tale piattaforma...
Morde
> Giusto per capire, perche`? Se ho un prodotto funzionante ebuono per
> quel lavoro, perche` non sfruttarlo in tal senso?
Si, hai ragione, non ti ho motivato la mia risposta. I motivi
principali sono due: la futuribilitￜ di un gestionale in delphi e
quella della mia professione.
Costruendo da zero un software, lo devi progettare che sia evolvibile
nel minor tempo possibile e con lo sforzo minore possibile. Java si
presta ad una modellazione totale, usando pattern e framework sostenuti
dalle communities, delphi non ha tutto questo (anche se embarcadero
attualmente sta lavorando bene con la delphi community).
La seconda cosa, ￜ che se continuo a restare su delphi tra qualche anno
sarￜ come uno dei tanti cobolisti della passata generazione:
disperatamente alla ricerca di un impiego come manutentore di codice
legacy.
Per chiudere la questione, vai su monster.it, digita delphi - milano
poi premi invio.. rifai la stessa cosa per java - milano e confronta il
numero dei risultati: ora capisci il perchￜ delle mie motivazioni. ;)
ciao
--
Morde
Morde
> Veramente un peccato perchￜ, secondo il mio modestissimo parere, Pascal ￜ uno
> dei migliori linguaggi di sempre. Non entro nei dettagli delle motivazioni :)
Concordo con te, infatti il passaggio su java a livello di linguaggio ￜ
del tutto spontaneo e indolore. Ma chiudo quei il thread, siamo OT.
ciao
--
Morde
Pablo
> riscrivo un progetto lavorativo su tale piattaforma...
Così poi magari cambi opinione e ne riparliamo... ;)
Ciao!
Pablo
nbvcx
> In 20/12/2009 21:09 Pablo wrote:
>
>> Inoltre ha senso solo finché parliamo
>> di sw proprietario: Python o Ruby sono standard ECMA? Eppure credo
>> concorderai nel dire che sono più "liberi" e "sicuri" (scusa la
>> genericità dei termini) di .net. Sbaglio?
>
> Ni. E` vero che linguaggi open source non sono certificati come
> standard,
I linguaggi non sono open source (o closed source), bensì le librerie...
nbvcx
> Pablo ha scritto:
>> Generale Cluster ha scritto:
>>> Questa volta, approfittando della necessitￜ di compatibilitￜ con win
>>> e linux, sto cercando di fare il punto della situazione, ma pare che
> [CUT]
>> Concludo dicendo che, "assolutamente IMHO ma non troppo" :), partire
>> con un progetto in .net, oggi, ￜ un po' come mettersi a fare gli
>> equilibristi legandosi la corda di sicurezza attorno al collo invece
>> che alla cintura ;)
>
> mi sembra un paragone un po' esagerato :-)
> Ti do' ragione sul fatto che ￜ antipatico vedere divenire obsoleto un
> ambiente di sviluppo cosￜ velocemente, ma non ￜ obbligatorio dover
> passare immediatamente alle nuove versioni.
>
> Guardando un po' in giro pare comunque di capire che .NET nativo sotto
> windows sia piￜ performante di java, mentre java prevale rispetto
> all'esecuzione di .net attraverso mono.
Prego, fare degli esempi concreti: applicazioni che girano meglio con
.NET rispetto a Java.
Non dimenticare che .NET ￜ una copia della piattaforma Java.
Il vantaggio di .NET rispetto a Java ￜ la grande spinta
commerciale data dalla Microsoft grazie ai suoi sistemi operativi.
Java, a mio parere, soffre di una cattiva reputazione a causa
della lentezza con cui gli applet venivano scaricati dal web
anni fa. Ciￜ era dovuto alla poca banda disponibile ai tempi,
non certo alla inefficienza di Java, tantￜ che Microsoft ha dovuto
ha pensato bene di creare una piattaforma simile (.NET) a Java.
Non dimenticarti, inoltre, il linguaggio J#...
>>
>> > Da allora ho lavorato con java soltanto lato server con grande
>> > soddisfazione [...]
>>
>> Una curiositￜ: visto che giￜ usi con soddisfazione Java lato server,
>> perchￜ non usarlo per fare un gestionale web o, al limite, "ibrido"
>> (es. Web Services / REST)? Avete particolari esigenze grafiche?
>
> Principalmente perchￜ sarￜ un prodotto indirizzato a piccole imprese,
> per cui vorrei sviluppare un prodotto che si installi in maniera
> indolore con un semplice installer, senza bisogno di installare
> application server o altri componenti aggiuntivi.
>
> In secondo luogo, vorrei proteggere la mia proprietￜ intellettuale,
> evitando di rilasciare i sorgenti, e cercando di evitare la possibilitￜ
> di decompilare il programma.
> Sotto questo aspetto mi pare di capire che sia una battaglia persa in
> partenza, sia usando java, sia usando .net.
[cut]
Esistono dei compilatori per creare codice macchina da bytecode.
Pablo
> I linguaggi non sono open source (o closed source), bensì le librerie...
Dipende: le librerie con sportelli sono closed, quelle con antine di
vetro sono shareware e quelle aperte sono tipicamente open. Però
attenzione che così i libri si impolverano!
Dai, che senso ha fare i pignoli sul termine 'linguaggi' e poi buttare
lì il termine "librerie"? ;)
Sappiamo che i linguaggi a livello teorico sono puramente semantica e
sintassi ma su un ng di programmazione è palese che si parli anche
dell'implementazione: compilatore, interprete, linker e un'altra mezza
dozzina di cose... E l'implementazione è sottoposta a licenze (open o
closed).
Anche una libreria poi può essere definita solo come insieme di
specifiche e funzionalità, senza che ne esista un'implementazione.
Ciao,
Pablo
nbvcx
> nbvcx ha scritto:
>> I linguaggi non sono open source (o closed source), bensì le librerie...
>
> Dipende: le librerie con sportelli sono closed, quelle con antine di
> vetro sono shareware e quelle aperte sono tipicamente open. Però
> attenzione che così i libri si impolverano!
>
> Dai, che senso ha fare i pignoli sul termine 'linguaggi' e poi buttare
> lì il termine "librerie"? ;)
> Sappiamo che i linguaggi a livello teorico sono puramente semantica e
> sintassi ma su un ng di programmazione è palese che si parli anche
> dell'implementazione: compilatore, interprete, linker e un'altra mezza
> dozzina di cose... E l'implementazione è sottoposta a licenze (open o
> closed).
Secondo me ti sbagli ancora. Non si tratta di voler fare il pignolo.
> Anche una libreria poi può essere definita solo come insieme di
> specifiche e funzionalità, senza che ne esista un'implementazione.
Davvero?
Enrico 'Henryx' Bianchi
> Prego, fare degli esempi concreti: applicazioni che girano meglio con
> .NET rispetto a Java.
Dipende da cosa intendi per girare meglio. All'esecuzione del codice
Java per l'esecuzione di una console[2], sulla mia macchina[1] viene
riportata una occupazione di memoria di 11.5Mb circa. L'esecuzione con
mono del codice C# per l'esecuzione della stessa console[3], invece
occupa 6.3Mb circa. A questo punto, mi viene semplice dire che Mono, a
differenza di Java, gira meglio in quelle applicazioni in cui il fattore
"occupazione memoria" e` determinante (ok, mi si potra` controbattere
che che in quei casi non si adoperano linguaggi come C# o Java, ma
comunque rimane sempre un fattore da prendere in considerazione)
Enrico
[1] Debian Linux x86_64, Java 1.6.0_17, Mono 2.4.3
[2]
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
public class Console {
public static void main(String[] args) {
BufferedReader input;
String curString;
boolean state;
input = new BufferedReader(new InputStreamReader(System.in));
state = true;
while (state) {
System.out.print("> ");
try {
curString = input.readLine();
if (curString.equals("\\q")) {
state = false;
}
} catch (IOException e) {
state = false;
}
}
}
}
[3]
using System;
class HelloWorldApp
{
public static void Main()
{
string cmd;
bool state;
state = true;
while(state == true)
{
Console.Write("> ");
cmd = Console.ReadLine();
if (cmd == "\\q")
{
state = false;
}
else
{
Console.WriteLine(cmd);
}
}
}
}
Pablo
> Secondo me ti sbagli ancora. Non si tratta di voler fare il pignolo.
"Ancora"? La frase da te citata non era mia.
Per me va benissimo fare i pignoli ma, IMHO, o lo si fa sempre o meglio
evitare.
> Davvero?
Sì, hai dubbi?
Enrico Franchi
>>> I linguaggi non sono open source (o closed source), bens� le
librerie...
> Secondo me ti sbagli ancora. Non si tratta di voler fare il pignolo.
Tecnicamente hai ragione. In questo concordiamo tutti, un linguaggio e'
puramente un ente matematico e fine della storia.
Io continuamente lotto contro termini aberranti come "linguaggio
interpretato/compilato/byte-compilato[0]", che si riferiscono
tipicamente all'implementazione principale di riferimento e non al
linguaggio.
Eppure la gente continua ad usarli e spesso non si riesce a fare capire
quanto e' aberrante la dizione, anche portando esempi di linguaggi che
sono tutti e tre.
La dizione "linguaggi open source" e' chiaramente impropria. Suppongo
che ci si riferisce ai linguaggi nati in seno alla comunita' open
source, le cui implementazioni principali di riferimento sono pure open
source. In particolare credo parlasse di Python, Perl, Ruby, forse PHP.
Inoltre, non e' questione di "libreria" open source. Nei casi sopra
menzionati, anche la vm e il compilatore (o l'interprete) sono open
source. Essendo programmi, la definizione si applica. Idem anche per la
libreria standard.
*Ma* niente vieta di avere implementazioni closed source con libreria
closed source. E l'essere open della libreria standard non era il
carattere discriminante di tali linguaggi: oggi ci sono una decina di
librerie standard del C open source. Ma il Enrico *non* intendeva il C.
Intendeva parlare proprio delle piattaforme costruite per *linguaggi*
nati nella comunita' open source. Sono i *linguaggi* ad essere nati in
seno alla comunita', non solo le implementazioni (cosa che ormai e' vera
per quasi qualunque linguaggio, Java, C#, C, C++, Python, Perl, Ruby,
Haskell, Scheme, ...).
--
-riko
Enrico Franchi
> A questo punto, mi viene semplice dire che Mono, a
> differenza di Java, gira meglio in quelle applicazioni in cui il fattore
> "occupazione memoria" e` determinante (ok, mi si potra` controbattere
> che che in quei casi non si adoperano linguaggi come C# o Java, ma
> comunque rimane sempre un fattore da prendere in considerazione)
IMHO questo test non e' troppo significativo.
Qui dava addirittura 23 MB di real memory sul Java.
Python per lo stesso programma (che diventa 4 righe) prende 3.1 MB.
E non direi che Python e' particolarmente adatto per il fattore memoria.
*E* in Java potresti pur sempre usare una macchina virtuale ME e vedi
che la memoria scende. Comunque qua usando -Xint per dire scende di 8
MB.
Ma credo che sta cosa dei programmi giocattolo non sia troppo
significativa.
--
-riko
Pablo
> differenza di Java, gira meglio in quelle applicazioni in cui il fattore
> "occupazione memoria" e` determinante
Beh dai, se facciamo confronti sui risultati (su un singolo risultato,
poi...) senza verificare le implementazioni tanto vale lanciare i dadi ;)
Ci vogliono dieci minuti a scrivere una classe Java che, preso uno
stream in ingresso, lo converta in stringa in uscita con un'occupazione
di memoria molto minore e velocit� superiore di almeno un ordine di
grandezza. Da vedere poi cosa succederebbe su piattaforme diverse e/o ad
ogni cambio di versione.
Per concretizzare (solo alcuni dettagli trovati al volo):
- se controlli nel codice di Mono, relativamente a Console, trovi
istruzioni tipo:
static string [] locations = { "/etc/terminfo", "/usr/share/terminfo",
"/usr/lib/terminfo" };
(in /trunk/mcs/class/corlib/System/TermInfoDriver.cs)
[DllImport ("kernel32.dll", EntryPoint="ReadConsoleInput",
SetLastError=true, CharSet=CharSet.Unicode)]
extern static bool ReadConsoleInput (IntPtr handle, out InputRecord
record, int length, out int nread);
(in /trunk/mcs/class/corlib/System/WindowsConsoleDriver.cs)
- su Console.cs trovi una chiamata al garbage collector per pulire gli
stdin, out ed err (ridurr� la memoria ma diminuir� anche le prestazioni?)
- le using/import esplicite le vediamo, ma quelle implicite?
Il tutto verificando solo il linguaggio: senza prendere in
considerazione nessun aspetto delle rispettive VM, quindi
fingendo/ipotizzando che il tutto giri sulla stessa VM o comunque su VM
equivalenti.
E' abbastanza scontato che se deleghi al SO operativo (o a librerie
scritte con linguaggi di pi� basso livello) parte delle operazioni
l'occupazione in memoria sia pi� ridotta.
L'esempio di Enrico usando Python � palese.
Che poi il codice C# mi piaccia molto pi� di quello Java (verboso oltre
misura) � un altro discorso... :)
Ciao,
Pablo
Enrico 'Henryx' Bianchi
> IMHO questo test non e' troppo significativo.
Molto probabile, pero` era un test pur sempre indicativo per i miei
scopi
Enrico
Enrico 'Henryx' Bianchi
> Costruendo da zero un software, lo devi progettare che sia evolvibile
> nel minor tempo possibile e con lo sforzo minore possibile.
E questo e` lapalissiano, indipendentemente se stiamo parlando di C#,
Java o qualsiasi altro linguaggio
> Java si
> presta ad una modellazione totale, usando pattern e framework sostenuti
> dalle communities, delphi non ha tutto questo (anche se embarcadero
> attualmente sta lavorando bene con la delphi community).
Non capisco questo punto. Cosa intendi che in Delphi non esistono
pattern (???) o framework non sostenuti dagli utenti? Per capirmi, se io
voglio programmare in Delphi/Freepascal, di certo faro` di tutto per
evitare librerie o framework che mi legano in qualche modo agli autori o
alla piattaforma (e.g. sicuramente evitero` Delphi in quanto mi
costringe a legarmi ad una sola piattaforma). Se mi servono librerie per
la connessione al database, quasi certamente usero` Zeos (una libreria
simil JDBC) o tiOPF (un ORM). Se mi servono librerie per la gestione
della rete, sicuramente mi appoggero` a Synapse. Se devo disegnare una
GUI, oltre a Lazaruso e/o a Delphi, nulla mi vieta di usare toolkit per
cui e` stato fatto il porting (Gtk, Qt) o toolkit disegnati ad hoc
(fpGUI), e cosi` via. Ovviamente non scelgo Delphi/Freepascal per la
creazione di web services, in quanto non e` pensato per essere
utilizzato in tale senso, anche nulla ci vieta di scrivere CGI con esso
> La seconda cosa, è che se continuo a restare su delphi tra qualche anno
> sarò come uno dei tanti cobolisti della passata generazione:
> disperatamente alla ricerca di un impiego come manutentore di codice
> legacy.
Bisogna vedere anche l'altro lato della medaglia: Nonostante sia tra
coloro che giudicano il Cobol come un linguaggio che merita di terminare
il proprio corso, come programmatore Cobol non solo non farei parte
della massa (e quindi invece di adattarmi, posso chiedere), ma sarei
anche piu` ricercato proprio per fare manutenzione a quelle applicazioni
legacy il cui costo di reimplmenetazione sarebbe troppo alto e per cui
stanno scomparendo le figure che sanno metterci mano
> Per chiudere la questione, vai su monster.it, digita delphi - milano
> poi premi invio.. rifai la stessa cosa per java - milano e confronta il
> numero dei risultati: ora capisci il perchè delle mie motivazioni. ;)
Senza offesa, ma piuttosto che cercare su di un sito (inteso come
locazione) specifico, preferisco cercare su un sito di raccolta dati
globale :)
In questo senso Tiobe mostra chiaramente l'andamento delle richieste dei
linguaggi di programmazione. E Delphi, nonostante si trovi in 11esima
posizione, e` tra i linguaggi classificati "di serie A". Tra l'altro,
sempre seguendo i trend mostrati da Tiobe, sarebbe piu` interessante
puntare proprio su .Net (C#) o su ObjC, in quanto sono i linguaggi che
nell'ultimo anno hanno avuto una crescita maggiore
Enrico
P.S. mi rendo conto che la discussione sia andata palesemente OT, pero`
ritengo che sia molto interessante e costruttiva, senza contare che non
saprei dove continuarla
Enrico 'Henryx' Bianchi
> Beh dai, se facciamo confronti sui risultati (su un singolo risultato,
> poi...) senza verificare le implementazioni tanto vale lanciare i dadi ;)
Come ho detto (un po' qua e un po' di la), per me era un test indicativo
sulle prestazioni a livello di memoria di alcuni linguaggi/VM che
implementavano del codice abbastanza comune senza mettere in mezzo
ottimizzazioni varie. In queto senso e` da vedere il mio test (un test
da strapazzo, aggiungerei). Per test piu` seri, direi che Alioth e` piu`
significativo :)
Enrico
Morde
> P.S. mi rendo conto che la discussione sia andata palesemente OT[..]
Per questo motivo ho dato una risposta veloce e priva di
approfondimenti.
Concordo sulla linea generale del tuo discorso: hai citato
framework/librerie disponibili, ma non so se li hai provati/utilizzati
per lavoro: l'unica cosa che ti garantisco ￜ che non sono tutti cosￜ
semplici da usare per sviluppare e fare manutenzione su progetti
longevi.
Chiunque si trovi a mettere mani su codice un pￜ vecchio, non troverￜ
synapse bensi' una qualche versione degli Indy, a livello DB Zeos sono
degli ottimi componenti ma nel codice legacy troverai nei casi peggiori
BDE, in quelli meno peggiori ADO, nei migliori DBExpress..
Se vuoi fare della persistenza, i delphisti delle communities ti
suggeriscono tiOpf, tutti ne parlano bene, io stesso lo conosco, ma non
ho mai lavorato su un progetto che lo stia utilizzando. TiOpf ￜ ottimo
ma la documentazione ￜ lacunosa, non c'ￜ community a supporto e lo
sviluppo ￜ fermo da anni.
In un precedente impiego ho utilizzato un ORM scritto da noi stessi,
dove sono ora me ne sono fatto uno da me, semplice e poco complesso.
Quello che intendo dirti ￜ che hai fatto bene a contraddirmi perchￜ
effettivamente ￜ vero che ci sono librerie, ma non sono cosￜ semplici e
facili da utilizzare, e non si trovano quasi mai nei progetti longevi,
per questo motivo non ne ho parlato.
>come programmatore Cobol non solo non farei parte della massa
>(e quindi invece di adattarmi, posso chiedere), ma sarei
>anche piu` ricercato proprio per fare manutenzione a quelle applicazioni
>legacy
Il tuo discorso non fa una piega, io stesso ne ho un forte riscontro,
il fatto ￜ che personalmente parlando non voglio passare tutta la mia
carriera a mettere cerotti su codice altrui. Lo sto giￜ facendo, questo
mi dￜ il pane, ma le mie aspirazioni sono altre :-)
Riguardo la mia citazione di monster.it ovviamente non mi offendo mica,
ed i numeri presentati da tiobe rafforzano ancor di piￜ le mie
convinzioni, e cioￜ che non ha senso, IMHO, investire ulteriori risorse
personali e finanziarie su delphi.
Se vuoi continuare questa piacevole e costruttiva "chiacchierata" in
pvt, mi trovi all'account mordeitaly (su gmail).
ciao
--
Morde
Enrico 'Henryx' Bianchi
> Quello che intendo dirti è che hai fatto bene a contraddirmi perchè
> effettivamente è vero che ci sono librerie, ma non sono così semplici e
> facili da utilizzare, e non si trovano quasi mai nei progetti longevi,
> per questo motivo non ne ho parlato.
E` ovvio che in progetti longevi non hai a disposizione delle librerie
che invece avresti in progetti piu` giovani. Intendiamoci, il mio
discorso e` rivolto soprattutto in funzione del fatto che si andra` a
sviluppare un nuovo progetto, non che si andra` a manutenere un vecchio
progetto iniziato chissa` quando da chissa` chi. Nello scenario da te
proposto qualsiasi linguaggio ha gli stessi problemi, ovvero nesuno ti
garantisce che le librerie utilizzate siano ancora mantenute o, nel caso
di ambienti ad ampio spettro tipo Java o .Net, nessuno ti
garantisce che siano state deprecate (emblematico in Java il caso
dell'oggetto java.util.Date). Nell'ambito di avvio di un nuovo
progetto, personalmente rimango della mia idea, ovvero, nel caso in cui
il committente non richiede espressamente una determinata tecnologia:
- Userei Pascal/Delphi/Lazarus nel caso vi siano richieste a basso
livello o il progetto richieda di utilizzare delle funzionalita`
proprie del sistema operativo (e.g. per un progett, sono stato
costretto in Java 1.3 ad implementare una finestra always on top, con
tutti i problemi del caso).
- Userei Java nel caso in cui il progetto debba essere multipiattaforma
oppure sia in ambito web.
- Userei Python in caso debba sviluppare delle procedure di contorno
e/o sia un progetto in ambito web.
Ovviamente, caso per caso sceglierei le tecnologie nonche` le librerie
da adottare, tenendo conto pero` di quali siano gli obiettivi del
progetto stesso
Enrico