Newsgroup: it.comp.os.dibattiti
Titolo: Forte dubbio sulle VM e vari framework

Lo prendo da wikipedia:
"La suite di prodotti .NET (tutto in lettere maiuscole, pronunciato
dotnet) è un nuovo progetto all'interno del quale Microsoft ha creato
una nuova piattaforma di sviluppo software caratterizzata da
trasparenza rispetto alla rete sottostante, indipendenza dalla
piattaforma hardware e software, e facilità di sviluppo rapido delle
applicazioni."
Dico io... ma questo non è il compito di un sistema operativo?
Nel caso della Java JVM sono favorevole per la portabilità del codice
su vari OS, ma questo
maledetto framework a che cavolo serve?
Cioè secondo me , dato che non riescono a fare un OS sicuro affidabile
ecc... devono mettere
una VM trà il OS e l'applicazione, secondo me questo è contro a tutta
la teoria informatica.
Se un programma ha N operazioni già il OS la carica di M , poi ci
mettiamo una VM e sinceramente N+M+VM mi sembra un po troppo , no?

 mettiamo una VM e sinceramente N+M+VM mi sembra un po troppo , no?
No.
Sicuro di non essere il solito anti-microsoft per principio che passa da
queste parti?
-- 
Lawrence - 
http://www.oluyede.org/blog
http://www.neropercaso.it
"Nothing is more dangerous than an idea
if it's the only one you have" - E. A. Chartier

No è che semplicemente non capisco perchè creare queste VM per
aumentare la sicurezza
quando basta concentrarsi sul SO!!
si arriverà ad avere una macchina virtuale per ogni processo in
esecuzione per paura
che intacchi il SO.
in sostanza gira un SO con un altro SO light reggente l'applicazione.
Mi sembra uno spreco , forse sono solo nostalgico di una linea di
comando un 
compilatore C  e fai tutto quel che vuoi.

 compilatore C  e fai tutto quel che vuoi.
Si ciao, ripassa fra qualche decennio.

Dimenticavo ...
http://www.microsoft.com/presspass/press/2006/sep06/09-26MicroFrameworkDKPR.mspx

mettiamo una VM e sinceramente N+M+VM mi sembra un po troppo , no?
Purtroppo il framework .net è irrinunciabile per me, e lo sarà ancora di piu 
fra un po quando uscirà il 3.0
(vedi i vari WPF WWF ecc..)
Dico purtroppo perchè sebbene sia piuttosto documentato, non è stato fatto 
il porting su altri Os (il progetto mono ad esempio è fermo ...), visto che 
non è proprio così banale ... come immaginavo!
Di conseguenza sono legato a Microsoft, ma sono felice di esserlo finchè mi 
"ripagano" con uno strumento così potente ...
Proprio qualche giorno fa mi chiedevo come stesse procedendo Java .. ma non 
capisco se si muove in questa direzione o meno .. mah ... a me non sembra 
!!! 

 !!!
Qual'è "quella direzione"?
Realizzare un framework sborone _teoricamente portabile_ ma
praticamente non portato?
Spero proprio di no.
In ogni caso, sta per uscire ufficialmente Java 1.6 Mustang:
http://java.sun.com/javase/6/webnotes/features.html
Raffaele

 compilatore C  e fai tutto quel che vuoi.
Mi sembra una stupida nostaglia dato che la linea di comando e il
compilatore C esistono ancora (e quei sistemi che critichi sono in parte
scritti in C, "da linea di comando")


 capisco se si muove in questa direzione o meno .. mah ... a me non sembra
In quale direzione?


Quindi a quanto pare sono l'unico a non apprezzare questi mitici
sistemi a VM!
ok pero' dovete ammettere che un programma compilato è piu veloce di
un compilato e fatto girare su VM!

 un compilato e fatto girare su VM!
Lo sai vero che i programmi .NET sono compilati?



compilati in un codice ibrido e poi reinterpretati dalla vm, almeno in
java è cosi.

 java è cosi.
In .NET c'è il JIT che genera codice nativo e il pre-jitter. Ma
sicuramente lo sapevi prima di criticare, no?
Mi viene da ridere a pensare di dover difendere .NET :D


 Mi viene da ridere a pensare di dover difendere .NET :D
.NET rocks ... java sta lentamente morendo, surclassata dal framework 
microsoft.

Mah , rimango della mia idea , datemi un gcc e un po di librerie e si
fà tutto !
Se cmq viene in aiuto la vm per la portabilità ok, ma mi sembra che
sia solo per windows.
Quindi smettetela di fare cazzate e concentratevi sui SO e i
compilatori che è già tanto

 compilatori che č gią tanto
Ok, grazie del consiglio. Tra 15 anni, dopo che avrai studiato i JIT e i
GC, ti rileggerai e riderai di te :).
-- 
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.4
Blog: 
http://vvolonghi.blogspot.com
New Pet: 
http://www.stiq.it

 microsoft.
Evvai con le cazzate.


 fà tutto !
Ti concedo solo assembly, le librerie te le scrivi, e le 100 vite che
ti serviranno te le fai dare da non so chi ...

 microsoft.
Non su questo pianeta.
Raffaele

 un compilato e fatto girare su VM!
Si vede che non fai il programmatore per vivere.

 fà tutto !
Arieccoti, se vede proprio che non fai il programmatore di mestiere...

 microsoft.
Mo n'esaggeriamo.

Cioč secondo me , dato che non riescono a fare un OS sicuro affidabile
Ma che minchiate. 


Certo.
Si fanno anche tanti memory leak, buffer overflow, e compagnia bella :)

 mettiamo una VM e sinceramente N+M+VM mi sembra un po troppo , no?
Non crederai mica che ci si programmino cose in VM (.net o java) che 
necessitino di alte prestazioni? Hanno un altro scopo.
-- 
Sensei <senseiwa@Apple's mail>
Research (n.): a discovery already published by a chinese guy one month
               before you, copying a russian who did it in the 60s.

 necessitino di alte prestazioni? Hanno un altro scopo.
Non c'entrano nulla le alte prestazioni. I motivi per cui non si usa una
VM e` che e` necessario eseguire un controllo manuale delle risorse. Non
c'e` assolutamente nulla che leghi la velocita` dell'applicativo con il
fatto che si usa una VM.
Codice JITato con un buon GC come dimostra bigloo possono
tranquillamente andare piu` veloci di gcc/icc e via dicendo, al prezzo
di consumare MOLTA piu` ram.
Esistono situazioni in cui sei obbligato, per ragioni fuori dal tuo
controllo, a far stare della roba in 4K (sugli amplificatori ad esempio)
e cascasse il mondo li` ci devi lavorare in asm o in C di bassissimo
livello, la VM non e` scartata perche` hai bisogno di velocita` ma
perche` non esiste nessuna VM che sta in 4K.



io su questa cosa ho un po' di dubbi... Sinceramente, ci sono un sacco
di tool per tutte le piattaforme per verificare la correttezza dei
programmi. Tanto per citarne uno di buono, valgrind.
Ci sono i tool per controllare gli errori di programmazione, basta
usarli. E francamente non credo che l'uso dei garbage collector e altre
soluzioni sia educativo: prima ci si dimentica i free, poi cosa altro ci
si dimenticherà? Insomma, per imparare a programmare bene ci vogliono
tempo ed esercizio.

 applicazioni."
.NET rocks ...
http://www.microsoft.com/presspass/press/2006/sep06/09-26MicroFrameworkDKPR.mspx
ovviamente non ve lo portano su linux, ma su tutto il resto si ...
ciaooo

:

Ti rendi conto che questa e' una sciocchezza vero ?
Non ci si dimenticano i free, il GC elimina il problema alla radice.
E se fosse cosi' tanto un problema di "tempo ed esercizio" i programmi e
programmatori che di tempo ed esercizio ne hanno avuto a pacchi non farebbero
cosi' tante cazzate.
Oh, poi puo' essere che _tutti_ gli implementor di server, sistemi operativi e
chi piu' ne ha piu' ne metta siano degli emeriti sfigati, non c'e' fine al
peggio.
  ngw

 tempo ed esercizio.
Eh gia'... ricordo i bei tempi su il mio vecchio amiga: quando
dimenticavo di liberare la memoria allocata, era persa fino al prossimo
reset. Forse e' anche per quello che di GC non ne voglio sentire parlare
e vivo felice con il C a suon di free...
Scola

 e vivo felice con il C a suon di free...
Direi che i GC non funzionano cosi da ere :-)
Che poi in un gioco (soft real-tiome) un GC sia scomodo posso anche
essere d'accordo.


 perche` non esiste nessuna VM che sta in 4K.
E questi?
http://developers.sun.com/techtopics/mobility/midp/articles/api/
http://developers.sun.com/techtopics/mobility/javacard/articles/javacard1/
Raffaele

 Ti rendi conto che questa e' una sciocchezza vero ?
secondo me è un approccio sbagliato. Il programmatore, sopratutto se
inesperto, non impara un bel po' i cose con questi strumenti.
Soprattuto per chi sta imparando....

 Soprattuto per chi sta imparando....
Per me, invece, si deve occupare di dettagli strepitosamente inutili a meno
che non finisca a programmare a basso livello, combattendo con dettagli
implementativi anziche' concentrarsi sul problema reale.
  ngw


Guarda che lo stesso approccio che avresti per la memoria lo hai per le
altre risorse critiche che usi nella tua applicazione e che hanno
bisogno di essere allocate e rilasciate, e per le quali non esiste un
garbage collector.
Quindi a livello teorico la gestione delle risorse con alloc/free la
continui a fare anche su runtime con garbage collection. Le
problematiche le vedi comunque. Ed impari a gestirle a prescindere dal
fatto che non ti devi preoccupare della memoria.
Il garbage collector elimina i problemi inerenti l'allocazione di
memoria. Il resto rimane. Ed e' uguale a fare malloc/free al
punto/posto giusto.


Dipende dal campo applicativo...
Cmq se hai l'indole di tafazzi, contento tu, contenti tutti! :)

 di consumare MOLTA piu` ram.
Pertanto verrebbero umiliati da programmi nativi che usano la stessa
quantita' di memoria...
La si puo' raccontare come si vuole, ma il risultato e' sempre
lo stesso i programmi compilati sono SEMPRE piu' veloci degli
equivalenti programmi scritti per una VM (posto che i programmi
compilati non siano fatti da esimi cazzoni e quelli interpretati
da draghi della programmazione).
C:\>iao Angelo
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 Lo sai vero che i programmi .NET sono compilati?
Si per un qualcosa che li interpreta e li converte in istruzioni native
per il processore sottostante.
Ovvero i programmi .NET sono interpretati. ;-)


 quantita' di memoria...
Questo e` semplicemente falso... :)
Ed e` sull'orlo dell'essere privo di senso. 


 da draghi della programmazione).
Un sistema JIT può beneficiare di una compilazione ad-hoc per il
sistema sul quale sta girando, cosa che un normale programma compilato
non può fare. Al massimo lo si può ricompilare per il sistema ospite,
ma è una cosa da fare più o meno a manina, e che comunque non
funziona a runtime a meno di impelagarsi nella scrittura di codice
automodificante...brrr...
Comunque:
VM != interpretato && Java != interpretato
&& Java != JIT && JIT == COMPILATO_A_RUNTIME
Raffaele


Dici?
Se il programma e' mantenuto TUTTO in memoria (e non ci resta solo
il working set) questo va alla massima velocita' possibile. Se il
programma
non e' fatto da cazzoni ed il compilatore ottimizza come si deve (ed a
me
risulta che il compilatore della Intel e' quello che ottimizza meglio
per le
prestazioni), mi risulta particolarmente strano che una VM riesca a
fare
di meglio. Al limite (ma molto al limite) riesce a fare quello che fa
il programma
nativo se
- si compila tutto il bytecode all'avvio del programma;
- si mantiene in memoria tutto il programma compilato.
Se per caso dovessi sbagliarmi,  mi piacerebbe sapere come dei page
fault
(mica tutto il programma .NET puo' essere compilato all'avvio) e delle
compilazioni
al volo, possono essere piu' veloci di un qualcosa che (come minimo)
non ha
compilazioni al volo da fare.
Ovviamente parlo dello STESSO programma compilato in forma nativa ed in
bytecode.
C:\>iao Angelo

 
E GC!=VM non lo dice nessuno?
Alessandro.

 
Il .NET-lebano ci mancava. Chi manca ancora alla collezione?-)
Alessandro.

 && Java != JIT && JIT == COMPILATO_A_RUNTIME
Volendo, anche uno script bash viene "compialto" a runtime:
una serie di stringhe ascii viene convertita in una serie di codici
macchina da una "macchina virtuale".
Cambiano i termini, la sostanza rimane.
C:\>iao Angelo

 macchina da una "macchina virtuale".
No, viene "interpretato". Non jittato.
Niente cache del codice macchina.
Niente ottimizzazione on-the-fly.
Raffaele


Semplicemente perchè:
1) non sempre si ha il codice sorgente a disposizione per ricompilare
2) non sempre si può ricompilare il codice su ogni macchina sulla
quale il programma deve essere eseguito
3) quando il programma viene distribuito in forma binaria, nel 99% dei
casi esiste un'unica versione compilata con ottimizzazioni generiche.
Un bytecode jittato, lo ripeto, viene compilato "just in time" usando
ottimizzazioni specifiche per la piattaforma.
Inoltre, un compilatore JIT NON compila l'intero programma all'avvio,
ma interviene dinamicamente per compilare sul momento solo le parti di
bytecode effettivamente eseguite.
Piccola nota aggiuntiva: usando un compilatore JIT è possibile
migliorare le performance di tutti i programmi scritti per quel
compilatore intervenendo in un unico posto, il JIT appunto.
Raffaele

 Dici?
Dico e quello che scrivi dopo mi suggerisce che non sai cosa sia un JIT.


 evidenti vantaggi in termini di prestazioni.
Il codice nativo NON HA BISOGNO DI QUESTO. Il motivo
l'ho detto sopra.  A mio misarabile modo di vedere, se
si ha bisogno di programmi che girino su N piattaforme,
rivolgersi ad un programma in bytecode puo' essere una
cosa sensata.
Se si sviluppa solo per una piattaforma usare il bytecode,
sperando che la VM faccia miracoli, non e' una furbata.
C:\>iao Angelo

 Dico e quello che scrivi dopo mi suggerisce che non sai cosa sia un JIT.
Amen. Quello che so io e' che i miracoli li fa l'Altissimo ed un
compilatore
"just in time" e' un (altro) pezzo di software messo in mezzo tra
quello che
i byte che hai sul disco e quelli che ti servono per lavorarci.
C:\>iao Angelo

 compilatore intervenendo in un unico posto, il JIT appunto.
Infatti la maggioranza dei programmi di "number crunching"
sono scritti in bytecode proprio per sfruttare questa caratterisitca.
Il JIT e' solo una tecnica per rendere meno obbrobriosa la velocita'
dei programmi in bytecode. E nessun programma sul mercato
campa tanto a lungo da beneficiare delle migliorie della versione
successiva della macchina virtuale.
C:\>iao Angelo

 Ovvero i programmi .NET sono interpretati. ;-)
Lo sai vero che in questa logica qualsiasi programma è interpretato :-)
?
Dai scherzi a parte, era per mettere un pò di sale in zucca al
flammatore.


 i byte che hai sul disco e quelli che ti servono per lavorarci.
E' un pezzo di software che si mette tra il bytecode ed il sistema
operativo, fa il suo sporco lavoro di jittatura, e poi si leva dalle
pa**e ed osserva ciò che succede, ritoccando se necessario.
Raffaele

 pa**e ed osserva ciň che succede, ritoccando se necessario.
Riassumendo:
Lato sviluppatore:
-Caso compilatore nativo: sorgente->compilazione->codice nativo:
-Caso VM: sorgente->compilatore->bytecodes.
Lato user:
-Caso nativo: lanciare prog->esecuzione prog.
-caso VM: lanciare prog->JIT->esecuzione prog. + ev altro JIT
Ora se guardiamo i tempi di esecuzione T si ha che:
-Caso nativo: T=T(esecuzione prog)
-Caso VM: T=T(JIT)+T(esecuzione prog) (+ev. T(altro JIT))
Ora con tutta la buona volonta' di questo mondo non posso credere che
nel caso di VM si possano avere dei programmi altrettanto performanti...
il che vorrebbe dire che T(JIT)->0, il che non e' vero (e sfido a
dimostrarlo... e non portatemi esempi stile while(i<10000) i++; )
senza flame
Scola

 perche` non esiste nessuna VM che sta in 4K.
D'accordissimo. Non parlo di prestazioni in termini di tempo e basta, 
sarebbe banale. Codici d'alte prestazioni (prendi ad esempio alcuni 
codici a Livermore) devono tener conto di tempo e spazio.
-- 
Sensei <senseiwa@Apple's mail>
Research (n.): a discovery already published by a chinese guy one month
               before you, copying a russian who did it in the 60s.

 quale il programma deve essere eseguito
No, ma sulla stessa architettura si. Per alte prestazioni fai sempre 
una compilazione nativa.


 senza flame
Non contano solo i tempi. Contano anche le ottimizzazioni. Il JIT può
ottimizzare meglio di un binario compilato con opzioni generiche. Per
avere ottimizzazioni specifiche devi:
1) creare nmila binari ottimizzati per ogni piattaforma possibile
2) rilasciare i sorgenti, che l'utente dovrà compilarsi a mano (salvo
casi particolari come gentoo et similia)
3) impelagarsi con la scrittura di codice automodificante
Con VM+JIT questo lavoro viene fatto AUTOMATICAMENTE. Lo sviluppatore
rilascia il bytecode (senza bisogno di rilasciare il sorgente, quindi
con qualsiasi licenza gli giri), ed il JIT metterà a disposizione
_automaticamente_ l'ottimizzazione specifica per la piattaforma sulla
quale viene eseguito.
Ovviamente si ha un rallentamento iniziale, quando il JIT deve
compilare in genere una maggior quantità di bytecode, ma poi le
prestazioni vanno aumentando. E direi che del bootstrap importa poco,
quando si calcola che solitamente i software target di tali linguaggi
sono del tipo "lancia ed usa per ore ed ore". Guarda i vari server, che
girano per giorni.
Comunque, il "+ eventuale altro JIT" serve a migliorare le prestazioni,
non a peggiorarle. Il JIT analizza in vari modi (statistica, pattern,
etc) il codice in esecuzione, e se necessario lo rielabora per
ottimizzarlo ulteriormente. Ed un buon JIT risolve facilmente tanti
problemi comuni di performance che si hanno a programmare in linguaggi
compilati non jittati.
In ogni caso, il JIT costituisce solo una piccola parte dei pregi che
hanno in genere le VM.
A questo ci possiamo aggiungere la portabilità del software, le
restrizioni di sicurezza, etc.
Ovvio, per compiti specifici un linguaggio compilato è più adatto
(motori grafici, calcolo numerico, et similia) ma per la stragrande
maggioranza dei compiti un linguaggio a bytecode non ha nulla da
invidiare ad uno compilato nativamente.
Notare poi che pressochè tutti i linguaggi a bytecode possono essere
compilati staticamente, se necessario.
Raffaele

 ciaooo
Mah, vedremo. Ci sara` un hype C# come fu per Java? Il prossimo (post 
Vista) MS-OS sara` scritto in C#?


 
Hai due fasi: analisi (eseguita in continuazione)+ eventuale 
riottimizzazione. Il tempo perso nell'analisi è sicuro, quello 
guadagnato ad ogni ottimizzazione è aleatorio (potrebbe non esserci 
niente da ottimizzare) e, nel tempo, destinato a tendere a 0.
Se l'analisi avviene costantemente, guadagni solo se il tempo guadagnato 
ottimizzando è maggiore di quello perso nell'analisi: il gioco vale 
veramente la candela?
Alessandro.

 compilati staticamente, se necessario.
Chiaro, anzi se non fosse vero ci sarebbe un bel paradosso...

 codici a Livermore) devono tener conto di tempo e spazio.
No fai peggio. Parli di prestazioni comprendendo qualsiasi genere di
prestazione anche quelle che ragionevolmente dipendono dal contesto e le
fissi come se facessero una differenza... Ho visto gente essere bocciata
ad esami per molto meno all'esame di algoritmi.


 Vista) MS-OS sara` scritto in C#?
Non so dove vivi te Sensei ma l'hype C# c'è già stato. Ormai sono 5 anni
che esiste eh. L'OS scritto in C# già c'è, almeno nella sezione
Research: 
http://research.microsoft.com/os/singularity/


 - ottimizzazione (in vari modi) del bytecode
ehm, forse perché in un compilato non servono?

 ad esami per molto meno all'esame di algoritmi.
Io tolgo semplicemente punti se allochi 20 volte per una cosa per cui 
ne bastano 2. Dunque, fai te. Le prestazioni VM o JIT non possono 
raggiungere in tempo e spazio il compilato ottimizzato per una 
piattaforma, e sono pochi quelli lo sostengono.
Nel limite, ovvero nel mondo ideale, possono coincidere. E questo e` un 
limite superiore. Dimmi il contrario, poi divento anche io sarcastico.


 Research: 
http://research.microsoft.com/os/singularity/
Lawrence, io non intendo quella shell con la software isolation al 
posto di usare i ring. E se intendi bene quello che dicono, sono 
lontani da dire ``tutto _e`_ scritto in C#'', singularity e` ancora un 
mix. Ed e` lontanissimo dall'essere minimamente usabile per un OS nuovo 
dal momento che su Channel9 non hanno fatto vedere che una CLI, senza 
nulla aggiungere.
Non parlo di ricerca (MS ne fa, e molta anche teorica), ma quanto di 
quello che stanno facendo _ora_ che vista e` in pratica uscito (quasi), 
e che sara` possibile vedere sul serio.


 e che sara` possibile vedere sul serio.
Beh allora non c'č niente in ballo :-) Vista tra l'altro č la metą
rispetto ai progetti iniziali. Prima o poi lo finiranno sto coso.


 sentimenti ;-)
Beh, non so se qualcuno l'ha già fatto, ma il codice è disponibile,
quindi non è impossibile riuscirci.
Raffaele

:

Dai questo strano assunto per cui le nude prestazioni siano il fattore piu'
importante di un software, molto piu' di - per dire - il costo dello sviluppo
di questo software, la correttezza del software, la manutenibilita' e chi piu'
ne ha piu' ne metta.
Sicuramente se usi Python per le prestazioni sei un idiota, ma ci sono alcuni
altri fattori da mettere in conto: e' estremamente semplice usare librerie
native, puoi eliminare i colli di bottiglia con C, buona parte dei costrutti
base che ti dovresti implementare a manina sono gia' implementati,
ottimizzati, usati in produzione ovunque (stack, hash, chi piu' ne ha piu' ne
metta), e non implementati in n + 1 librerie esterne, sono _feature_ del
linguaggio.
A questo possiamo aggiungere che i tempi di sviluppo e debugging sono di
qualche ordine di magnitudine inferiori (se parliamo di Python e C il
confronto e' a tutti gli effetti imbarazzante, C#/Java e C e' gia' piu'
equilibrato, ma senza dubbio a favore del primo) e, a conti fatti, i  
programmi sono decisamente piu' corretti. Con piu' di un decennio di sviluppo
alle spalle e 3 dico 3 riscritture Apache ha ancora il coraggio di avere
prestazioni non cosi' buone e diversi bug, magari a scriverlo con un
linguaggio a piu' alto livello usando C quando necessario il software sarebbe
migliore, un web server non e' esattamente rocket science. 
I programmi bytecode possono essere prestanti eccome, e se non lo sono ti puoi
comprare dell'hardware migliore con i (tanti) soldi che hai risparmiato
facendo sviluppare il software in un linguaggio ad alto livello.
Per fortuna, la possibilita' che le prestazioni siano abbastanza buone e'
molto alta, per questo nella mia limitata esperienza l'unica cosa che resta e'
il risparmio.
  ngw

 sperando che la VM faccia miracoli, non e' una furbata.
La VM non fa miracoli. La VM fa solo il suo sporco lavoro, ovvero
evitare che lo sporco lavoro lo debba fare lo sviluppatore. Per
esempio, nel caso di Java, lo fa decisamente bene.
Raffaele

 uno compilato.
vorrei vedere un esempio pratico, per piacere

 a codice macchina.
hai un esempio di ottimizzazione che può essere fatta solo a runtime e
non a priori dal compilatore?

 non a priori dal compilatore?
Tutte quelle conseguenti all'introduzione di nuove istruzioni nei processori
avvenute posteriormente alla compilazione del programma?

 avvenute posteriormente alla compilazione del programma?
Stiamo un po' parlando del sesso degli angeli pero`... E` vero quello 
che dici, ma a questo punto dovresti ricompilare il programma e basta, 
visto che stai tentando di avere il massimo delle prestazioni. Per 
programmi normali non c'e` bisogno, e per quelli speciali e` allora 
equivalente a ricompilare (a discapito della portabilita`).


 uno compilato.
Solo se fai test statistici alla membro di segugio. Certo che se 
compari un programma compilato per 486 con uno JIT che ottimizza per 
Xeon, nelle prestazioni POTREBBE essere meglio jit. Ma questa e` una 
prova LEGGERMENTE biased. Senza contare che non stai tenendo in 
considerazione neanche il tempo di ricompilazione jit. Sarebbe una 
prova poco credibile insomma.


 non a priori dal compilatore?
Non ci stiamo capendo.
Non è questione di una capacità esclusiva del JIT di ottimizzare.
E' questione del fatto che il JIT può ottimizzare partendo dal
bytecode, SENZA bisogno di ripartire dai sorgenti, ma in maniera del
tutto trasparente. I sorgenti li puoi anche dare in pasto ai pescicani,
una volta che hai il bytecode. (esasperazione, ma rende l'idea)
Se poi un giorno si scopre che un certo opcode bytecode può essere
ottimizzato in maniera più efficiente, basterà aggiornare il JIT, ed
automaticamente TUTTI i programmi che usano quell'opcode beneficieranno
della miglioria, SENZA ricompilare i sorgenti, senza niente se non
l'aggiornamento della VM.
Programmi scritti anni fa, dei quali magari si son persi i sorgenti,
potranno girare meglio senza bisogno di alcuna modifica.
Raffaele

 avvenute posteriormente alla compilazione del programma?
E questo puo' avere un senso per programmi con cicli di vita di 10
anni:
tu quanti ne conosci che hanno tempi di esistenza maggiori di un paio
di anni?
In un paio di anni, a meno di cambi di processore, stravolgimenti
epocali
per la tecnologia corrente non ne esistono. Tra una revision e l'altra
dello
stesso processore e' gia tanto se eliminano i bug.
C:\>iao Angelo

 comprare dell'hardware migliore con i (tanti) soldi che hai risparmiato
Su tutto il resto sono d'accordo, ma questa mi sembra una cazzata: se
il programma e' lento sul l'HW attualmente a disposizione, quale altro
HW
puoi comprare?
C:\>iao Angelo

 di anni?
Personalmente, ho lavorato su alcuni grossi progetti in Java, e tutti
hanno cicli di vita pluriennali. Alcuni progetti sono legati
all'agricoltura/amministrazione pubblica. Sono già in piedi da 3-4
anni, e continueranno ad andare avanti per un bel pò. Stesso dicasi
per l'interfaccia web che abbiamo sviluppato per i sistemi legacy di un
paio di istituti finanziari.
Raffaele

 forse valore anni fa, non certo oggigiorno.
Se Visual Studio e' veramente in bytecode, come ho sentito dire,
la lentezza e' tutt'altro che una leggenda urbana. Garantito, per
esperienza personale.
C:\>iao Angelo

 paio di istituti finanziari.
Io lavoro su un progretto che va avanti da 10 anni: l'ottimizzazione
che
aveva all'inizio era per il 486. Credi che si sia mantenuta la stessa
ottimizzazione dopo dieci anni e tre compilatori diversi?
C:\>iao Angelo

 puoi comprare?
Scusami ma non state litigando sulla RAM da giorni ?
Inizia ad aggiungere RAM, poi vediamo :)
Per quello che mi riguarda a livello _commerciale_ vale la pena di dare per
assunto C/C++ solo e unicamente quando appunto ci sono delle limitazioni
hardware, ad esempio limitazioni di memoria.
Negli altri casi e' partire con il piede sbagliato, visto che mente con Java
puoi sempre sostiruire parti in Java con codice nativo per eliminare eventuali
problemi, la vedo dura fare il contrario, se non riscrivendo.
Poi ognuno e' libero di farsi male come meglio crede eh (il che - per me -
vale sia nell'usare C che nell'usare Java in generale ;)
  ngw 

 ottimizzazione dopo dieci anni e tre compilatori diversi?
Noi abbiamo apportato ben poche ottimizzazioni, se non a livello di
query SQL.
Quando aggiorneranno il parco macchine, sarà sufficiente installare la
JVM per quell'hardware, e rideployare i package. Punto.
L'ottimizzazione sarà a livello di VM, ed a noi non toccherà se non
in caso di incompatibilità di diverso genere.
Raffaele

 JVM per quell'hardware, e rideployare i package. Punto.
Quando cambiara' il parco processori, bastera' cambiare uno switch,
tra una ricompilazione e l'altra, per avere la nostra bella
ottimizzazione.
Niente di troppo complicato...
Io sono legato ad una specifica piattaforma, per me usare un del codice
in bytecode sarebbe solo una palla al piede, non avrei nessun
vantaggio.
C:\>iao Angelo

 hardware, ad esempio limitazioni di memoria.
Punti di vista. Io ritengo che se si e' legati ad una piattaforma, e
non
ci sono altre motivazioni (tipo i programmatori C/C++ costano troppo
;)),
il C/C++ e' una scelta valida.
C:\>iao Angelo

 vantaggio.
Così su due piedi, mi vien da dire che è proprio la tua "specifica
piattaforma" ad essere una palla al piede...
Raffaele

 piattaforma" ad essere una palla al piede...
Da me hanno scelto di usare UNICAMENTE Intel & Microsoft. Non
sono io che decido su queste cose: dato il vincolo, svluppo in modo
da avere il massimo delle prestazioni.
C:\>iao Angelo

 il C/C++ e' una scelta valida.
Si, punti di vista, ma io ho il culo che il mio coincide con il mercato degli
ultimi anni, il tuo di quando andavano di moda gli Spandau Ballet :D
  ngw

 e della compessita'di "Hello world".
PaolÃi', te non e' che Java non l'hai mai visto in foto, te non conosci
nemmeno nessuno che ce l'abbia visto.
Ma solo il fatto di non avere puntatori tra i maroni lo rende il doppio piu'
produttivo e complesso almeno la meta'.
E non nomino nemmeno la libreria standard, o gli innumerevoli aspetti che Java
ha semplificato rispetto a C++.
Costi... che vuoi trovare ? Non e' da due mesi che le aziende cassano C/C++
per linguaggi a piu' alto livello, sono *anni*. Se non ti serve andare a basso
livello perche' mai usare un linguaggio orrendamente complicato come C++ ?
Vai in una banca a vedere cosa tirano su in Java (e basta con questa cagata
che se dei dati danno palesemente torto allora si sta scrivendo "Hello World")
e vedi tu quanta gente servirebbe per farla in C++.
  ngw

 e vedi tu quanta gente servirebbe per farla in C++.
In Java si vedono un sacco di server, aggeggi dove conta in maniera
preponderante l'interoperabilita' tra sistemi eterogenei (eliminare
l'endianess
e le divese dimensioni dei tipi base sono feature simpatiche) e dove i
ritardi
introdotti dal software spesso e volentieri sono nascosti dalla
lentezza della
rete.
Ma vista tutta questa semplicita'&produttivita'&velocita' di Java,
perche',
ad es., OpenOffice non e' stato riscritto completamente in Java? E'
sponsorizzato dalla Sun (che mi sembra sia il maggior sponsor di Java),
e' stato riscritto praticamente da zero, ed avrebbe beneficiato di
tutte le
migliorie apportato alla VM... Cazzo! Nonostante tutto lo hanno scritto
(per la maggior parte) in C++.
C:\>iao Angelo

 per linguaggi a piu' alto livello, sono *anni*.
Quello che tu ed il tuo compare Vongola non avete ancora capito (o fate
finta di non averlo capito :) è come funziona il mercato oggi.
Se c'è una grande richiesta di programmatori Java e di altri linguaggi
di alto livello (come Python e Ruby, anche se in realtà non mi paiono 
ancora diffusi) è solo perché questi programmatori vengono sottopagati e
"schiavizzati". Alle aziende non interessa produrre sw di qualità, ma 
trovare un po' di "ragazzini" che buttino giù codice in fretta anche
se il risultato è scadente.
Ciao.
-- 
BSD is for UNIX lovers -- linux is for Windows haters.

 compilati non jittati.
Forse ti sfugge che tutte queste ottimizzazioni sono estremamente
pesanti computazionalmente.


 vale sia nell'usare C che nell'usare Java in generale ;)
Mah... faccio un esempio pratico che mi sta anche abbastanza a cuore. Al
lavoro mi capita di usare piu' che spesso MatLab. Chiaramente le parti
di codice che fanno il calcolo numerico sono state compilate in nativo
(ora non so se a partire dal Fortran o dal C... le vecchie versioni di
MatLab erano scritte in Fortran, non so se hanno gia' portato tutto in
C). L'interfaccia grafica invece e' implementata in Java. L'idea sembra
eccellente: routine veloci per calcolo numerico, interfaccia in Java per
facilitare la portabilita' e concentrarsi sul'aspetto tecnico del
programma. Ora nasce un piccolo problema: l'interfaccia Java sulla mia
gentoo e' mega buggatissima... praticamente non riesco neanche a fare
un'elevazione a potenza perche' non mi riconosce il ^ (ora va gia'
meglio, qualche versione fa addirittura il ^ faceva piantare la jvm)...
poi ci sono un sacco di altri problemi. Di sicuro dev'essere possibile
configurare per farlo funzionare (non ci credo che facciano uscire un
prodotto cosi'), il problema sta nel fatto che includono una loro jvm e
che non c'e' doc da nessuna parte...

 se il risultato è scadente.
Mi sa che sei tu quello schiavizzato. Io me la passo piuttosto bene con
python anzi... Ti invito a Pycon se vuoi venire. Milano 6-7 febbraio, la
sto organizzando io con Lawrence, sai... facciamo la fame, poi mi tocca
rifiutare 4 o 5 contratti al mese perche` non ho tempo di seguirli tutti
ma faccio la fame, beato te...
-- 
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.4
Blog: 
http://vvolonghi.blogspot.com
New Pet: 
http://www.stiq.it

 se il risultato è scadente.
Ragazzini? Ma te in che razza di aziende vai a lavorare?
Ma soprattutto, quando "null" conosci di Java, per dire simili
fesserie?
Vatti a vedere che architetture si tirano su, con Java, poi ne
riparliamo.
Raffaele

 se il risultato è scadente.
Questo l'hai letto su Gente o su Oggi ?
Per quale strambo motivo un linguaggio dovrebbe definire la qualita' di un
progetto ? Schiavizzati e sottopagati ? Non saprei, io C++ non lo tocco
nemmeno con un quadruplo goldone carpiato, e mi aggiro sui 200/250 euro al
giorno.
Davvero delle banche mettono in mano a dei "ragazzini sottopagati" i loro
progetti e se ne sbattono del software di qualita', soprattutto quando il
costo medio di un consulente e' attorno i 600/700 euro al giorno ? Che
qualita' di acido lisergico hai assunto ?
Io ti consiglierei di tenere questo astio verso me e il mio compare Vongola
per quando hai motivazioni un po' piu' forti da Java = risultato scadente e
ragazzini sottopagati, almeno passi per il via prima di farmi ridere.
  ngw

 che non c'e' doc da nessuna parte...
Chiaramente non puoi dare la colpa allo strumento se il progetto e' stato
sviluppato con il culo.
Questo lo possiamo dare per assunto credo.
  ngw

 Questo lo possiamo dare per assunto credo.
Non credo che alla mathworks lavorino cosi' col culo... quello che
volevo far notare e' che l'idea di base dietro alle VM e' buona, ma
visto che poi anche le VM sono programmate, si finisce sempre per
cozzare contro problemi di ogni sorta. Quello che alla fin fine mi
domando: il gioco (le VM) vale veramente la candela? Me lo domando anche
pensando che java ad esempio non esiste per tutte le piattaforme (se non
sbaglio per freeBSD non esiste (per lo meno non esisteva)), .NET c'e'
solo per win (mono lascia a desiderare),... L'idea e' buona, ma tra il
dire e il fare...

 te...
Da quello che dici direi che non sei un dipendente, ed anche un bambino
delle elementari avrebbe capito che stavo parlando di lavoro
subordinato...


 riparliamo.
Anche con SAP, ma non per questo è un prodotto meno schifoso...


 dire e il fare...
Tra il dire e il fare ci sono Python e Ruby che funzionano su una decina
di piattaforme e non hanno GUI "mastodontiche" come quelle di Java :-P
-- 
Lawrence - 
http://www.oluyede.org/blog
http://www.neropercaso.it
"Nothing is more dangerous than an idea
if it's the only one you have" - E. A. Chartier

 software multipiattaforma, il C++ e' piu' complicato di Java.
Non entro nel merito della vostra discussione ma non mi pare che C++ sia
facile quanto o più di Java anzi. Java è nato apposta per togliere
complessità a C++.
Detto questo torno in read mode :-)


 se il risultato è scadente.
E questo sicuramente è un problema imputabile al creatore del
linguaggio...
-- 
Lawrence - 
http://www.oluyede.org/blog
http://www.neropercaso.it
"Nothing is more dangerous than an idea
if it's the only one you have" - E. A. Chartier

 ragazzini sottopagati, almeno passi per il via prima di farmi ridere.
Io ce l'ho con voi per le cazzate che dite...
Poi, ovviamente, voi ritenete cazzate quelle che dico io, ma questo non
può che farmi piacere.
Ciao.
-- 
BSD is for UNIX lovers -- linux is for Windows haters.

 Se un linguaggio rende più difficile scrivere codice di qualità...
Sarebbe interessante partire da questa definizione per capire cosa si
intende per qualità del codice.


 linguaggio...
La questione, come spero di avere spiegato sopra, è ribaltata:
la necessità è produrre in fretta anche a scapito della qualità, il
risultato è che si diffondono linguaggi in grado di essere usati anche
con poca esperienza. 
D'altra parte, però, alcuni di questi linguaggi rendono più difficilie
la scrittura di codice di qualità.


 la scrittura di codice di qualità.
Se non capisci da solo quanto questo sia inesatto non e` colpa
mia/nostra.
Ne conosco ben pochi di software scritti in python di qualita` bassa e
quando li ho criticati mi sono sempre assunto le mie responsabilita`
(minacce di cause per diffamazione) e infatti posto col mio nome e
cognome.
Python puo` essere usato da chi ha poca esperienza, vero. E` anche vero
che molti dei grossi capoccia del C++ lo usano e contribuiscono al suo
sviluppo (e non solo loro, anche chi ha creato il web lo usa per i fatti
suoi). Sono tutti stupidi? Dave Abrahams e Andrew Koenig usano e
contribuiscono a Python, lungi da me pensare che siano stupidi perche`
usano C++. Io sto studiando piu` approfonditamente in questi giorni C++
per ragioni di futuri lavori e ho deciso che C++ con boost::asio e in
generale boost possa essere un ottimo attrezzo nella mia cassetta, ma un
linguaggio complesso come lo e` quello introduce una serie di problemi
nella scrittura del codice che non hanno nulla a che fare con la
complessita` del progetto.
C++ rende complesse le cose facili e fattibili le cose molto difficili
(con le dovute precauzioni). Ma pensare che questo basti a evitare che:
1) Ci lavorino sopra PM incompetenti
2) Ci lavorino sopra neo-laureati incompetenti
3) Ci lavorino sopra incompetenti
e` una pensiero tanto bello quanto velleitario. Come dici tu sono le
persone che guidano i costi dei progetti e se per vincoli di costo sei
costretto ad assumere un pischello...
Scrivere codice di qualita` in un linguaggio complesso e` piu` difficile
non piu` facile. Sarebbe come dire che per allenarsi bene dovresti
procurarti un campo completamente impantanato dove si corre a fatica.
Esistono linguaggi limitanti come java e C# che obbligano a pensare poco
e a scrivere tanto, esistono poi linguaggi molto piu` flessibili che
permettono di pensare di piu` e scrivere meno. Esistono poi filosofie
differenti e implementazioni differenti. Lo dico sinceramente: Dalla
triade Java/C#/C++ sono uscite piu` disgrazie che miracoli (anche se ci
sono entrambi chiaramente) proprio perche` il linguaggio e` _SCOMODO_ e
quando programmi 8 ore al giorno hai anche bisogno di non doverti
ricordare 50 pagine di regole e 50 di eccezioni alle regole e 30 di
varianti alle regole.
-- 
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.4
Blog: 
http://vvolonghi.blogspot.com
New Pet: 
http://www.stiq.it

 la scrittura di codice di qualità.
Continuo a domandarmi la tua definizione di qualità


 Anche con SAP, ma non per questo è un prodotto meno schifoso...
Tu hai detto "alle aziende non interessa produrre software di
qualità".
Non so in che aziende lavori tu, ma io nella mia esperienza lavorativa
ho visto codice Java di altissima qualità, idem per le architetture
relative.
L'unica cosa di scarsa qualità su cui ho messo le mani è il PL/SQL,
ma più per l'aspetto che altro, per mancanza di standard di
formattazione.
Invece ho avuto modo di visionare codice COBOL di San Paolo, e lì la
qualità è altissima.
Raffaele

 e che sara` possibile vedere sul serio.
Mentre a voler fare i pistini un OS sviluppato in Java già esiste, ed
è JNode
http://www.jnode.org/
che tra l'altro presenta qualcosina in più che non una semplice CLI.
:)
Ciao
Raffaele

 :)
Conoscevo... ma e` un YAOS (yet another operating system). Nulla di 
usabile JNode (poi in java... brrrrrrrrr!!), mentre mi riferisco a 
qualche tipo di preview, vedi leopard o vista. Zeta rinato non pare in 
grado di far nulla per ora... mah, qualcosa prima o poi spuntera`.
-- 
Sensei <senseiwa@Apple's mail>
Research (n.): a discovery already published by a chinese guy one month
               before you, copying a russian who did it in the 60s.

 avvenute posteriormente alla compilazione del programma?
eh no, mi dispiace qui tu bari:
se la ricompilazione non puň avvenire per gli uni non puň avvenire
nemmeno per gli altri. Non puoi dire che per i non jittati dai il
binario senza ricompilare  e per gli altri ricompili jit. Perché se fai
questo allora parte la musichetta "ti piace vincere facile?" :-)

 potranno girare meglio senza bisogno di alcuna modifica.
se perdi i sorgenti allora come sviluppatore vali poco. :-)

 fai questo allora parte la musichetta "ti piace vincere facile?" :-)
Studiati il modello di compilazione di .NET 2.0
Saluti.

 Studiati il modello di compilazione di .NET 2.0
posta un link, per piacere.

 se perdi i sorgenti allora come sviluppatore vali poco. :-)
Non parlo di me, parlo in generale. Tra 20anni potrebbe esserci
necessità di far girare un programma Java scritto oggi.
Con un programma compilato posso scrivere un emulatore, senza la
garanzia che funzioni meglio del programma su macchina nativa.
Con un bytecode, mi basta scrivere una VM che rispetti le specifiche
usate per quel bytecode: molto più facile e decisamente più
performante.
Ora notte
Raffaele

 performante.
ti basta scrivere una vm? ah be, allora....
ragazzi i ocnfronti che fate  sono come quelli della pubblicità del
gratta e vinci.

 ti basta scrivere una vm? ah be, allora....
Secondo te è più semplice/performante emulare un'architettura, o
scrivere una JVM?
(ricordo che l'esempio che ho fatto parla di compilato per il quale non
sia più disponibile il sorgente)
Raffaele

 grado di far nulla per ora... mah, qualcosa prima o poi spuntera`.
Beh, si parlava di OS scritti in linguaggi di alto livello come C#.
JNode è scritto in un linguaggio di alto livello, e quantomeno è
funzionante.
Raffaele

 scrivere una JVM?
sai che non so cosa sia più difficile?

 secondo me non č fatto proprio bene.
Che pezzenti! Qt Library:
void QFile::setFileName ( const QString & name )
Sets the name of the file. The name can have no path, a relative path, 
or an absolute path.
Do not call this function if the file has already been opened.
If the file name has no path or a relative path, the path used will be 
the application's current directory path at the time of the open() call.
Example:
 QFile file;
 QDir::setCurrent("/tmp");
 file.setFileName("readme.txt");
 QDir::setCurrent("/home");
 file.open(QIODevice::ReadOnly);      // opens "/home/readme.txt" under Unix
Note that the directory separator "/" works for all operating systems 
supported by Qt.


 supported by Qt.
Windows supporta i forward slash dalla NT mi pare, o dalla 2000. Sono
sicuramente comodi per evitare l'escaping o il \\


 Che pezzenti! Qt Library:
CUT
Occhio, per la parte java lì si parla di "abstract pathname", e di
"pathname".
Quel formato "non fatto bene" è quello usato internamente. In pasto
gli si può dare invariabilmente i due formati.
Per fare un esempio, gli script ANT sono multipiattaforma, anche se
hanno separatori vari ed eventuali.
Raffaele

 gli si puň dare invariabilmente i due formati.
scusa, non capisco. puoi spiegare meglio?

 scusa, non capisco. puoi spiegare meglio?
Beh, non sono addentro agli internals di java, ma mi pare abbastanza
chiaro.
Qualche esempio...
sotto windows:
"c:\pippo.txt" ->  "c:\\" + "pippo.txt"
"..\..\pippo.txt" -> "c:" + ".." + ".." + "pippo.txt"
c:\\ se il path è assoluto
c: e basta se è relativo (indica solo il drive nel quale si trova il
file)
Sotto *nix:
"/etc/fstab" -> "/" + "etc" + "fstab"
"./fstab" -> "" + "." + "fstab"
Se il path è relativo, non c'è prefisso
Quando si converte il path astratto in un path stringa, il sistema
elabora questo path astratto ed applica i separatori specifici per la
piattaforma.
Ovviamente ci sarà qualche specifico problema nel convertire path
assoluti da windows a *nix, ma questo non c'è santo che tenga, non
può funzionare.
Ma per tutti i path relativi, java è in grado di gestire i path
indipendentemente dal sistema che ci sta sotto. Se io imposto ".\bin"
in un file di configurazione per java, il programma sarà in grado di
applicare correttamente "\" piuttosto che "/" o qualsiasi altro
separatore che la piattaforma sottostante usa, purchè la stessa sia
supportata.
Spero di essere stato comprensibile.
Raffaele

 può funzionare.
bene. era qua che volevo arrivare. Secondo me questo è migliorabile,
vedi per esempio le QT


Non ci siamo capiti.
Io mi riferisco al fatto che "c:\pippo.txt" non lo puoi convertire in
un path *NIX sensato, e non c'è santo che tenga: c: sotto UNIX non ha
un corrispondente. E nè le QT, le altri, possono ovviare al problema,
se non prendendosi libertà implementative che non hanno però un
fondamento tecnico. A questo mi riferisco.
Ah, ovviamente il problema c'è anche all'inverso. "/etc/fstab" a cosa
lo faccio corrispondere, su una macchina windows? In base a cosa
stabilisco il criterio per cambiare la root di quel path? Non posso. E
non possono le QT, e non può Java.
Per il resto, quello stralcio che hai citato dice ben poco, se non che
"/" è valido per tutte le piattaforme: con java puoi mettere
indifferentemente "/" o "\", anche mischiati, a comporre un path, e
Java si occuperà di astrarlo, e riconvertirlo nel formato richiesto
dal sistema operativo sottostante. Sarebbe un confronto sensato se ci
portassi qualcosa riguardo gli internals delle QT riguardo la gestione
dei path...
Raffaele

 un corrispondente.
Ma tu sei convinto che su NTFS  c:\pippo.txt sia solo c:\pippo.txt?

 Ma tu sei convinto che su NTFS  c:\pippo.txt sia solo c:\pippo.txt?
No, ho detto questo?
Ho semplicemente detto che i path assoluti non sono compatibili tra Win
e *NIX.
Raffaele


e allora la portabilità non funziona così bene come qualcuno sostiene....

 e allora la portabilità non funziona così bene come qualcuno sostiene....
i MIRACOLI non c'è nessun linguaggio in grado di farne.
E la portabilità funziona finchè chi scrive i programmi lo fa usando
il cervello. Non puoi pretendere di scrivere "/home/user/" ed
aspettarti che java vada da solo a cercarsi "c:\Documents etc etc".
Bisogna comunque usare gli strumenti messi a disposizione dal
linguaggio. Ci sarà una costante, o funzione, o quel che è (mai
usata, però) che mappa la cartella home di default per il sistema
operativo sottostante, per esempio. Ci sarà una costante con il
separatore specifico per lapiattaforma, etc etc.
Comunque il punto del discorso è che java permette la portabilità dei
path come, se non più, del QT che è stato portato come esempio.
Raffaele

 path come, se non più, del QT che è stato portato come esempio.
ma non è vero. ma stai negando la cosa! capisco essere fan di una
tecnologia e voler negare l'evidenza....


Allora, rileggiti la documentazione di File in java, ed il pezzo di
documentazione QT citato da Sensei, poi ne riparliamo. Perchè mi sà
che non hai ancora capito che:
1) quello che hai citato tu è relativo alla rappresentazione ASTRATTA
usata internamente da Java per rappresentare un path
2) il pezzo citato da sensei parla di ciò che QT fa lato
sviluppatore/utente.
Nessuno ha ritenuto opportuno sottolineare che per Java è indifferente
indicare un path usanto "/" piuttosto che "\", esattamente come
l'esempio citato per le QT.
In più, Java è in grado di convertire un Pathname astratto in un path
stringa usando il separatore standard previsto per la piattaforma, ma
non ci è dato sapere come funzionano internamente le QT, se qualcuno
non cita info specifiche.
Comunque, per riassumere, stai continuando a confrontare mele con pere,
e non senti ragioni. Io non so che dirti se non di riguardarti meglio
la documentazione Java, perchè mi sa che ti è sfuggito qualcosa.
Per aggiungere carne al fuoco:
Le QT come si comportano nel caso di pathname assoluti come
"c:\pippo.txt"? Usano poteri magici per capire dove andare a prendere
quel "pippo.txt" una volta in esecuzione su una macchina *NIX, oppure
anche loro si inchinano di fronte al fatto che "c:" per una macchina
*NIX non significa nulla? Oppure un "/etc/fstab" su win32, il discorso
non cambia.
Finchè si parla di pathname relativi, in base a quanto citato qui,
entrambi funzionano in modo analogo. La frase "Note that the directory
separator "/" works for all operating systems
supported by Qt." è valida tanto per le QT quanto per Java. Inoltre,
per Java anche il separatore "\" è valido per tutte le piattaforme
supportate, per QT?
Insomma, spiegami quale sarebbe questa "evidenza" che io starei
negando, ed in cosa la gestione mostrata dalle QT è superiore/migliore
a quella di Java. Andando però a paragonare mele con mele, e pere con
pere, e non a casaccio a piacimento.
Raffaele

 l'esempio citato per le QT.
Dimmi perché questo programma mi dà questo output
import java.io.*;
public class Test {
        public static void main (String argv[]) {
                FileInputStream file;
                try {
                        file = new FileInputStream ("tmp.txt");
                } catch (FileNotFoundException e) {
                        System.err.println("tmp.txt non trovato");
                } catch (Exception e) {
                }
                try {
                        file = new FileInputStream ("tmp/tmp.txt");
                } catch (FileNotFoundException e) {
                        System.err.println("tmp/tmp.txt non trovato");
                } catch (Exception e) {
                }
                try {
                        file = new FileInputStream ("tmp\\tmp.txt");
                } catch (FileNotFoundException e) {
                        System.err.println("tmp\\tmp.txt non trovato");
                } catch (Exception e) {
                }
                return;
        }
}
bott@banach:/tmp$ ls tmp.txt tmp/tmp.txt
tmp/tmp.txt  tmp.txt
bott@banach:/tmp$ java Test
tmp\tmp.txt non trovato
bott@banach:/tmp$

 Dimmi perché questo programma mi dà questo output
Perchè non hai letto la documentazione, ed hai scritto un pezzo di
codice scarsamente portabile.
FileInputStream è così:
FileInputStream(File file)
FileInputStream(FileDescriptor fdObj)
FileInputStream(String name)
Tu hai usato l'ultimo, che prende il "name" paro paro, e lo usa come
path del file. Ma in alcuni casi è esattamente quello che si vuole
fare.
Per garantire la portabilità devi usare invece il primo, che usa la
classe File di cui abbiamo tanto discusso, e che infatti funziona.
Raffaele

 tmp\tmp.txt non trovato
Il fatto è che nomi dei file in dos/windows *non* possono contenere il 
carattere '/' mentre in unix *possono* contenere il carattere '\' (prova 
un "touch tmp\tmp.txt").
Questo ti permette di usare '/' come separatore di directory al posto di 
'\', ma non viceversa e in base alla nota riportata da Sensei mi sembra 
che valga anche per Qt.
Alessandro.

 Dimmi perché questo programma mi dà questo output
In riferimento all'altra risposta.
Prova questo programma su una macchina linux, che ora non ho
possibilità di farlo io stesso:
import java.io.*;
public class Test {
        public static void main (String argv[]) {
                FileInputStream file;
                File f;
                try {
                        f = new File ("tmp.txt");
                        file = new FileInputStream (f);
                } catch (FileNotFoundException e) {
                        System.err.println("tmp.txt non trovato");
                } catch (Exception e) {
                }
                try {
                        f = new File ("tmp/tmp.txt");
                        file = new FileInputStream (f);
                } catch (FileNotFoundException e) {
                        System.err.println("tmp/tmp.txt non trovato");
                } catch (Exception e) {
                }
                try {
                        f = new File ("tmp\\tmp.txt");
                        file = new FileInputStream (f);
                } catch (FileNotFoundException e) {
                        System.err.println("tmp\\tmp.txt non trovato");
                } catch (Exception e) {
                }
                return;
        }
}
sotto windows e java 1.5 funziona correttamente trovando tutti i files.
Raffaele

 sotto windows e java 1.5 funziona correttamente trovando tutti i files.
non posso provare, ma sotto linux no, pur con java 1.5 di sun.
Con QT come separatore usi sempre / e sei a posto. almeno stando alla
documentazione.

Ottavio Campana ha scritto:

...se non puoi provare, come puoi sapere che non funziona?
Con Java puoi usare sia \ che / e sei a posto, sempre stando alla
documentazione.
A questo ci posso aggiungere la mia esperienza personale con gli script
ANT, scritti su win2000, ed eseguiti poi anche su Linux Red Hat e SUN
Solaris senza modifiche ai path ivi indicati.
Raffaele

 Solaris senza modifiche ai path ivi indicati.
senti, non conosco ANT, ma il codice java che ho postato non funziona.
E' inutile girarci intorno.

 documentazione.
Ecco, secondo me questa è un po' una puttanata....
1) in linux con sun java 1.5 non funziona
2) anche se funzionasse dimostra un errore concettuale. Visto che vuoi
fare astrazione dovrsti usare un solo separatore. Poi per gestire i path
assoluti basta fare /c:/path/file, considerando  c: come il nome di una
directory. e un solo separatore. Perché mettendono due, ma uno dei due
non funziona ovunque dai solo la possibilità ai programmatori di fare
casino.

 E' inutile girarci intorno.
Il codice che _hai_ postato, come ti ho già fatto notare, _non_ è
portabile.
Hai provato a far girare quello che _io_ ho postato, e che fa uso della
classe File? Che è poi quella di cui abbiam parlato all'inizio,
ovverosia l'oggetto della discussione...non è molto saggio dire che
non funziona, se non la si usa, non ti pare?
Raffaele

 casino.
EH? /c:/path/file ? E mi spieghi che significato può avere questo per
un sistema *NIX? A meno ovviamente di non andare a creare alberature
più o meno a caso in giro per il filesystem...
Spiacente, ma continuo a ritenere che un path assoluto windows non
abbia alcun significato in *NIX, e viceversa.
Quanto al separatore doppio, può tornare utile. Per esempio, se devo
fare il parsing di un file di configurazione che può essere scritto in
formati diversi. O per banale comodità in fase di sviluppo: se lavoro
con windows, dove solitamente uso "\", è una seccatura doversi
ricordare ogni volta di sostituire tutti gli "\" con "/", o viceversa.
Raffaele

 ricordare ogni volta di sostituire tutti gli "\" con "/", o viceversa.
bella arrampicata sugli specchi. Vedo che ti piace difendere il doppio
codice. Ma tu non difendevi la portabilità un volta? :-)


nemmeno il tuo funziona, fatto copia e incolla dal tuo codice:
bott@banach:/tmp$ ls -al /etc/alternatives/java
lrwxrwxrwx 1 root root 40 2006-07-02 14:33 /etc/alternatives/java ->
/usr/lib/jvm/java-1.5.0-sun/jre/bin/java
bott@banach:/tmp$ ls  tmp/tmp.txt
tmp/tmp.txt
bott@banach:/tmp$ java Test
tmp\tmp.txt non trovato
bott@banach:/tmp$
quindi come vedi uso java 1.5.0 di sun e la classe File non funziona.
Però se a te funziona vuole dire che si deve fare come con QT: per fare
un codice portabile come separatore si usa solo / e non \ .

 codice. Ma tu non difendevi la portabilità un volta? :-)
Non difendo il doppio codice. Veramente, non sto proprio difendendo
nulla. Sto guardando le cose come stanno. Java mi semplifica la vita,
rendendo automaticamente portabile un path (nei limiti del possibile,
come già spiegato prima) senza che io mi debba preoccupare di quale
separatore uso. Non si tratta di doppio codice. Non devo scrivere una
variante con "/" ed una con "\": me ne frego e basta.
Allo stesso modo, non si tratta di "doppio codice" il dover parsare
file scritti da altri. Se io ho un file di configurazione scritto da
uno che usa sempre "/" come separatore, ed uno scritto da un altro che
usa sempre "\", cosa dovrei fare con le QT? Ripassare a mano il file
sbagliato, oppure scrivermi una mia funzione per adattare i path, o
usare una libreria terza che si occupi della portabilità del path.
Raffaele

 variante con "/" ed una con "\": me ne frego e basta.
ma non funziona! ho rovato il tuo codice e non va!

 un codice portabile come separatore si usa solo / e non \ .
Appena avrò la possibilità verificherò anche su linux. Ma vedendo
come si comporta su windows, e leggendo le specifiche, deve funzionare
allo stesso modo su linux.
Verificherò.
Raffaele

 ma non funziona! ho rovato il tuo codice e non va!
Indagherò. Ma che non funzioni mi puzza un pò, dato che qui su
windows si comporta esattamente come dovrebbe. (e vedi l'altro test che
ho postato sopra).
raffaele

 sull'installer e fare avanti avanti avanti.
Dopo aver aperto un browser, essere andato nel sito della sun, aver 
cercato la versione giusta.
emerge sun-jdk, fine.

 ho postato sopra).
ti dico, ho fatto copia ed incolla e non mi funziona.
E sì, prima di lanciarlo l'ho compilato :-)

 allo stesso modo su linux.
s/deve/dovrebbe/g :-)

 E sì, prima di lanciarlo l'ho compilato :-)
Appena posso, provo, come ho già detto. Ora sono senza *NIX a
disposizione.
Raffaele

 compatibilità.
ho capito che non ci siamo capiti. Io non voglio portare il path, voglio
fare in modo che una sola routine scritta bene funzioni sempre.
Sto cercando di farti capire che se ipotizzi una unica radice fittizzia
in windows cui attacchi le varie lettere poi puoi allora navigare i
filesystem esattamente come fai nel filesystem unix. La macchina
virtuale java potrebbe considerare in modo fittizzio c:\ come se fosse
una directory.
Capisci quello che sto cercando di dirti?
Quindi non dovresti più pensare di fare le routine di accesso al
filesystem che gestiscano i due casi /path/file e c:\path\file te ne
basta una sola. Insomma, per cercare di essere ancora più chiaro, in
questo modo eviteresti di avere che su alcuni sistemi la root è una e su
altri molteplici.

 dettagli implementativi come l'allocazione/deallocazione delle risorse,
Questa mi piacerebbe sapere dove l'hai vista. In Java l'unica cosa della
quale non ti devi preoccupare è dell'allocazione/deallocazione della
memoria, tutte le altre risorse te le devi gestire a mano (cosa che, per
inciso, in C++ la lascio fare al compilatore). 
Ciao.
-- 
BSD is for UNIX lovers -- linux is for Windows haters.

 triade Java/C#/C++ sono uscite piu` disgrazie che miracoli (anche se ci
È evidente che non hai neppure idea di cosa sia stato scritto in C++.


 Continuo a domandarmi la tua definizione di qualità
In questo caso intendo semplicemente codice robusto e sicuro rispetto
alle eccezioni.
Ciao.


 ho visto codice Java di altissima qualità, 
Beato te, io devo ancora vedere una singola riga di codice Java scritta
bene...


 grosso punto di debolezza), che porta ad usarlo in modo non corretto.
Si, probabilmente un C++ non sovrainsieme del C sarebbe stato davvero un
linguaggio "fantastico"
-- 
Lawrence - 
http://www.oluyede.org/blog
http://www.neropercaso.it
"Nothing is more dangerous than an idea
if it's the only one you have" - E. A. Chartier

 alle eccezioni.
"il codice non testato è codice che non esiste". Mi pare l'abbia detto
uno degli sviluppatori di Twisted Matrix (fatto in Python).


 di fare hype per ogni cosa.
E dov'è? Non è la pubblicità che non vedo, è il sw...
Ciao


 uno degli sviluppatori di Twisted Matrix (fatto in Python).
Ah, beata innocenza...


 E dov'è? Non è la pubblicità che non vedo, è il sw...
Che uso io, e di cui difficilmente potrei fare a meno, ti posso citare 
Mailman e Spambayes.
Non so se e' da considerare "roba web", ma anche Trac mi e' indispensabile.
  ngw
-- 
Now Playing: How Hard - Silently Noisy - Olen'

 Ah, beata innocenza...
A parte che non hai capito la metafora, non definirei gli sviluppatori
di Twisted dei bambinelli innocenti.


 E dov'è? Non è la pubblicità che non vedo, è il sw...
Spambayes? Buona parte dell'infrastruttura di Redhat, Gentoo e Ubuntu?
Un bel po` di programmi in GNOME? 
http://pythonology.org/success
 ?
http://www.python.org/about/success/
 ?
Io ho anche visto fior fior di software per il controllo industriale e
CAD in Python.
Certo, se vuoi comparare con i numeri di C++ o Java allora ti devo dare
ragione.


 Non so se e' da considerare "roba web", ma anche Trac mi e' indispensabile.
agiungo per il web zope (e volendo pure plone), twisted, django e
turbogears.

 sw.
Il videogioco "Bridge Commander" è interamente scriptato in python.
Altri qui:
http://en.wikipedia.org/wiki/Python_software
e nei link ivi riportati.
Attenzione! Potresti scoprire che usi python più spesso di quanto
pensi! :D
Raffaele

 turbogears.
HPL aveva chiesto "non web" :-) Tra l'altro tu hai elencato framework
per fare applicazioni :P


 per fare applicazioni :P
oops, mi ero perso questo dettaglio.... :-)

 pensi! :D
Dell'uso di Python sono pefettamente consapevole.
Ma non si tratta di sw scritto in Python...


 per fare applicazioni :P
Rispondo qui a tre messaggi (quello di Nicholas, quello di Ottavio ed il
tuo):
non è una questione di "razzismo", è semplicemente che si tratta di
applicazoni/librerie delle quali ho sentito più volte parlare, quindi so
che ci sono, mentre non conosco (non ne ho mai sentito parlare) sw 
"non web" scritto in Python. In realtà c'è Chandler, ma non mi pare che
sia un esempio che vada "a favore" di Python.
Ciao.


 CAD in Python.
CAD in Python mi sono sfuggiti... Potresti citarmene uno? Non per
sfiducia, è solo che un CAD serio è un'applicazione di una complessità
tale che sono sicuro (non convinto, sicuro) che non sia possibile in
Python.
Ciao.


 non definirei gli sviluppatori di Twisted dei bambinelli innocenti.
Non mi stavo riferendo agli sviluppatori di Twisted...


 sia un esempio che vada "a favore" di Python.
No decisamente no. Ad esempio non si cita mai portage di Gentoo come
esempio di buon software scritto in Python :D


 Python.
Beh io non so quando lo rilasceranno. L'ho visto coi miei occhi, ma non
posso dirti di più perché è un programma, da quanto ho capito, closed
source e a pagamento. Appena saprò qualcosa lo saprai anche tu. Per ora
devi fidarti.


 esempio di buon software scritto in Python :D
Io in effetti non sapevo fosse scritto in Python.


 devi fidarti.
OK.


 Io in effetti non sapevo fosse scritto in Python.
apt-proxy č in python per dire quello che mi č venuto in mente

 "non web" scritto in Python
Il client news che sto usando per risponderti e` scritto in Python (da
un italiano, tra l'altro)
Enrico