Newsgroup: it.comp.java
Titolo: sviluppare applicazione desktop cross-platform: java o .net con mono?

Ciao a tutti,
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

 (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

 Pablo
[CUT]
bye!


 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.

 (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

 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

 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

 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


 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

 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.

 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

 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

 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

 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

 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

 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... :)

 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

 mesi e non ci troveremo mai d'accordo... ;-)
Beh, direi che questo e` lapalissiano :)
Enrico

 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

 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...

 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

 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

 riscrivo un progetto lavorativo su tale piattaforma...
Così poi magari cambi opinione e ne riparliamo... ;)
Ciao!
Pablo

 standard,
I linguaggi non sono open source (o closed source), bensì le librerie...

 partenza, sia usando java, sia usando .net.
[cut]
Esistono dei compilatori per creare codice macchina da bytecode.

 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

 specifiche e funzionalità, senza che ne esista un'implementazione.
Davvero?

 .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);
        }
      }
    }
  }

 Davvero?
Sì, hai dubbi?

 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

 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

 "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

 IMHO questo test non e' troppo significativo.
Molto probabile, pero` era un test pur sempre indicativo per i miei
scopi
Enrico

 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

 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

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

 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