Java vs C++... Sono stanco... [Archivio] - Pagina 2

cdimauro

27-08-2007, 08:39

no intendevo dire che il fatto che i bench danno un risultato non significa che un software complesso quanto un SO dia lo stesso risultato
Questo mi sembra ovvio, anche se si possono fare dei benchmark che testino funzionalità tipiche di un s.o..
mah a me risulta che:
Anche se fosse così (mi piacerebbe verificare), da "percepibile" a "buona fetta" del tempo di esecuzione mi sembra che ci sia una bella differenza. ;)
quello che non è incluso è l'uso della memoria e della CPU
Si possono avere anche quelli, ma quando si fanno dei benchmark si assume che la CPU sia quasi esclusivamente a sua disposizione; eventualmente si può togliere di mezzo il tempo di CPU usato dal s.o..
però sarai daccordo con me che non si può avere la botte piena e la moglie ubriaca.. la portabilità porta inevitabilmente a un decadimento delle prestazioni. sta al programmatore valutare se questo è accettabile e in molti casi lo è effettivamente
Per me il 5-10% di decadimento è un prezzo irrisorio da pagare a fronte dei benifici che se ne traggono. ;)
a me l'hypervisor mi sta sullo stomaco :fagiano: e ti spiego anche perchè: mancanza di trasparenza da parte del SO, mancanza di controllo sul SO da parte dell'utente e altissima pericolosità di tale tecnologia.
non so se hai mai dato un'occhiata al blog Joanna Rutkowska negli ultimi anni... gli scenari che la virtualizzazione offre al malware sono a dir poco da preoccupanti
No, non la conosco. Comunque le problematiche di sicurezza dell'hypervisor sono similari a quelle del kernel di un s.o..
guarda che qui c'è un equivoco :D io non sto dicendo che gli ambienti managed sono inutili, ma siete voi che dite che quelli non managed sono inutili. per quanto mi riguarda ci sono dei pro e dei contro per ognuno e a senconda di quello che bisogna fare conviene l'uno o l'altro.
Chiaro, ma non era un giudizio lapidario. Il concetto è che con le "applicazioni di tutti i giorni" linguaggi e ambienti managed permettono una maggior produttività e robustezza (dell'applicazione ed eventualmente del sistema stesso; vedi in quest'ultimo caso l'esecuzione di codice in macchine NON dotate di protezione della memoria e affini, dove basta "un soffio" per far cadere tutto), per cui IMHO sono la soluzione da preferire.
ps. spesso si pensa che gli ambienti managed siano superiori soltanto per le caratteristiche dei linguaggi, ma questo non c'entra assolutamente niente. l'unica differenza è che il codice managed gira in una VM mentre quello non managed è nativo.
Come ho già detto prima, questo non è sempre vero. .NET è stato pensato per NON essere interpretato, e infatti il codice viene SEMPRE compilato (una sola volta, alla prima esecuzione, oppure "al volo").
In soldoni, non è stata pensata una VM che implementa un'architettura (quindi un processore con una precisa ISA), ma l'IL viene usato come descrizione di quello che il codice deve fare e come dev'essere compilato.
si in genere è vero, ma a volte per fare cose di bassissimo livello è ancora più efficiente usare l'assembly direttamente (penso ad algoritmi in cui il know-how è alle stelle). se è un pezzo di codice critico può essere anche decisivo per le prestazioni
Te l'ho già detto: con le moderne architetture out-of-order è tempo perso. Molto meglio lasciare al compilatore l'onere di sbrogliare la matassa tenendo in considerazione i numerosi vincoli a cui sono soggette le istruzioni e l'architettura in generale.

Fermo restando che, come dicevo anche prima, l'uso di un compilatore JIT permette di profilare l'esecuzione del codice ed eventualmente modificarlo per meglio adattarsi alla situazione reale: cosa impossibile da fare se il codice è già stato compilato una tantum, anche a manina con l'assembly.
eh cosa vuoi.. è stato rilasciato a gennaio di quest'anno :cool:
comunque interessante questa statistica che lo vede in forte crescita http://www.tiobe.com/tpci.htm
poi si vede anche che python e ruby dopo lo scoppio iniziale stanno pian piano tornando nei ranghi.. penso che alla fine si ritaglieranno la loro fetta di mercato e lì ci rimarranno.
Mah. Sulla metodologia utilizzata ci sarebbe parecchio da discutere.

cdimauro

27-08-2007, 08:40

ma non ci penso nemmeno! :Prrr: erano i tempi in cui skrivevo con le k e avevo i brufoli :sofico:
comunque mi fa piacere ricordare che oltre ad una marea di @zzate ho detto anche qualcosa che puntualmente si è avverato :O
Ehm... Cosa? :D
ps. inoltre mi piacerebbe anche che fek sapesse che l'XP è stato argomento d'esame nella mia università (perchè lui sosteneva che le università sono sempre indietro e spiegano concetti obsoleti)
Lo sostenevo pure io. :D

E' un ottimo segnale: significa che il bestione, seppur lentamente, è incline ai cambiamenti. :p
l'ultima volta l'ho usato un paio di mesi fa.. è cambiato molto?
Una reattività mai vista prima. E ho detto tutto.

cdimauro

27-08-2007, 08:45

Confermo che l'ultima versione di Eclipse è molto più stabile..mi ricordo che non mi teneva più di un paio d'ore e poi crashava...:D
E pur vero che molto spesso la colpa è dei plugin utilizzati..alcuni sono dei veri macigni (tipo l'Hibernate Console).
Anche quando sembra impallarsi un pò, non crasha, ma si riprende dopo qualche secondo!!

Vado abbastanza OT, ma ne approfitto per chiedervi se voi cambiate a manina i file di configurazione di eclipse per la gestione della RAM usata (minima e massima)

L'unica cosa scomoda che ho notato sulla versione 3.3 è che hanno tolto la possibilità di commentare più righe di codice nei file xml con la classica combinazione CTRL+SHIFT+/
Onestamente Eclipse mi sarà crashato pochissime volte quando m'è capitato di usarlo (ed è sicuramente un miracolo, considerata la mole di sfiga che mi porto dietro :asd:), ma quel che ho notato dell'ultima versione è l'incredibile reattività dell'IDE.

P.S. Mai forzata l'impostazione per l'uso della RAM: ho sempre lasciato quella di default.

cdimauro

27-08-2007, 08:54

Per quanto riguarda l'evoluzione di Java, io non me ne lamento affatto: le modifiche sono le benvenute. :D

Alla fine è sempre una questione di gusti. Ad esempio in Delphi le classi interne sono state introdotte giusto un paio d'anni fa e appena sono arrivate mi sono detto: "belle, belle, belle". Le avessi usate UNA sola volta da allora!!! :asd:
Al contrario, se avessero introdotto le funzioni anonime avrei fatto una processione alla Borland per ringraziarli. :p

Come diceva il mio carissimo professore (persona eccezionale, sia professionalmente che umanamente) di Linguaggi di programmazione quando spiegava il suo bellissimo LISP: "è tutto zucchero sintattico" (ciò che offrono gli altri linguaggi; sogghignando). Però in LISP c'erano le funzioni anonime (lambda) di si sarebbe potuto fare tranquillamente a meno, eh! :D
D'altra parte parlando di Giovanni e Paperi il suo nome è una garanzia: Giovanni Gallo. :p

Comunque io propongo di passare in massa a Brainfuck: difficile trovare un linguaggio più semplice. :asd:

AngeL)

27-08-2007, 09:49

Comunque io propongo di passare in massa a Brainfuck: difficile trovare un linguaggio più semplice. :asd:

>>>>>>>>>++++++++[>++++++++++<-]
<++++++[>++++++++++<-]
<+++[>++++++++++<-]
<++++++++++[>++++++++++<-]
<++++++++++++[>++++++++++<-]
<++++++++++[>++++++++++<-]
<+++++++[>++++++++++<-]
<+++[>++++++++++<-]
<+++++++++[>++++++++++<-]
>---.>++.>++++.>---.>--.>---.>++.>--.>-.

:O

^TiGeRShArK^

27-08-2007, 10:00

Onestamente Eclipse mi sarà crashato pochissime volte quando m'è capitato di usarlo (ed è sicuramente un miracolo, considerata la mole di sfiga che mi porto dietro :asd:), ma quel che ho notato dell'ultima versione è l'incredibile reattività dell'IDE.

P.S. Mai forzata l'impostazione per l'uso della RAM: ho sempre lasciato quella di default.

Per progetti MOLTO grossi devi per forza usarla..
tieni conto che a fine giornata eclipse mi arriva spessissimo sopra o 600 MB :asd:
Anche se c'è da dire che in partenza mi occupa solo 150MB di memoria fisica.

cdimauro

27-08-2007, 11:00

>>>>>>>>>++++++++[>++++++++++<-]
<++++++[>++++++++++<-]
<+++[>++++++++++<-]
<++++++++++[>++++++++++<-]
<++++++++++++[>++++++++++<-]
<++++++++++[>++++++++++<-]
<+++++++[>++++++++++<-]
<+++[>++++++++++<-]
<+++++++++[>++++++++++<-]
>---.>++.>++++.>---.>--.>---.>++.>--.>-.

:O
E non è semplice come linguaggio? Mi puoi dire che i sorgenti in Brainfuck non sia comprensibili, ma non che il linguaggio non sia la sintesi della semplicità. :read:

cdimauro

27-08-2007, 11:01

Per progetti MOLTO grossi devi per forza usarla..
tieni conto che a fine giornata eclipse mi arriva spessissimo sopra o 600 MB :asd:
Anche se c'è da dire che in partenza mi occupa solo 150MB di memoria fisica.
Buono a sapersi. Eventualmente (spero mai ovviamente :asd:) ne terrò conto. :)

AngeL)

27-08-2007, 11:11

E non è semplice come linguaggio? Mi puoi dire che i sorgenti in Brainfuck non sia comprensibili, ma non che il linguaggio non sia la sintesi della semplicità. :read:

confronta:

>>>>>>>>>++++++++[>++++++++++<-]
<++++++[>++++++++++<-]
<+++[>++++++++++<-]
<++++++++++[>++++++++++<-]
<++++++++++++[>++++++++++<-]
<++++++++++[>++++++++++<-]
<+++++++[>++++++++++<-]
<+++[>++++++++++<-]
<+++++++++[>++++++++++<-]
>---.>++.>++++.>---.>--.>---.>++.>--.>-.

vs

System.out.print("W Java");

:asd:

comunque è carino il bf :D

k0nt3

27-08-2007, 11:59

No, non la conosco. Comunque le problematiche di sicurezza dell'hypervisor sono similari a quelle del kernel di un s.o..
non esattamente.. è la differenza che c'è tra il malware di I tipo e il malware di III tipo http://invisiblethings.org/papers/towards_verifiable_systems.ppt
ovviamente mi auguro che nessuno riesca a scovare un bug nell'hypervisor, ma anche che nessuno (sony?) abbia interesse nel fornire il mio pc di un rootkit :fagiano:

Chiaro, ma non era un giudizio lapidario. Il concetto è che con le "applicazioni di tutti i giorni" linguaggi e ambienti managed permettono una maggior produttività e robustezza (dell'applicazione ed eventualmente del sistema stesso; vedi in quest'ultimo caso l'esecuzione di codice in macchine NON dotate di protezione della memoria e affini, dove basta "un soffio" per far cadere tutto), per cui IMHO sono la soluzione da preferire.
per le macchine non dotate di protezione della memoria.. penso che non sia roba da tutti i giorni! comunque sia non ho capito se per produttività e robustezza intendi una serie di caratteristiche del linguaggio (perchè in questo caso non è fatto di managed o no)

Come ho già detto prima, questo non è sempre vero. .NET è stato pensato per NON essere interpretato, e infatti il codice viene SEMPRE compilato (una sola volta, alla prima esecuzione, oppure "al volo").
In soldoni, non è stata pensata una VM che implementa un'architettura (quindi un processore con una precisa ISA), ma l'IL viene usato come descrizione di quello che il codice deve fare e come dev'essere compilato.

scusate una domanda... ma senza CLR è possibile eseguire del codice .NET che è stato precompilato in codice nativo? :confused:

Te l'ho già detto: con le moderne architetture out-of-order è tempo perso. Molto meglio lasciare al compilatore l'onere di sbrogliare la matassa tenendo in considerazione i numerosi vincoli a cui sono soggette le istruzioni e l'architettura in generale.
io continuo a pensare che dipende. nel senso che se si conosce la maniera più efficiente per sbrogliare la matassa si può anche farci un pensierino

Fermo restando che, come dicevo anche prima, l'uso di un compilatore JIT permette di profilare l'esecuzione del codice ed eventualmente modificarlo per meglio adattarsi alla situazione reale: cosa impossibile da fare se il codice è già stato compilato una tantum, anche a manina con l'assembly.

questo introduce 2 aspetti sostanzialmente:
- il codice è capace di adattarsi alla situazione in tempo reale permettendo maggiore efficienza
- qualcosa deve continuare a profilare il codice e ne deve pure interpretare i risultati diminuendo l'efficienza

k0nt3

27-08-2007, 12:21

Ehm... Cosa? :D

questo post si commenta da solo http://www.hwupgrade.it/forum/showpost.php?p=17520558&postcount=225
se devo essere sincero mi è dispiaciuto molto che diamonds è morto (o quasi?)

Lo sostenevo pure io. :D

E' un ottimo segnale: significa che il bestione, seppur lentamente, è incline ai cambiamenti. :p

eddai per una volta che non siamo gli ultimi :sofico: http://www.alfonsofuggetta.org/?p=1681

ps. il mio professore (che non è lo stesso del sito sopra) però non era tanto d'accordo con l'XP :p e io più o meno la penso come lui: bisogna prendere dalla "dottrina" dell'XP soltanto quello che serve :O mai estremizzare ne pensare che una certa metodologia va bene per tutte le situazioni :read:

cdimauro

27-08-2007, 14:09

confronta:

>>>>>>>>>++++++++[>++++++++++<-]
<++++++[>++++++++++<-]
<+++[>++++++++++<-]
<++++++++++[>++++++++++<-]
<++++++++++++[>++++++++++<-]
<++++++++++[>++++++++++<-]
<+++++++[>++++++++++<-]
<+++[>++++++++++<-]
<+++++++++[>++++++++++<-]
>---.>++.>++++.>---.>--.>---.>++.>--.>-.

vs

System.out.print("W Java");

:asd:
Confronta con:

print 'W Python'
:asd:
comunque è carino il bf :D
Come una colonia di piattole. :asd:

^TiGeRShArK^

27-08-2007, 14:13

questo post si commenta da solo http://www.hwupgrade.it/forum/showpost.php?p=17520558&postcount=225
se devo essere sincero mi è dispiaciuto molto che diamonds è morto (o quasi?)
Veramente il problema principale sono MOLTI test fatti a cazzo.. :fagiano:

k0nt3

27-08-2007, 14:30

Veramente il problema principale sono MOLTI test fatti a cazzo.. :fagiano:
bisognerebbe fare dei test per i test :asd:

cdimauro

27-08-2007, 14:30

non esattamente.. è la differenza che c'è tra il malware di I tipo e il malware di III tipo http://invisiblethings.org/papers/towards_verifiable_systems.ppt
ovviamente mi auguro che nessuno riesca a scovare un bug nell'hypervisor, ma anche che nessuno (sony?) abbia interesse nel fornire il mio pc di un rootkit :fagiano:
Ho letto il documento e ribadisco: si tratta di problematiche molto simili a quelle che ha un kernel.
per le macchine non dotate di protezione della memoria.. penso che non sia roba da tutti i giorni!
Posso assicurarti che il mondo è pervaso da siffatte macchine. :p
comunque sia non ho capito se per produttività e robustezza intendi una serie di caratteristiche del linguaggio (perchè in questo caso non è fatto di managed o no)
Sì, mi riferisco a quello. E' vero che non è strettamente legato al fatto che un linguaggio sia managed o no, ma (e mi riferisco alla robustezza qui) in un linguaggio non-managed devi essere tu programmatore a usarlo in modo da "mimare" il funzionamento di quelli managed.

Quanto alla produttività, dipende da due fattori:
- la maggior robustezza di cui sopra (esempio: se è impossibile accedere ad aree di memoria diverse da quelle messeci a disposizione, e ogni tentativo viene intercettato, bloccato e messo alla gogna, non impazzirò cercando di tracciare bug rognosi come questi);
- gli strumenti che il linguaggio mette a disposizione.

In quest'ultimo caso c'è da dire che, dei linguaggi managed, quelli dinamici offrono una notevole versatilità.
scusate una domanda... ma senza CLR è possibile eseguire del codice .NET che è stato precompilato in codice nativo? :confused:
Un CLR per generare il codice nativo ci vuole sempre. :D

A parte gli scherzi, non ho esperienza, ma "a naso" non dovrebbe aver bisogno del CLR per funzionare.
io continuo a pensare che dipende. nel senso che se si conosce la maniera più efficiente per sbrogliare la matassa si può anche farci un pensierino
Facciamo una cosa: scaricati il manuale per le ottimizzazioni dell'architettura x86 dal sito di Intel e/o AMD, e se sei arrivato fino alla fine (è un bel malloppone, per cui è facile desistere dopo un po' di pagine :asd:) mi dirai se sei ancora convinto della tua idea. :p
questo introduce 2 aspetti sostanzialmente:
- il codice è capace di adattarsi alla situazione in tempo reale permettendo maggiore efficienza
- qualcosa deve continuare a profilare il codice e ne deve pure interpretare i risultati diminuendo l'efficienza
In realtà si potrebbe fare anche col codice compilato nativamente. Leggiti questo http://arstechnica.com/reviews/1q00/dynamo/dynamo-1.html interessante articolo sull'argomento.

Ne riporto un pezzo significativo:
Dynamo is an odd beast. It is, in essence, an interpreter for HP's PA-8000 instruction set that itself runs on a PA-8000 processor. That's right -- it interprets programs that could just as easily be executed natively on the same hardware. For a research prototype, this isn't as strange as it seems. The Dynamo project was started to investigate issues in what was seen as an increasingly important area -- dynamic translation of non-native binaries to native code. For that purpose it doesn't really matter if the original binaries are non-native or not, only that, whatever they are, they're read into some internal form, munged, and spit back out for native execution. The question is only, "How can this translation be efficient, both in time and space?" What's surprising is that Dynamo "inadvertently" became practical. Programs "interpreted" by Dynamo are often faster than if they were run natively. Sometimes by 20% or more.
;)

cdimauro

27-08-2007, 14:36

questo post si commenta da solo http://www.hwupgrade.it/forum/showpost.php?p=17520558&postcount=225
Il problema, come diceva giustamente Danilo, è che tanti test non sono stati fatti bene.

Questo NON dimostra la fallibilità dell'approccio XP / TDD al progetto.
se devo essere sincero mi è dispiaciuto molto che diamonds è morto (o quasi?)
E' stato ripreso in mano da Jappilas (che però è in vacanza, per cui è fermo da un po').
eddai per una volta che non siamo gli ultimi :sofico: http://www.alfonsofuggetta.org/?p=1681
Non siamo gli ultimi perché, nonostante la repubblica delle banane qual è l'Italia :rolleyes:, abbiamo tante di quelle menti brillanti che riusciamo a farci notare lo stesso all'estero. :p
ps. il mio professore (che non è lo stesso del sito sopra) però non era tanto d'accordo con l'XP :p e io più o meno la penso come lui: bisogna prendere dalla "dottrina" dell'XP soltanto quello che serve :O mai estremizzare ne pensare che una certa metodologia va bene per tutte le situazioni :read:
Mi sembra normale: bisogna valutare e decidere se come metodologia si sposa bene coi fini che si prefigge il progetto su cui si dovrà lavorare.

ndakota

27-08-2007, 14:38

ed ecco l'hello world in malbolge

(=<`:9876Z4321UT.-Q+*)M'&%$H"!~}|Bzy?=|{z]KwZY44Eq0/{mlk**
hKs_dG5[m_BA{?-Y;;Vb'rR5431M}/.zHGwEDCBA@98\6543W10/.R,+O<

intuitivo direi ;)

http://en.wikipedia.org/wiki/Malbolge

k0nt3

27-08-2007, 14:44

hello world in whitespace:

:read:

AngeL)

27-08-2007, 15:00

intuitivo direi ;)

lol

k0nt3

27-08-2007, 15:04

Ho letto il documento e ribadisco: si tratta di problematiche molto simili a quelle che ha un kernel.
le problematiche sono simili ma i metodi per rilevare tali problematiche sono moolto diversi

Un CLR per generare il codice nativo ci vuole sempre. :D

A parte gli scherzi, non ho esperienza, ma "a naso" non dovrebbe aver bisogno del CLR per funzionare.
io ce la farei una prova :fagiano:

Facciamo una cosa: scaricati il manuale per le ottimizzazioni dell'architettura x86 dal sito di Intel e/o AMD, e se sei arrivato fino alla fine (è un bel malloppone, per cui è facile desistere dopo un po' di pagine :asd:) mi dirai se sei ancora convinto della tua idea. :p

non c'è bisogno e ti credo sulla parola per quanto riguarda la difficoltà di lettura di tali manuali :D
ma questo perchè si parla di codice qualsiasi! quando invece si parla di casi particolari (e possibilmente che richiedono poco codice ASM) si può fare qualcosa. per fare un esempio stupido.. la maniera più efficiente per confrontare due valori è usare l'istruzione CMP non penso ci siano dei dubbi

In realtà si potrebbe fare anche col codice compilato nativamente. Leggiti questo http://arstechnica.com/reviews/1q00/dynamo/dynamo-1.html interessante articolo sull'argomento.

Ne riporto un pezzo significativo:

;)
transmeta! già sentita nominare :asd:

k0nt3

27-08-2007, 15:20

Il problema, come diceva giustamente Danilo, è che tanti test non sono stati fatti bene.

Questo NON dimostra la fallibilità dell'approccio XP / TDD al progetto.

forse intendevi l'infattibilità.. ma ci mancherebbe! al limite dimostra che un'approccio può andare alla perfezione in 10000 progetti ma questo non ci dice niente sul 10001°
se posso azzardo un'idea... avete provato a calcolare il rapporto "numero righe di codice funzionale"/"numero righe di codice dei test"? ecco io i miei dubbi sul testare qualunque cosa li ho :stordita:
la battuta sui test dei test era una battuta, però fa riflettere

cdimauro

27-08-2007, 15:44

le problematiche sono simili ma i metodi per rilevare tali problematiche sono moolto diversi
Infatti io non mi riferivo ai metodi. ;)
io ce la farei una prova :fagiano:
Non c'ho mai provato e non ho abbastanza tempo in questo momento.
non c'è bisogno e ti credo sulla parola per quanto riguarda la difficoltà di lettura di tali manuali :D
Non è soltanto una questione di difficoltà di lettura (sono argomenti estremamente tecnici), ma quanto dell'ENORME quantità di informazioni contenute e di cui bisogna tenere conto.

Ecco perché dico che è il lavoro adatto a un compilatore: lui non è umano, e lo si può caricare di vincoli senza pericolo di ritrovarsi con una camicia di forza.
ma questo perchè si parla di codice qualsiasi! quando invece si parla di casi particolari (e possibilmente che richiedono poco codice ASM) si può fare qualcosa. per fare un esempio stupido.. la maniera più efficiente per confrontare due valori è usare l'istruzione CMP non penso ci siano dei dubbi
Si potrebbe usare anche la test. ;)
transmeta! già sentita nominare :asd:
Ci lavorava un certo Torvalds...

cdimauro

27-08-2007, 15:49

forse intendevi l'infattibilità.. ma ci mancherebbe! al limite dimostra che un'approccio può andare alla perfezione in 10000 progetti ma questo non ci dice niente sul 10001°
La problematica non riguarda la quantità di progetti andati a buon fine, quanto invece la loro tipologia.

Tempo fa su una pagina avevo trovato uno schema con le diverse metodologie di sviluppo del software e i campi d'applicazione, ma non ho conservato il link.
se posso azzardo un'idea... avete provato a calcolare il rapporto "numero righe di codice funzionale"/"numero righe di codice dei test"? ecco io i miei dubbi sul testare qualunque cosa li ho :stordita:
A che servirebbe calcolare questo rapporto?
la battuta sui test dei test era una battuta, però fa riflettere
Sì, ma t'è stata data anche la risposta. ;)

^TiGeRShArK^

27-08-2007, 16:06

bisognerebbe fare dei test per i test :asd:

basterebbe spezzare le ditine fisicamente e non solo virtualmente :O

(e ovviamente anch'io ne ho scritte di schifezze e mi avrebbe fatto bene qualche rottura di ditini :asd: )

k0nt3

27-08-2007, 16:36

La problematica non riguarda la quantità di progetti andati a buon fine, quanto invece la loro tipologia.

Tempo fa su una pagina avevo trovato uno schema con le diverse metodologie di sviluppo del software e i campi d'applicazione, ma non ho conservato il link.

questo ci da un'indicazione di quanto l'ingegneria del software è ancora una "scienza" immatura. siamo ancora allo stadio empirico
se trovi il link sarebbe interessante :)

A che servirebbe calcolare questo rapporto?

Sì, ma t'è stata data anche la risposta. ;)
:fagiano: no era per dire che tutta l'infrastruttura di test che avete messo in piedi è davvero notevole

basterebbe spezzare le ditine fisicamente e non solo virtualmente

(e ovviamente anch'io ne ho scritte di schifezze e mi avrebbe fatto bene qualche rottura di ditini )
:asd: per questo il pair programming è meglio farlo faccia a faccia e non via chat

bist

27-08-2007, 18:17

Un CLR per generare il codice nativo ci vuole sempre. :D

A parte gli scherzi, non ho esperienza, ma "a naso" non dovrebbe aver bisogno del CLR per funzionare.

Il CLR ci vuole, altrimenti l'applicazione non sarebbe più managed.

marco.r

27-08-2007, 20:46

hello world in whitespace:

#include <stdio.h>

int main()
{
printf("Hello World\n");
return 0;
}

:read:
Anche questo programma e' scritto in whitespaces :D, ed incidentalmente pure in C :p

cdimauro

27-08-2007, 20:47

Il CLR ci vuole, altrimenti l'applicazione non sarebbe più managed.
Se bisogna far eseguibile delle applicazioni .NET compilandole al volo durante l'esecuzione sì, ma l'ipotesi di cui sopra era che fossero interamente compilate in formato binario nativo dell'architettura ospite. ;)

cdimauro

27-08-2007, 21:03

questo ci da un'indicazione di quanto l'ingegneria del software è ancora una "scienza" immatura. siamo ancora allo stadio empirico
se trovi il link sarebbe interessante :)
Mi spiace, ma non sono riuscito a recuperarlo. :|
:fagiano: no era per dire che tutta l'infrastruttura di test che avete messo in piedi è davvero notevole
Ma non copre tutto il codice, purtroppo, anche se la percentuale di linee di codice testata era molto elevata.
:asd: per questo il pair programming è meglio farlo faccia a faccia e non via chat
Indubbiamente, ma senza chat sarebbe stato impossibile farlo. :|

bist

27-08-2007, 21:07

Se bisogna far eseguibile delle applicazioni .NET compilandole al volo durante l'esecuzione sì, ma l'ipotesi di cui sopra era che fossero interamente compilate in formato binario nativo dell'architettura ospite. ;)

Il CLR non serve solo a compilare, serve a fare girare le applicazioni.
Il codice gira "dentro" il CLR, è per questo che si chiama managed code.
Che io sappia la VM fa parte del CLR. Compilazione prima o just in time non cambia nulla.

marco.r

27-08-2007, 21:09

Per quanto riguarda l'evoluzione di Java, io non me ne lamento affatto: le modifiche sono le benvenute. :D

Io non sono contrario in generale alle modifiche ad un linguaggio, pero' rimango dell' idea che dovrebbero essere abbastanza generali da portare molti vantaggi, poche in modo che entrino nella testa della gente abbastanza facilmente e di conseguenza ortogonali tra di loro.
E infine non devono richiedere una sintassi arcana.

Ad esempio ad introdurre in modo opportuno le closures prima, forse non avrebbero sentito la necessita' di una sintassi nuova per iterare su una collezione... poter definire funzioni dove cavolo si vuole, e passarle come argomento senza dover tribolare per costruire classi istanze e compagnia, permette molte semplificazioni. Penso a qualcosa del genere (occhio, e' "pseudo-java spannometrico" :D).

class Foo
{
public virtual void foo(Vector<Foo> v)
{
void doit( Foo f ){ f.doSomething( this, 42 ); }
c.apply( doit );
}
/* ... */
}

cionci

27-08-2007, 21:11

Però violeresti il principio secondo cui tutto in Java (tranne i tipi base) è un'oggetto.
Ho visto che in D puoi fare quello che hai scritto ;)

marco.r

27-08-2007, 21:42

Però violeresti il principio secondo cui tutto in Java (tranne i tipi base) è un'oggetto.

Puoi vederlo al contrario, ovvero renderei oggetti di prima classe anche i metodi (tutto sta nella definizione di oggetto che si usa). O in alternativa possiamo giustificarci dicendo che i metodi usati cosi' vengono implicitamente convertiti una classe anonima con un unico metodo con un certo nome).
Se lo si puo' fare con le stringhe, perche non con i metodi ?

Francamente quel che ho scritto sopra non mi sembra meno OO dell'uso di un ciclo for e, quando devo raccogliere i risultati, pure piu' conciso.

gokan

27-08-2007, 22:24

D'altra parte parlando di Giovanni e Paperi il suo nome è una garanzia: Giovanni Gallo. :p

Stai parlando per caso di Giovanni Gallo, dell'Università di Catania (mi sembra che tu abbia detto che sei di quelle parti)?

Se si, è stato mio prof nel periodo in cui ho studiato Informatica a Catania..gran brava persona..anche umanamente!!

Ciao

nrk985

27-08-2007, 22:54

In ambito mobile .NET compact è morto prima ancora di nascere e paragonato a MIDP si mette a piangere. Per il resto su smart phone C e C++ dominano.
e perchè?
ha molte piu potenzialita .net compact di un midp qualsiasi.
e riguardo alla portabilità: http://dotnetvnc.sourceforge.net/ ... un EXE unico che esegue su tutti i windows, tutti i pocket pc e smartphone windows mobile, e probabilmente anche tutti i linux con mono... cn java ci riesci in questo? la risposta è no.

ma forse il problema è che i telefoni non sono abbastanza potenti e l'utenza e i developers non sono abbastanza interessati al .net compact, e anche perchè windows mobile è poco diffuso...
d'altro canto java j2me è solo per i giochi, dato che il resto delle feature sono ridotte al minimo indispensabile... con un supporto disomogeneo tra un telefono e l'altro, vale a dire che servono JAR differenti per telefoni differenti(tutto questo grazie anche a nokia) vanificando completamente il goal primario di java...

cionci

27-08-2007, 23:07

nrk985

27-08-2007, 23:36

Addirittura i palmari venduti con una VM saranno circa il 5% (solo HP su alcuni modelli mi sembra). Quindi diciamo che Java nel mondo mobile va bene solo su smartphone. Mi sembra un'assurdità che Sun non sviluppi una VM per Windows Mobile.
.Net è molto più promettente da questo punto di vista...

cioè? esistono palmari con VM java j2se? io conoscevo solo CreME ma nn mi sono mai informato, potrebbe anche essere un ennesimo clone di j2ME...

comunque il Net è molto piu pormettente anche perchè non ti stravolge il modo di progrtammare anche se sei su un cellulare... le specifiche cldc e midp erano già obsolete per i primi cellulari che le adottavano.
Mentre con NET crei form, piazzi controlli, interagisci con file, device e rete esattamente allo stesso modo di come se fossi su windows. Anche se a dir la verità non ho l'mai estensivamente provato, perchè tutto qwuello che ho fatto sono 2 plug-in in C++ e uno stupido programmino nativo (li vedi in firma) :D

ciao

cionci

27-08-2007, 23:41

cioè? esistono palmari con VM java j2se? io conoscevo solo CreME ma nn mi sono mai informato, potrebbe anche essere un ennesimo clone di j2ME...
Non volevo dire che solo pochi palmari vengono distribuiti con un VM e per giunta nemmeno di Sun. Esistono VM commerciali J2ME CLDC e CDC (IBM J9 ad esempio), ma non J2ME anche se sarebbe tranquillamente possibile svilupparla.

k0nt3

27-08-2007, 23:54

mjordan

27-08-2007, 23:55

cioè? esistono palmari con VM java j2se? io conoscevo solo CreME ma nn mi sono mai informato, potrebbe anche essere un ennesimo clone di j2ME...

JSE sui palmari non ci va per definizione. SE è la versione desktop di Java.

comunque il Net è molto piu pormettente anche perchè non ti stravolge il modo di progrtammare anche se sei su un cellulare... le specifiche cldc e midp erano già obsolete per i primi cellulari che le adottavano.

Ed ecco perchè nei cellulari il .NET framework non esiste o per lo meno è talmente un fantasma che non lo si incontra nel 99% dei prodotti :) Sugli smartphone tradizionali invece si usano le API native C/C++ del sistema operativo sottostante. Nella pratica, .NET compact sta solo in palmari e telefoni di tipo smartphone con sistemi Microsoft. Che non hanno nmmeno tutto questo market share, oltre tutto. ;) I limiti sono hardware nei cellulari. Per quanto riguarda CLDC e MIDP, non direi visto che uno dei primi cellulari al mondo che ha adottato un profilo MIDP1 è stato il Motorola T720 seguito dal Motorola V66. All'epoca era già un miracolo che simili dispositivi potessero essere definiti "programmabili", schermi piccoli e monocromatici, capacità di calcolo ridicole, connettività assente (già chi aveva WAP stava avanti), nessuna forma di multimedialità (zero fotocamera, video, foto). Al massimo c'erano i loghi operatore stile Nokia. Altro che profili obsoleti. Non erano i profili ad essere obsoleti, era su quei cellulari che non si poteva fare di piu'.

Mentre con NET crei form, piazzi controlli, interagisci con file, device e rete esattamente allo stesso modo di come se fossi su windows. Anche se a dir la verità non ho l'mai estensivamente provato, perchè tutto qwuello che ho fatto sono 2 plug-in in C++ e uno stupido programmino nativo (li vedi in firma) :D

ciao

Su quali dispositivi scusa? Perchè se mi parli di palmari e poi mi citi i profili CLDC, allora ti rispondo che mi stai facendo un grosso minestrone. Perchè per questi dispositivi dobbiamo considerare non piu' CLDC ma CDC. E con un profilo CDC si programma come se si fosse su desktop. Addirittura molte delle classi Swing sono utilizzabili. Primo telefono al mondo (dev phone) ad implementare un profilo CDC: Jasper S20. Ma visto che mi parli id .NET compact, allora si, mi stai facendo un minestrone, perchè mi stai confondendo il mercato dei palmari e degli smartphone con i profili Java destinati ai telefoni non smartphone (figuriamoci i palmari).

Per quanto riguarda i cellulari (non smartphone), sembra che tu non consideri la MSA (Mobile Service Architecture) e il MIDP 3.0 di prossimo rilascio. La frammentazione in questo modo è quasi risolta, ache se il problema non è dei framework ma della varietà dei dispositivi esistenti. Non credo che un programma che usi una videocamera tu lo possa usare su un telefono che tale videocamera non ce l'ha, .NET o non .NET ;)

Questo per il discorso delle features. Il discorso che facevo io è diverso e non cambia lo stesso: .NET compact, al di la delle sue potenzialità è un prodotto morto. Ormai JME ha festeggiato il miliardo di unità su cui è installato a livello globale.

nrk985

27-08-2007, 23:56

Non volevo dire che solo pochi palmari vengono distribuiti con un VM e per giunta nemmeno di Sun. Esistono VM commerciali J2ME CLDC e CDC (IBM J9 ad esempio), ma non J2ME anche se sarebbe tranquillamente possibile svilupparla.

forse qualche anno fa, ma ora ce l'hanno tutti, tranne i palmari piu pezzenti. :D

usano prevalentemente il tao Intent JMM e l'esmertec jeodek

soltanto che tutte le vm per windows mobile sono incredibilmente indietro in quanto al supporto delle JSR opzionali: bluetooth, java3d, etc... anzi, sembra che proprio nn vogliano implementarla

però è vero che sono estremamente veloci... merito probabilmente del processore del mio cellulare (ti omap850 con jazelle, se n'era già parlato in sto thread)

nrk985

28-08-2007, 00:02

JSE sui palmari non ci va per definizione. SE è la versione desktop di Java.questa distinzione non c'è in net, ed è un vantaggio

Non direi visto che uno dei primi cellulari al mondo che ha adottato un profilo MIDP1 è stato il Motorola T720 seguito dal Motorola V66. All'epoca era già un miracolo che simili dispositivi potessero essere definiti "programmabili". Altro che profili obsoleti. hai ragione

Su quali dispositivi scusa? Perchè se mi parli di palmari e poi mi citi i profili CLDC, allora ti rispondo che mi stai facendo un grosso minestrone. Perchè per questi dispositivi dobbiamo considerare non piu' CLDC ma CDC. E con un profilo CDC si programma come se si fosse su desktop. Addirittura molte delle classi Swing sono utilizzabili. Primo telefono al mondo (dev phone) ad implementare un profilo CDC: Jasper S20.sinceramente un dev-cellulare prototipo-esperimento_tecnologico-showcase non fa i grandi numeri... e VM che supportino i profili CDC per palmari non ne ho viste ancora, colpa di sun?

Per quanto riguarda i cellulari, sembra che tu non consideri la MSA (Mobile Service Architecture) e il MIDP 3.0 di prossimo rilascio.speriamo che abbiano corretto tutte le castronerie precedenti, es. specifiche che fanno acqua da tutte le parti e permettono a produttori coem nokia di ampliarle a piacimento aggiungendo parti proprietarie e rimanere comunque certificati (quando anche altre parti della vm java del symbian NON erano conformi)

Questo per il discorso delle features. Il discorso che facevo io è diverso e non cambia lo stesso: .NET compact, al di la delle sue potenzialità è un prodotto morto. Ormai JME ha festeggiato il miliardo di unità su cui è installato a livello globale. Un po tardi per dire che è troppo presto ;)rimane da vedere, il compact è da molto poco tempo che c'è... e qui si stava facendo un confronto tecnico, non un confronto sul livello marketing... e sul livello tecnico non ci sono paragoni

nrk985

28-08-2007, 00:04

una volta mi è capitato di usare .NET su un palmare ed è stato frustante (no non è un errore grammaticale :muro: )
è vero che puoi usare le componenti grafiche che vuoi, ma sono iperlimitate e anche poco facilmente estensibili (qualcuno ha detto tabelle? :D )

e l'alternativa qual'è? usare le api native (suicidio) o usare le MFC (suicidio^2, considerando che ti costringono a distribuire 2 mb di runtime e praticamente nn le usa nessuno)

oppure... j2me? :asd:

k0nt3

28-08-2007, 00:15

e l'alternativa qual'è? usare le api native (suicidio) o usare le MFC (suicidio^2, considerando che ti costringono a distribuire 2 mb di runtime e praticamente nn le usa nessuno)

oppure... j2me? :asd:
l'alternativa è comprare librerie aggiuntive proprietarie.. ma considerando che il mio lavoro era a titolo gratuito ho dovuto arrangiarmi creando il mio controllo personalizzato

qual'è il problema con j2me? non l'ho mai usato ma sembra che permette l'uso di componenti grafiche abbastanza agevolmente http://developers.sun.com/mobility/midp/articles/ui/GuiTests.java

mjordan

28-08-2007, 00:16

Non volevo dire che solo pochi palmari vengono distribuiti con un VM e per giunta nemmeno di Sun. Esistono VM commerciali J2ME CLDC e CDC (IBM J9 ad esempio), ma non J2ME anche se sarebbe tranquillamente possibile svilupparla.

Ma guarda, la VM JME è completamente open source ora... Quello che rimane per avere un'implementazione completa in verità tocca al produttore, non proprio a Sun.

mjordan

28-08-2007, 00:22

e perchè?
ha molte piu potenzialita .net compact di un midp qualsiasi.

.Net compact, lo ripeto per chi non lo ha capito, va paragonato con CDC e non con MIDP ;)
Nel segmento di mercato dove MIDP domina (e cioè i "piccoli" cellulari non smart phone) abbiamo la situazione che .NET lascia completamente scoperto questo segmento, rendendo lo stesso MIDP, di fatto, l'unico prodotto in commercio a rendere programmabili simili dispositivi. E questo è un dato di fatto.

mjordan

28-08-2007, 00:29

questa distinzione non c'è in net, ed è un vantaggio

Io il vantaggio non lo vedo. Se per un programma mi manca un supporto hardware, quel programma non lo uso lo stesso. Quindi quella sensazione di "portabilità estrema senza cambiamenti" è comunque fittizia. Quanto all'eseguire un programma per palmari su un PC Windows, lo considero un gran bell'esercizio di stile ma non proprio una possibilità interessante. E comunque anche i semplici jar di MIDP si possono eseguire su PC.

sinceramente un dev-cellulare prototipo-esperimento_tecnologico-showcase non fa i grandi numeri... e VM che supportino i profili CDC per palmari non ne ho viste ancora, colpa di sun?

Si hai ragione ma era per dirti che il paragone .NET compact VS MIDP è fuori luogo. La colpa comunque è dei produttori, molto lenti ad assimilare le nuove tecnologie. MIDP 2.1 per esempio è un pezzo che è fuori ma l'unico telefono fully compliant è il SonyEricsson K850 ... C'è anche da dire che la lentezza dei produttori, in fondo in fondo non è un problema tecnico ma di marketing: alla maggior parte della gente di queste questioni non importa nulla e compra i cellulari esclusivamente per estetica. Io personalmente non conosco nessuno che compra un cellulare e prima si informa su quali API abbia quel cellulare. In sostanza, la colpa di questa lentezza in fondo in fondo sono proprio i consumatori stessi. Tanto il RAZR V3 vende un botto lo stesso, chissenefrega allora :D

speriamo che abbiano corretto tutte le castronerie precedenti, es. specifiche che fanno acqua da tutte le parti e permettono a produttori coem nokia di ampliarle a piacimento aggiungendo parti proprietarie e rimanere comunque certificati (quando anche altre parti della vm java del symbian NON erano conformi)

Sono d'accordo che questo è il principale limite di come funzionano attualmente le cose con Java. Però pare che MSA dia una piccola controllata alla cosa. Vedremo. E' anche uno dei motivi per cui un telefono Nokia non entrerà mai in casa mia.

rimane da vedere, il compact è da molto poco tempo che c'è... e qui si stava facendo un confronto tecnico, non un confronto sul livello marketing... e sul livello tecnico non ci sono paragoni

Eppure mi hai risposto con un confronto tecnico laddove io facevo solo un ragionamento di marketing ;) E che tecnicamente non ci siano paragoni, ho da obiettare. Perchè un possibile CDC ha gli stessi vantaggi del .NET compact, con il vantaggio in piu' che non ci sono "exe" che girano su Windows ma "jar" che girano su tutte le piattaforme supportate da Java (parlo sui PC, tanto per chiarezza) :)
Ok, tecnicamente CDC ancora c'è e quindi attualmente su piattaforme palmari/smartphone attualmente .NET compact è quanto di meglio ci sia. Ma anche li soffre della grossa concoerrenza dei programmi nativi...

nrk985

28-08-2007, 00:41

qual'è il problema con j2me? non l'ho mai usato ma sembra che permette l'uso di componenti grafiche abbastanza agevolmente http://developers.sun.com/mobility/midp/articles/ui/GuiTests.javasi, ma queste componenti grafiche sono estremamente limitate.
lo vedi subito che è fatto in java, e questo è indice di scarsità qualitativa.
il layout stesso del Display è dall'alto al basso, senza possibilità di eccezione, e coi pulsanti su/giu li scorri.. hanno voluto ridurre ai minimi termini le funzionalità di base, ma proprio ai minimi termini.

Io il vantaggio non lo vedo. Se per un programma mi manca un supporto hardware, quel programma non lo uso lo stesso. Quindi quella sensazione di "portabilità estrema senza cambiamenti" è comunque fittizia.I cellulari di oggi hanno tutti quel supporto hardware che serve per eseguire il net, tranne i più schifosi.
E a sto punto un telefono "compatibile MIDP 2.0" può anche mandare solo le applicazioni che utilizzino l'lcdui (lwt) e non tutte le latre che fanno uso di boiate a schermo intero, java3d, e tutte le altre API opzionali.
Mentre invece il compatc framework lo fa solo la microsoft, e decide lei cosa metterci, e ovviamente la ricetta è la stessa per tutti.

mjordan

28-08-2007, 00:56

I cellulari di oggi hanno tutti quel supporto hardware che serve per eseguire il net, tranne i più schifosi.

Ah... Allora non proprio tutti ;)

E a sto punto un telefono "compatibile MIDP 2.0" può anche mandare solo le applicazioni che utilizzino l'lcdui (lwt) e non tutte le latre che fanno uso di boiate a schermo intero, java3d, e tutte le altre API opzionali.
Mentre invece il compatc framework lo fa solo la microsoft, e decide lei cosa metterci, e ovviamente la ricetta è la stessa per tutti.

Si, cosi facendo però la ricetta è uguale per tutti si, ma per 4 cellulari in commercio, basati solo su Windows Mobile. Non che sia un gran mercato. Ancora, paragoniamo il compact framework con il segmento midp...

^TiGeRShArK^

28-08-2007, 01:11

cioè? esistono palmari con VM java j2se? io conoscevo solo CreME ma nn mi sono mai informato, potrebbe anche essere un ennesimo clone di j2ME...

comunque il Net è molto piu pormettente anche perchè non ti stravolge il modo di progrtammare anche se sei su un cellulare... le specifiche cldc e midp erano già obsolete per i primi cellulari che le adottavano.
Mentre con NET crei form, piazzi controlli, interagisci con file, device e rete esattamente allo stesso modo di come se fossi su windows. Anche se a dir la verità non ho l'mai estensivamente provato, perchè tutto qwuello che ho fatto sono 2 plug-in in C++ e uno stupido programmino nativo (li vedi in firma) :D

ciao
E xkè con il Personal Profile non puoi forse usare anche SWT tanto per fare un esempio? ;)
E per favore evitiamo di elencare tutte le svariate APPLICAZIONI che ci sono per gli smart-phone java :p
Java nel mondo degli smart-phone domina letteralmente il .net compact quanto a diffusione e supporto (Open GL ES 1.1 ad esempio).
La pecca + grave è imho la mancanza di una JVM free DECENTE magari preinstallata sui vari pocket pc..
Anche se onestamente con i nuovi smartphone mi sfugge un pò il terget d'uso di un pocket pc :stordita:
Sul mio N73 ho lo schermo con la stessa risoluzione del mio HP H5500...certo..è + piccolo.. ma non mi da problemi da questo punto di vista :p

nrk985

28-08-2007, 01:15

E xkè con il Personal Profile non puoi forse usare anche SWT tanto per fare un esempio? ;)
guarda, non tirare fuori paroloni tipo SWT e personal profile.
so solo che SWT non lo mandi in un cellulare con j2me. fine.

Java nel mondo degli smart-phone domina letteralmente il .net compact quanto a diffusione e supporto (Open GL ES 1.1 ad esempio).dei giochi, si

Anche se onestamente con i nuovi smartphone mi sfugge un pò il terget d'uso di un pocket pc :stordita:
Sul mio N73 ho lo schermo con la stessa risoluzione del mio HP H5500...certo..è + piccolo.. ma non mi da problemi da questo punto di vista :p
e qui si capisce con chi parlo... se ti interessano i giochini ok, le cose serie sono un'altra cosa

^TiGeRShArK^

28-08-2007, 01:17

sinceramente un dev-cellulare prototipo-esperimento_tecnologico-showcase non fa i grandi numeri... e VM che supportino i profili CDC per palmari non ne ho viste ancora, colpa di sun?

:mbe:
si che ci sono...
Il Personal Profiloe di cui sopra non è altro che "a superset of Personal Basis Profile that supports resource-constrained devices with a graphical user interface toolkit based on AWT" preso direttamente dal sito della sun ;)
Quindi le VM per palmari che supportano Personal Profile esistono ma sono commerciali e/o non troppo aggiornate.
E tranquillo che ho visto con i miei occhi un programma usare le SWT lassopra come dicevo prima :p

speriamo che abbiano corretto tutte le castronerie precedenti, es. specifiche che fanno acqua da tutte le parti e permettono a produttori coem nokia di ampliarle a piacimento aggiungendo parti proprietarie e rimanere comunque certificati (quando anche altre parti della vm java del symbian NON erano conformi)

rimane da vedere, il compact è da molto poco tempo che c'è... e qui si stava facendo un confronto tecnico, non un confronto sul livello marketing... e sul livello tecnico non ci sono paragoni
xkè non ci sarebbero paragoni? :fagiano:

PGI-Bis

28-08-2007, 01:20

lo vedi subito che è fatto in java, e questo è indice di scarsità qualitativa.

Oddio, io non esagererei. Disegnare in Java è relativamente facile. Anche nell'ambiente ME. Direi piuttosto che può mancare quello "zic" in più da parte dei programmatori. Dove "zic" sta per "spendi un po' di tempo a disegnare un'interfaccia guardabile" oppure "fatti fare i bozzetti da un grafico". Ci vuole veramente un niente.

^TiGeRShArK^

28-08-2007, 01:21

si, ma queste componenti grafiche sono estremamente limitate.
lo vedi subito che è fatto in java, e questo è indice di scarsità qualitativa.
il layout stesso del Display è dall'alto al basso, senza possibilità di eccezione, e coi pulsanti su/giu li scorri.. hanno voluto ridurre ai minimi termini le funzionalità di base, ma proprio ai minimi termini.
:mbe:
Mai provato opera mini? :stordita:

^TiGeRShArK^

28-08-2007, 01:23

^TiGeRShArK^

28-08-2007, 01:27

guarda, non tirare fuori paroloni tipo SWT e personal profile.
so solo che SWT non lo mandi in un cellulare con j2me. fine.

:doh:
E infatti ho scritto chiaramente che le SWT le usi col Personal Profile non certo con il profilo MIDP..
E poi..
paroloni.. :mbe:
stiamo discutendo di piattaforme mobile e tu è da un'ora che discuti confondendo continuamente i profili CLDC, CDC, MIDP e Personal Profile.
Come si fa a portare avanti una discussione se mi accusi anche di dire paroloni quando specifico chiaramente che:"con il Personal Profile non puoi forse usare anche SWT?"

dei giochi, si

Perchè ora open gl ES sarebbe utile solo x fare giochi? :mbe:
Prova un attimo a vedere quanti sono i giochi sviluppati con Open GL su pc e quante le altre applicazioni :read:

e qui si capisce con chi parlo... se ti interessano i giochini ok, le cose serie sono un'altra cosa
e quali sarebbero le cose serie di grazia? :rolleyes:
forse quelle ke hai in sign? :rolleyes:
Per tua informazione io sui cellulari ho sviluppato cose ben + complesse di 2 semplici plugin :rolleyes:
In java ovviamente.

mjordan

28-08-2007, 03:12

:mbe:
Mai provato opera mini? :stordita:

Ahhhhh.... Opera Mini.... Che spettacolo... Non vedo l'ora che esce la 4.0 finale ... Proprio oggi ho letto sul blog degli sviluppatori che Mini è arrivato al punto di servire ben 1 miliardo di pagine al mese.... Un'altra applicazione degna di nota è Morange che ha un'interfaccia sbalorditiva, Google Local Maps che ormai è diventato fantastico, eBuddy o Mig33 come client MSN/multi protocol sono fenomenali, WLirc 2.0 per IRC
Eh già, è proprio solo per i giochi Java... :asd:

mjordan

28-08-2007, 03:19

Perchè ora open gl ES sarebbe utile solo x fare giochi? :mbe:
Prova un attimo a vedere quanti sono i giochi sviluppati con Open GL su pc e quante le altre applicazioni :read:

Come si chiamava quel progetto per creare un toolkit GUI 3D per cellulari? Ricordo che c'era una cosa del genere completamente basato su JSR184 e che la cosa mi colpì non poco... Non lo trovo piu' e non mi ricordo piu' nemmeno come si chiama... :doh:

cdimauro

28-08-2007, 09:00

Il CLR non serve solo a compilare, serve a fare girare le applicazioni.
Il codice gira "dentro" il CLR, è per questo che si chiama managed code.
Che io sappia la VM fa parte del CLR. Compilazione prima o just in time non cambia nulla.
Sì, può essere così.

Dallo schema che ho trovato qui qui http://en.wikipedia.org/wiki/Common_Language_Runtime tolta la generazione del codice da MSIL a nativo, rimangono dei compiti a carico della CLR, e non credo che siano a carico dell'applicazione.

Quindi un minimo di VM a quanto pare è sempre necessaria, ma mi piacerebbe saperne di più (ho fatto qualche ricerca ma ho trovato poche informazioni, purtroppo).

cdimauro

28-08-2007, 09:04

Io non sono contrario in generale alle modifiche ad un linguaggio, pero' rimango dell' idea che dovrebbero essere abbastanza generali da portare molti vantaggi, poche in modo che entrino nella testa della gente abbastanza facilmente e di conseguenza ortogonali tra di loro.
E infine non devono richiedere una sintassi arcana.

Ad esempio ad introdurre in modo opportuno le closures prima, forse non avrebbero sentito la necessita' di una sintassi nuova per iterare su una collezione... poter definire funzioni dove cavolo si vuole, e passarle come argomento senza dover tribolare per costruire classi istanze e compagnia, permette molte semplificazioni. Penso a qualcosa del genere (occhio, e' "pseudo-java spannometrico" :D).

class Foo
{
public virtual void foo(Vector<Foo> v)
{
void doit( Foo f ){ f.doSomething( this, 42 ); }
c.apply( doit );
}
/* ... */
}

E' pacifico che le modifiche devono integrarsi con lo stile/filosofia del linguaggio, non selvaggiamente com'è capitato con linguaggi come PHP, PERL, ecc.

Tanto per fare un esempio, ho apprezzato moltissimo l'introduzione in Python 2.5 dell'operatore ternario di selezione: l'ho trovato molto "pythonic". :p

cdimauro

28-08-2007, 09:07

Stai parlando per caso di Giovanni Gallo, dell'Università di Catania (mi sembra che tu abbia detto che sei di quelle parti)?

Se si, è stato mio prof nel periodo in cui ho studiato Informatica a Catania..gran brava persona..anche umanamente!!

Ciao
Sì, è proprio lui (io sono di Siracusa, ma da due anni abito a Catania). :)

All'università per me è stato un modello da seguire, ed è stato anche il mio relatore.

AngeL)

28-08-2007, 09:12

Sì, è proprio lui (io sono di Siracusa, ma da due anni abito a Catania). :)

All'università per me è stato un modello da seguire, ed è stato anche il mio relatore.

ma non parlavate di james (giovanni) gosling (gallo) ? :mbe:

bist

28-08-2007, 09:14

Sì, può essere così.

Dallo schema che ho trovato qui qui http://en.wikipedia.org/wiki/Common_Language_Runtime tolta la generazione del codice da MSIL a nativo, rimangono dei compiti a carico della CLR, e non credo che siano a carico dell'applicazione.

Quindi un minimo di VM a quanto pare è sempre necessaria, ma mi piacerebbe saperne di più (ho fatto qualche ricerca ma ho trovato poche informazioni, purtroppo).

Se fosse possibile far girare il codice senza il CLR, vorrebbe dire che il .NET Framework sarebbe solo una semplice libreria di alto livello, un wrapper delle win32 :) invece offre moltre altre funzionalità, appunto grazie al CLR che è l'ambiente di esecuzione (invece dell'OS nudo e crudo).

cdimauro

28-08-2007, 09:23

Se fosse possibile far girare il codice senza il CLR, vorrebbe dire che il .NET Framework sarebbe solo una semplice libreria di alto livello, un wrapper delle win32 :) invece offre moltre altre funzionalità, appunto grazie al CLR che è l'ambiente di esecuzione (invece dell'OS nudo e crudo).
Infatti ho visto in quel link che si occupa della gestione della memoria, del GC, ecc.

La questione è se è possibile integrare queste funzionalità in maniera trasparente in un'applicazione completamente nativa. Ho visto che ci sono un po' i produttori che offrono la possibilità di realizzare applicazioni .NET standalone, e alcuni dicono che integrano alcune librerie minimali del CLR, altri affermano che il CLR e la VM ci sono, ecc. Un vero casino, e non si capisce effettivamente cosa sia possibile fare.

cdimauro

28-08-2007, 09:24

ma non parlavate di james (giovanni) gosling (gallo) ? :mbe:
Papero, non gallo. :D

Giovanni Gallo c'è finito in mezzo quando s'è disquisito di estensioni dei linguaggi e relativo zucchero sintattico. :p

k0nt3

28-08-2007, 09:40

lo vedi subito che è fatto in java, e questo è indice di scarsità qualitativa.

io invece l'ho capito subito che sul palmare che mi hanno dato girava WIN CE.. mi è miserabilmente crashato :rolleyes:

il layout stesso del Display è dall'alto al basso, senza possibilità di eccezione, e coi pulsanti su/giu li scorri.. hanno voluto ridurre ai minimi termini le funzionalità di base, ma proprio ai minimi termini.

ma scusa.. cosa l'hanno messo a fare il GridBagLayout?
http://java.sun.com/javame/reference/apis/jsr216/java/awt/GridBagLayout.html

nrk985

28-08-2007, 10:32

:mbe:
si che ci sono...
Il Personal Profiloe di cui sopra non è altro che "a superset of Personal Basis Profile that supports resource-constrained devices with a graphical user interface toolkit based on AWT" preso direttamente dal sito della sun ;)
Quindi le VM per palmari che supportano Personal Profile esistono ma sono commerciali e/o non troppo aggiornate.
E tranquillo che ho visto con i miei occhi un programma usare le SWT lassopra come dicevo prima :p
se stiamo parlando di J2ME, NON ic mandi le swt.
se stiamo parlando dell'altra cosa (CDC o come 'zzo si chiama), ci sono POCHISSIMI device che lo supportano, e per di piu sono degli esperimenti.

xkè non ci sarebbero paragoni? :fagiano:
è come paragonare swing/awt a una qualsiasi altra API per UI sviluppata da esseri umani. l'altra API è sicuramente non una, ma almeno 2 volte meglio. e non sto parlando da uno che non ha mai usato swing.

:mbe:
Mai provato opera mini? :stordita:si, ma che c'entra? pesa piu di 100k, si saranno riscritti un casino di layout e altri controlli per farli stare come volevano loro... anzi, faranno tutto in una canvas a occhio...

Perchè ora open gl ES sarebbe utile solo x fare giochi? :mbe:
Prova un attimo a vedere quanti sono i giochi sviluppati con Open GL su pc e quante le altre applicazioni :read:ma che c'entra? sui cellulari OpenGL serve a una cosa: giochi!
o vuoi mandarci seti o prj di calcolo distribuito??? :asd:

e quali sarebbero le cose serie di grazia? :rolleyes:
forse quelle ke hai in sign? :rolleyes:
Per tua informazione io sui cellulari ho sviluppato cose ben + complesse di 2 semplici plugin :rolleyes:
In java ovviamente.ho anche scritto che i miei 2 plugin sono "stupidi", però di grazia dimmi te cosa hai sviluppato!

ma scusa.. cosa l'hanno messo a fare il GridBagLayout?
http://java.sun.com/javame/reference/apis/jsr216/java/awt/GridBagLayout.html
ehi ehi, ehi .... vedi nell'url? "JSR216" ... ergo, su quanti cellulari va, ora? zero... ergo, è utile? NO!

Questi profili sono stati pensati per dispositivi con capacità di calcolo differenti dai classici cellulari. Possiamo trovarli su PDA, Smartphone e altri dispositivi evoluti. Racchiudono molte delle API J2SE
dispostivi con capacità di calcolo differenti dai classici cellulari... quali? smartphone nokia? direi di no, perchè le capacità di calcolo sono pressochè li... palmari? boh, e chi la vede una VM sun per palmare???
sarà perchè ancora sono trincerati nel medioevo alla sun

cionci

28-08-2007, 10:42

ma scusa.. cosa l'hanno messo a fare il GridBagLayout?
http://java.sun.com/javame/reference/apis/jsr216/java/awt/GridBagLayout.html
E' JSR216 (cioè l'implementazione di AWT), ad occhio non credo che sia per i profili MIDP. Comunque confermo che a livello di framework base le classi per disegnare le interfacce sono veramente limitate. Il design è dall'alto verso il basso, ogni componente che metti si va ad infilare dopo quello che hai messo precedentemente senza possibilità di ridimensionamento o posizionamento.

cionci

28-08-2007, 10:45

si, ma che c'entra? pesa piu di 100k, si saranno riscritti un casino di layout e altri controlli per farli stare come volevano loro... anzi, faranno tutto in una canvas a occhio...
Tutti i controlli di Opera Mini sono stati riscritti ad hoc (tranne quando si editano i testi, quello è un controllo MIDP). Partendo dalla finestra intera in grafica e realizzando la selezione e la reazione in base agli input in grafica. In pratica si sono scritti un framework da soli.

k0nt3

28-08-2007, 10:46

ehi ehi, ehi .... vedi nell'url? "JSR216" ... ergo, su quanti cellulari va, ora? zero... ergo, è utile? NO!
non ci capisco più niente... stiamo parlando di marketing o di aspetti tecnici? :fagiano:
E' JSR216 (cioè l'implementazione di AWT), ad occhio non credo che sia per i profili MIDP. Comunque confermo che a livello di framework base le classi per disegnare le interfacce sono veramente limitate. Il design è dall'alto verso il basso, ogni componente che metti si va ad infilare dopo quello che hai messo precedentemente senza possibilità di ridimensionamento o posizionamento.
nessuno ha detto che era per i profili MIDP (infatti era CDC personal profile).. ma tu non mi puoi confrontare il framework .NET compact con MIDP semplicemente dove quest'ultimo gira con capacità limitate il primo non gira proprio :O

cionci

28-08-2007, 10:52

nessuno ha detto che era per i profili MIDP (infatti era CDC personal profile).. ma tu non mi puoi confrontare il framework .NET compact con MIDP semplicemente dove quest'ultimo gira con capacità limitate il primo non gira proprio :O
Nota che le periferiche compatibili CDC sono praticamente tendenti allo ZERO ad ancora meno sono quelle con CDC Personal Profile.

^TiGeRShArK^

28-08-2007, 10:56

se stiamo parlando di J2ME, NON ic mandi le swt.
se stiamo parlando dell'altra cosa (CDC o come 'zzo si chiama), ci sono POCHISSIMI device che lo supportano, e per di piu sono degli esperimenti.

No.
staimo parlando di Java per dispositivi mobili.
Quindi stiamo parlando sia di CLDC che di CDC.

ma che c'entra? sui cellulari OpenGL serve a una cosa: giochi!
o vuoi mandarci seti o prj di calcolo distribuito??? :asd:

Ci puoi fare assolutamente quello che vuoi.
Non mi pare ci sia scritto in nessun posto che Open GL ES sui cellulari deve essere relegato per contratto ai giochi.

ho anche scritto che i miei 2 plugin sono "stupidi", però di grazia dimmi te cosa hai sviluppato!

Qualcosa di *lievemente* + complesso.
Un software che grazie ad un architettura ad agenti intelligenti (JADE) e ad un motore di parsing dei workflow serve per l'assistenza guidata di innumerevoli tipologie di utenti.
Lo scenario che abbiamo curato maggiormente era l'assistenza degli operatori di rete telecom mediante interfacciamento diretto con la rete stessa per effettuare configurazioni, verifiche e quant'altro.
E poi per conto mio avevo fatto una banalissima applicazioncina per il controllo remoto tramite la videocamera del cellulare che inviava le foto direttamente sul mio server tramite rete UMTS (quando ancora avevo la semi-flat tim).

dispostivi con capacità di calcolo differenti dai classici cellulari... quali? smartphone nokia? direi di no, perchè le capacità di calcolo sono pressochè li... palmari? boh, e chi la vede una VM sun per palmare???
sarà perchè ancora sono trincerati nel medioevo alla sun
Si certo :asd:
alla sun sono trincerati nel medioevo :asd:
è proprio per questo che le applicazioni Java per i cellulari sono così diffuse :asd:

^TiGeRShArK^

28-08-2007, 10:58

Nota che le periferiche compatibili CDC sono praticamente tendenti allo ZERO ad ancora meno sono quelle con CDC Personal Profile.
Sui cellulari sicuramente (Anche se ad esempio il Nokia 9500 supportava il Peronal Profile).
Sui palmari assolutamente no.
Quello che manca è una JVM decente installata di DEFAULT.

nrk985

28-08-2007, 11:22

No.
staimo parlando di Java per dispositivi mobili.
Quindi stiamo parlando sia di CLDC che di CDC.
il mio confronto è sempre stato tecnico fin dall'inizio, sinceramente di tutte ste sigle nn ci capisco molto (sarà anche per questo che alla Sun viene presa x il culo da un po tutti per tutte le sue sigle e versioni?)

Ci puoi fare assolutamente quello che vuoi.
Non mi pare ci sia scritto in nessun posto che Open GL ES sui cellulari deve essere relegato per contratto ai giochi.seh, vabbè.... ciaooooo!!

Qualcosa di *lievemente* + complesso.
Un software che grazie ad un architettura ad agenti intelligenti (JADE) e ad un motore di parsing dei workflow serve per l'assistenza guidata di innumerevoli tipologie di utenti.
Lo scenario che abbiamo curato maggiormente era l'assistenza degli operatori di rete telecom mediante interfacciamento diretto con la rete stessa per effettuare configurazioni, verifiche e quant'altro.
E poi per conto mio avevo fatto una banalissima applicazioncina per il controllo remoto tramite la videocamera del cellulare che inviava le foto direttamente sul mio server tramite rete UMTS (quando ancora avevo la semi-flat tim).molto interessante, ma sarai uno dei pochi che ha fatto qualcosa di veramente interessante e utile per j2me

Si certo :asd:
alla sun sono trincerati nel medioevo :asd:
è proprio per questo che le applicazioni Java per i cellulari sono così diffuse :asd:già, grazie a (e x colpa di) una certa nokia che ha espanso il midp cn le sue classi permettendo di giocare a framerate accettabili....se era per Sun giocavamo ancora coi caratteri ascii nei textpane... ma va và...

Sui cellulari sicuramente (Anche se ad esempio il Nokia 9500 supportava il Peronal Profile).
Sui palmari assolutamente no.
Quello che manca è una JVM decente installata di DEFAULT.
scusa, conosci JVM per palmari?
JVM che supportino swing, swt, tutta l'altra roba?

^TiGeRShArK^

28-08-2007, 11:42

scusa, conosci JVM per palmari?
JVM che supportino swing, swt, tutta l'altra roba?
Ad esempio J9 della IBM che era stata anche citata prima ;)

PGI-Bis

28-08-2007, 12:20

Non credo che ci siano palmari in grado di supportare una piattaforma Java SE ma se avesse un processore x86, una quantità di memoria accettabile (diciamo un gigabyte) e Linux allora si potrebbe anche provare ad installarlo.

La piattaforma Websphere Everyplace Micro Environment supporta un fottìo di dispositivi a là palmare e affiini. Ha il piccolo inconveniente di essere a pagamento (l'utente finale lo paga circa 25$, non so quanto costi per un'acquisto in volumi).

Per le interfacce grafiche, Swing (che, per dipendenze, è poi una terna, Swing/AWT/Java2D) è un punto di riferimento assoluto. Lo è da un punto di vista meccanico e concettuale. Paga lo scotto della mancanza di un GUI builder decente - ci si avvicina Matisse di Netbeans - ciò che lo rende inviso alla metà dei programmatori - i cosidetti visuali, che si contrappongono tradizionalmente ai codificanti.

nrk985

28-08-2007, 12:30

PGI-Bis

28-08-2007, 13:35

Non bene, benissimo :).

k0nt3

28-08-2007, 13:56

swing un punto di riferimento? siete messi bene...
fa che raccolga un po delle stranezze e storture che ho visto in questi mesi di swing...
ah beh.. invece quelli che hanno progettato le API di .NET sono dei geni vero? per cambiare la larghezza di una colonna in un DataGrid bisogna:
1 - creare un nuovo DataGridTableStyle
2 - creare un nuovo DataGridColumnStyle
3 - modificare il campo Width nel DataGridColumnStyle
4 - aggiungere il DataGridColumnStyle agli stili delle colonne del DataGridTableStyle
5 - aggiungere il DataGridTableStyle agli stili del DataGrid

(e ricordando che se è necessario riprendere gli stili per modificarli di nuovo a runtime bisogna pure dare un nome agli stili! sennò col piffero che sai quale pescare dall'array :fagiano: )

:cry: io volevo solo cambiare la larghezza di una colonna :cry:

cdimauro

28-08-2007, 14:03

ah beh.. invece quelli che hanno progettato le API di .NET sono dei geni vero? per cambiare la larghezza di una colonna in un DataGrid bisogna:
1 - creare un nuovo DataGridTableStyle
2 - creare un nuovo DataGridColumnStyle
3 - modificare il campo Width nel DataGridColumnStyle
4 - aggiungere il DataGridColumnStyle agli stili delle colonne del DataGridTableStyle
5 - aggiungere il DataGridTableStyle agli stili del DataGrid

(e ricordando che se è necessario riprendere gli stili per modificarli di nuovo a runtime bisogna pure dare un nome agli stili! sennò col piffero che sai quale pescare dall'array :fagiano: )

:cry: io volevo solo cambiare la larghezza di una colonna :cry:
:eek: :eek: :eek:

Non posso credere che sia opera della stessa mente che ha creato il Turbo Pascal prima e Delphi poi. :muro:

^TiGeRShArK^

28-08-2007, 14:04

nrk985

28-08-2007, 14:25

Non bene, benissimo :).
si, a cominciare dal fatto che swing, per essere progettata da zero, sermbra un accrocchio con mille cose inutili tenute solo per mantenere la compatibilità indietro.

oppure il mischione di componenti awt e swing con gli ultimi che overlappano i primi dovunque li piazzi, e sei costertto a usarli perchè alcuni non ci sono per swing

oppure il fatto che è singolo-thread (ridicolo), ma se poi effettivamente chiami i metodi di un componente da un altro thread non si lamenta, o almeno non mi è mai capitato

oppure gli artefatti che escono non appena ti spingi fuori dal suo uso normale, come ad esempio jtextfield che spuntano a random davanti agli altri componenti, come i jpanel, che sono messi in uno z-index inferiore e quindi piu prioritario... e se nn spuntano fuori (tutto a random, ovviamente), allora spunta fuori il cursore lampeggiante quando spingi TAB, un casino insomma.

oppure i componeti inseriti nei jscrollpane che sbordano tranquillamente dai bordi, fottono il layout, e provocano incasinamenti grafici non da poco.

oppure il fatto che i metodi sono overloadati in modo incompleto, i.e. per visualizzare un Joptionpane c'è il costruttore che mi prende un component, al chè io posso passargli il mio root pane dell'applet... e invece per visualizzare un Jdialog modale, che concettualmente è simile se non identico a un joptionpane, i costruttore vuole un dialog, un frame, o un window... e tu che fai? ti tocca cercare in internet e sperare di trovare il tipo che s'è già smazzato su ste pu@@a#ate progettuali.

oppure, cosa che da sola giustifica il fatto di non usare swing, il fatto che usi ancora i layout. essi sono inutili, complicati, inadeguati, retrogradi, difficili e, non meno importante, evidentemente progettati per chi disegna i form via codice, pratica che a metà 2007, se permetti, è ormai sconsigliabile tranne ai wanna-be hardcore di java (poveri loro, si fanno tanto male)... infatti sono assolutamente a favore dell'uso del designer di netbeans che trovo più che adeguato, e nel quale i layout servono a ben poco.

senza contare le solite scemenze Java di dare dei nomi improbabili a tutte le proprietà di un oggetto, tanto per incentivare la già proverbiale facilità di programmazione :asd: ... es. per posizionare un oggetto cosa usi? setposition? setlocation? setXY? no.... setbounds..... SETBOUNDS!!

Tutto questo è semplicemente RIDICOLO e trovi come niente su google esperienze di persone che, pur apprezzando java per ilr resto, odiano swing come la morte

nrk985

28-08-2007, 14:27

ah beh.. invece quelli che hanno progettato le API di .NET sono dei geni vero? per cambiare la larghezza di una colonna in un DataGrid bisogna:
1 - creare un nuovo DataGridTableStyle
2 - creare un nuovo DataGridColumnStyle
3 - modificare il campo Width nel DataGridColumnStyle
4 - aggiungere il DataGridColumnStyle agli stili delle colonne del DataGridTableStyle
5 - aggiungere il DataGridTableStyle agli stili del DataGrid

(e ricordando che se è necessario riprendere gli stili per modificarli di nuovo a runtime bisogna pure dare un nome agli stili! sennò col piffero che sai quale pescare dall'array :fagiano: )

:cry: io volevo solo cambiare la larghezza di una colonna :cry:
oh beh, mi paragoni uno specifico aspetto dell'ado.net o quel che è, che potrebbe anche essere implementato male, con l'INTERA API PER L'UI DI JAVA ...
swing poi è solo la punta dell'iceberg.
basti cercare tutti i Factory che ci sono nell'api, quelli si che sono già dal nome giri di parole (e di oggetti) inutili.

PGI-Bis

28-08-2007, 14:31

variabilepippo

28-08-2007, 14:36

Non posso credere che sia opera della stessa mente che ha creato il Turbo Pascal prima e Delphi poi.

IMHO a distanza di oltre 10 anni la VCL resta un esempio di ottimo design, eleganza, potenza e produttività. Ho visto portare in .NET una (semplice) applicazione a 16 bit sviluppata nel '96 (quando Win32 muoveva i primi, stentati, passi) con la VCL di Delphi1 grazie ad una banale compilazione! :eek:

cionci

28-08-2007, 14:42

Non è limitato a Swing il mio interesse verso la presenza di una piattaforma desktop su un dispositivo wireless. E' una questione di unificazione del variegato mondo dei PDA, cellulari, smartphone eccetera. Così come Java SE è il minimo comune denominatore di Windows, Linux, Solaris, OsX, BSD, OS/2 eccetera, così potrebbe essere per PalmOS, WindowsCE, QNX eccetera. Al momento è una possibilità. Sarebbe una gioia se diventasse attualità.
Purtroppo fino a quando non uniformeranno il framework sarà impossibile. J2ME non solo è un subset di J2SE, ma è anche uno "schifoset" di J2SE. Il linguaggio è praticamente rimasto fermo alla versione 1.1 e il framework è incomprensibilmente diverso.
Con la potenza di calcolo dei dispositivi PocketPC non ci vorrebbe niente ad implementare una vera VM. Spero che prima o poi si decidano.

cdimauro

28-08-2007, 14:54

IMHO a distanza di oltre 10 anni la VCL resta un esempio di ottimo design, eleganza, potenza e produttività.
Perfettamente d'accordo (e la VCL esiste anche per Linux, tra l'altro).
Ho visto portare in .NET una (semplice) applicazione a 16 bit sviluppata nel '96 (quando Win32 muoveva i primi, stentati, passi) con la VCL di Delphi1 grazie ad una banale compilazione! :eek:
E' la prima cosa che ho provato quando è arrivato Delphi .NET: a dir poco fenomenale! :)

k0nt3

28-08-2007, 14:57

oh beh, mi paragoni uno specifico aspetto dell'ado.net o quel che è, che potrebbe anche essere implementato male, con l'INTERA API PER L'UI DI JAVA ...
swing poi è solo la punta dell'iceberg.
basti cercare tutti i Factory che ci sono nell'api, quelli si che sono già dal nome giri di parole (e di oggetti) inutili.
non so cosa ci azzecchi ado e comunque sia ti consiglio un corso accelerato su SWING (è facile dire che qualcosa che non si sa usare è progettato male)

ps. e anche uno sui design patterns
oppure, cosa che da sola giustifica il fatto di non usare swing, il fatto che usi ancora i layout. essi sono inutili, complicati, inadeguati, retrogradi, difficili e, non meno importante, evidentemente progettati per chi disegna i form via codice, pratica che a metà 2007, se permetti, è ormai sconsigliabile tranne ai wanna-be hardcore di java (poveri loro, si fanno tanto male)... infatti sono assolutamente a favore dell'uso del designer di netbeans che trovo più che adeguato, e nel quale i layout servono a ben poco.
qua ci sta un sondaggione: visuali vs. codificanti
per quanto mi riguarda una volta che ho trascinato gli oggetti che mi servono nel form il designer lo posso buttare nel cesso :D

senza contare le solite scemenze Java di dare dei nomi improbabili a tutte le proprietà di un oggetto, tanto per incentivare la già proverbiale facilità di programmazione ... es. per posizionare un oggetto cosa usi? setposition? setlocation? setXY? no.... setbounds..... SETBOUNDS!!
seBounds imposta sia la posizione che la dimensione contemporaneamente, mentre setLocation imposta solo la posizione e setSize imposta solo la dimensione
niente di più logico

PGI-Bis

28-08-2007, 14:59

Come ogni cosa, per usare Swing bisogna conoscerlo. Artefatti, problemi di concorrenza, combinazione di componenti AWT e Swing, sforamenti... sono tutte questioni che denotano una conoscenza imprecisa del framework.

Ci sono alcuni aspetti convenzionali che potrebbero essere eliminati ma Sun ha sempre giudicato con smodata attenzione la retrocompatibilità.

Non so se sia possibile forzare il rispetto dell'architettura a Thread singolo. A naso direi di no.

La programmazione di una GUI è un'attività diversa dalla sua progettazione. E' un'attività banalmente mimetica: hai delle bozze, prodotte da dei grafici, e le ripeti in codice.

In qualità di codificante, la mia opinione personale e fu professionale, è che il GUI Editor lo usi franceschino dalle bande nere quando vuole fare il programma per suo cognato. Almeno finchè non avremo un editor di GUI che dia la stessa libertà di un Photoshop. I layout manager servono a catturare la distribuzione proporzionale degli spazi che è la chiave di interpretazione di quelle bozze. La catturano e la mantengono su sistemi che hanno sensibili differenze nelle dimensioni dei dettagli.

Non è solo Swing ad usarli. Ad esempio li ha Morph. Credo che li abbia anche Wx ma non sono sicurissimo.

variabilepippo

28-08-2007, 15:03

la VCL esiste anche per Linux, tra l'altro

Senza dimenticare che esiste anche per PHP (http://www.qadram.com/vcl4php/) e per C++! :D

E' la prima cosa che ho provato quando è arrivato Delphi .NET: a dir poco fenomenale!

Purtroppo un prodotto tecnologicamente superiore rispetto a gran parte dei concorrenti sta scomparendo in una lenta agonia... :cry:

cdimauro

28-08-2007, 15:23

Senza dimenticare che esiste anche per PHP (http://www.qadram.com/vcl4php/)
L'ho provata con Delphi for PHP, ma onestamente mi sembra acerba (ad esempio non c'è stato verso di creare un componente che derivasse da CustomGrid).
e per C++! :D
Mumble. Sicuro? Io ricordo che CBuilder utilizzava la versione Delphi della VCL.
Purtroppo un prodotto tecnologicamente superiore rispetto a gran parte dei concorrenti sta scomparendo in una lenta agonia... :cry:
Pensavo anch'io così, ma da quando CodeGear ha rilasciato le versioni Turbo, noto nuovamente un po' d'interesse.

Turbo Delphi 2006 è un ottimo prodotto, sebbene con alcune limitazioni.

Poi in questo periodo sto smanettando con Python for Delphi e mi sto trovando molto bene. Un nuovo modo per realizzare applicazioni dotate di GUI. ;)

bist

28-08-2007, 15:37

Infatti ho visto in quel link che si occupa della gestione della memoria, del GC, ecc.

La questione è se è possibile integrare queste funzionalità in maniera trasparente in un'applicazione completamente nativa. Ho visto che ci sono un po' i produttori che offrono la possibilità di realizzare applicazioni .NET standalone, e alcuni dicono che integrano alcune librerie minimali del CLR, altri affermano che il CLR e la VM ci sono, ecc. Un vero casino, e non si capisce effettivamente cosa sia possibile fare.

Scusa la domanda stupida, ma che senso avrebbe levare il livello framework e integrarne le funzionalità nel livello dell'applicazione? :) Mi sembra tanto lavoro per nulla, anzi sarebbe nocivo.

ah beh.. invece quelli che hanno progettato le API di .NET sono dei geni vero? per cambiare la larghezza di una colonna in un DataGrid bisogna:
1 - creare un nuovo DataGridTableStyle
2 - creare un nuovo DataGridColumnStyle
3 - modificare il campo Width nel DataGridColumnStyle
4 - aggiungere il DataGridColumnStyle agli stili delle colonne del DataGridTableStyle
5 - aggiungere il DataGridTableStyle agli stili del DataGrid

(e ricordando che se è necessario riprendere gli stili per modificarli di nuovo a runtime bisogna pure dare un nome agli stili! sennò col piffero che sai quale pescare dall'array :fagiano: )

:cry: io volevo solo cambiare la larghezza di una colonna :cry:

1) perché usi DataGrid invece di DataGridView
2) al di là di questo esempio specifico le API grafiche di .NET secondo me sono molto buone, e pure il designer di Visual Studio è una figata

variabilepippo

28-08-2007, 15:43

L'ho provata con Delphi for PHP, ma onestamente mi sembra acerba

E' molto acerba, ad onor del vero Delphi4PHP e annessi vari sono stati acquistati da una società indipendente e "brandizzati" CodeGear.

Sicuro? Io ricordo che CBuilder utilizzava la versione Delphi della VCL.

Sono stato poco preciso nell'esposizione, con "per C++" intendevo "utilizzabile da chi programma in C++".

Pensavo anch'io così, ma da quando CodeGear ha rilasciato le versioni Turbo, noto nuovamente un po' d'interesse.

Purtroppo molti programmatori Delphi (e non eravamo poi in tantissimi) hanno preferito abbandonare la nave che affondava passando a C#. Tanti progetti Delphi sono stati abbandonati, sospesi o portati in altri linguaggi. :muro:

E' un peccato, perché Delphi aveva 10 anni fa caratteristiche (la VCL su tutte) che altri RAD faticano ad offrire oggi.

variabilepippo

28-08-2007, 15:50

io volevo solo cambiare la larghezza di una colonna

Io utilizzerei un DataGridView.

DataGrid1.TableStyles("Employees").GridColumnStyles("Title").Width = newwidth non funziona?

Tanti anni fa in Delphi era possibile farlo con un intuitivo:

DBGrid.Columns[indiceColonna].Width := Larghezza; :D

AngeL)

28-08-2007, 15:51

Papero, non gallo. :D

Giovanni Gallo c'è finito in mezzo quando s'è disquisito di estensioni dei linguaggi e relativo zucchero sintattico. :p

non ci capisco piu' niente :asd:

k0nt3

28-08-2007, 16:09

Io utilizzerei un DataGridView.

DataGrid1.TableStyles("Employees").GridColumnStyles("Title").Width = newwidth non funziona?

Tanti anni fa in Delphi era possibile farlo con un intuitivo:

DBGrid.Columns[indiceColonna].Width := Larghezza; :D
DataGridView non è ugualmente un gioiello, ma soprattutto io stavo usando il framework 1.1 e questo controllo ancora non esisteva (abbastanza ridicolo in effetti)
ovviamente è solo una delle tante cose che non mi piacciono dell'implementazione che hanno dato al framework (e questa non mi sembra la sede per parlarne approfonditamente), comunque sia in tutte le API che ho visto c'è qualcosa tipo DBGrid.Columns[indiceColonna].Width := Larghezza; non è questione di delphi o meno, ma di buon senso

variabilepippo

28-08-2007, 16:12

non è questione di delphi o meno, ma di buon senso

Concordo, ma era "quasi" una battuta per riallacciarmi ai messaggi precedenti. ;)

nrk985

28-08-2007, 16:54

Non so se sia possibile forzare il rispetto dell'architettura a Thread singolo. A naso direi di no.
in NET se lo fai, ti lancia un'eccezione

La programmazione di una GUI è un'attività diversa dalla sua progettazione. E' un'attività banalmente mimetica: hai delle bozze, prodotte da dei grafici, e le ripeti in codice.

In qualità di codificante, la mia opinione personale e fu professionale, è che il GUI Editor lo usi franceschino dalle bande nere quando vuole fare il programma per suo cognato. Almeno finchè non avremo un editor di GUI che dia la stessa libertà di un Photoshop. I layout manager servono a catturare la distribuzione proporzionale degli spazi che è la chiave di interpretazione di quelle bozze. La catturano e la mantengono su sistemi che hanno sensibili differenze nelle dimensioni dei dettagli.abbiamo capito che tipo di programmatore sei...
ma con questa mentalità non ci si pone bene nel confronto di chi deve imparare, ma anche con chi ne sa abbastanza di un altro linguaggio ma è da poco che fa i conti con java/swing.

PGI-Bis

28-08-2007, 17:37

Un'eccezione in compilazione o in esecuzione? Il primo caso sarebbe molto bello, il secondo non tanto.

Chi non sa impara, chi non sa bene impara meglio. Pian piano e un po' per volta. Non è che sia ingegneria nucleare: è un framework per creare interfacce grafiche.

mjordan

28-08-2007, 17:57

ah beh.. invece quelli che hanno progettato le API di .NET sono dei geni vero? per cambiare la larghezza di una colonna in un DataGrid bisogna:
1 - creare un nuovo DataGridTableStyle
2 - creare un nuovo DataGridColumnStyle
3 - modificare il campo Width nel DataGridColumnStyle
4 - aggiungere il DataGridColumnStyle agli stili delle colonne del DataGridTableStyle
5 - aggiungere il DataGridTableStyle agli stili del DataGrid

(e ricordando che se è necessario riprendere gli stili per modificarli di nuovo a runtime bisogna pure dare un nome agli stili! sennò col piffero che sai quale pescare dall'array :fagiano: )

:cry: io volevo solo cambiare la larghezza di una colonna :cry:

Mi viene da pensare che programmare in C/GTK+ non sia piu' ormai tanto piu' macchinoso che usare i nuovissimi produttivi framework... :stordita:

mjordan

28-08-2007, 18:01

Purtroppo fino a quando non uniformeranno il framework sarà impossibile. J2ME non solo è un subset di J2SE, ma è anche uno "schifoset" di J2SE. Il linguaggio è praticamente rimasto fermo alla versione 1.1 e il framework è incomprensibilmente diverso.
Con la potenza di calcolo dei dispositivi PocketPC non ci vorrebbe niente ad implementare una vera VM. Spero che prima o poi si decidano.

Questa purtroppo è una triste verità. Difatti non ancora mi spiego perchè, a dispetto dell'incredibile evoluzione che le API abbiano avuto negli ultimi anni, non si siano decisi ad implementare qualche elemento del linguaggio in piu'...
In fondo in fondo ormai anche i cellulari non smartphone sono arrivati a frequenze dell'ordine dei 500Mhz (parlo dei modelli basati su ARM11, come ad esempio il Motorola V8 "RAZR²).

Conclusione: :muro: :muro:

marco.r

28-08-2007, 18:50

Mi viene da pensare che programmare in C/GTK+ non sia piu' ormai tanto piu' macchinoso che usare i nuovissimi produttivi framework... :stordita:
Non ti allargare adesso, che dalle mie parti hanno giusto attivato un corso per imparare a usare le TreeView... :D

cdimauro

28-08-2007, 20:18

Scusa la domanda stupida, ma che senso avrebbe levare il livello framework e integrarne le funzionalità nel livello dell'applicazione? :) Mi sembra tanto lavoro per nulla, anzi sarebbe nocivo.
L'idea era quella di ottenere un eseguibile nativo senza portarsi dietro il framework, se non per le librerie strettamente necessarie (anch'esse compilate nativamente).

Non ho capito bene perché sarebbe nacivo.

k0nt3

28-08-2007, 20:21

L'idea era quella di ottenere un eseguibile nativo senza portarsi dietro il framework, se non per le librerie strettamente necessarie (anch'esse compilate nativamente).

Non ho capito bene perché sarebbe nacivo.
perchè il codice managed per definizione deve girare in un ambiente protetto e sotto controllo :)

cdimauro

28-08-2007, 20:23

E' molto acerba, ad onor del vero Delphi4PHP e annessi vari sono stati acquistati da una società indipendente e "brandizzati" CodeGear.
Sì, l'avevo letto. L'idea è molto interessante, ma se non sistemano tutti i bug dubito si possa prendere in considerazione per sviluppare qualcosa da mandare in produzione.
Sono stato poco preciso nell'esposizione, con "per C++" intendevo "utilizzabile da chi programma in C++".
OK :)
Purtroppo molti programmatori Delphi (e non eravamo poi in tantissimi) hanno preferito abbandonare la nave che affondava passando a C#. Tanti progetti Delphi sono stati abbandonati, sospesi o portati in altri linguaggi. :muro:
E' stata anche colpa di Borland che non ha aggiornato adeguatamente il linguaggio, il compilatore (dov'è il supporto x64?) e la VCL.
E' un peccato, perché Delphi aveva 10 anni fa caratteristiche (la VCL su tutte) che altri RAD faticano ad offrire oggi.
Già. Ed è proprio per questo che continuo a svilupparci quando capita, seppur usando soluzioni come quelle descritte prima (con Python).

Comunque qualche novità interessante al linguaggio è arrivata (penso agli iteratori e alla possibilità di definire tipi e costanti all'interno di una classe, ad esempio, che aspettavo da tempo), e spero che ne arrivino altre.

cdimauro

28-08-2007, 20:24

perchè il codice managed per definizione deve girare in un ambiente protetto e sotto controllo :)
E per far questo è indispensabile far girare il tutto dentro una VM?

cdimauro

28-08-2007, 20:26

DataGridView non è ugualmente un gioiello, ma soprattutto io stavo usando il framework 1.1 e questo controllo ancora non esisteva (abbastanza ridicolo in effetti)
ovviamente è solo una delle tante cose che non mi piacciono dell'implementazione che hanno dato al framework (e questa non mi sembra la sede per parlarne approfonditamente), comunque sia in tutte le API che ho visto c'è qualcosa tipo DBGrid.Columns[indiceColonna].Width := Larghezza; non è questione di delphi o meno, ma di buon senso
Appunto per questo continuo a non capire il perché di scelte così scomode e distanti da quelle già realizzate con Delphi: eppure l'architetto è lo stesso!

Mah. :muro:

cdimauro

28-08-2007, 20:29

Questa purtroppo è una triste verità. Difatti non ancora mi spiego perchè, a dispetto dell'incredibile evoluzione che le API abbiano avuto negli ultimi anni, non si siano decisi ad implementare qualche elemento del linguaggio in piu'...
In fondo in fondo ormai anche i cellulari non smartphone sono arrivati a frequenze dell'ordine dei 500Mhz (parlo dei modelli basati su ARM11, come ad esempio il Motorola V8 "RAZR²).

Conclusione: :muro: :muro:
Beh, 500Mhz e ARM11 mi sembrano caratteristiche non di poco conto (suppongo che l'ARM abbia anche l'estensione Jazilla): non penso che quel miliardo di parco macchine installato di cui parlavi prima possa vantarne di simili (magari!!!).

Comunque di recente ho preso (di seconda mano) uno Zaurus SL-5500 con StrongARM a 200Mhz, e debbo dire che mi va discretamente bene. Devo ancora provare Java (sto impazzendo con la distro Linux modificata che ho installato al posto di quella nativa), ma spero di poterci smanettare al più presto.

bist

28-08-2007, 20:31

L'idea era quella di ottenere un eseguibile nativo senza portarsi dietro il framework, se non per le librerie strettamente necessarie (anch'esse compilate nativamente).

Credo che così si risparmi solo spazio su disco. O almeno, mi auguro che il framework carichi dinamicamente solo le librerie/classi che sono effettivamente usate.

Non ho capito bene perché sarebbe nacivo.

Per esempio per gli aggiornamenti, molto più comodo aggiornare uno strato condiviso che le librerie di ogni singola applicazione.

cdimauro

28-08-2007, 21:15

Credo che così si risparmi solo spazio su disco. O almeno, mi auguro che il framework carichi dinamicamente solo le librerie/classi che sono effettivamente usate.
Se non sbaglio alcuni tool che compilano nativamente un'applicazione .NET controllano le classi utilizzate e compilano solo quelle (suppongo staticamente a questo punto).
Per esempio per gli aggiornamenti, molto più comodo aggiornare uno strato condiviso che le librerie di ogni singola applicazione.
Sicuramente, ma a volte è preferibile avere lo stesso set di librerie perché (e capita, purtroppo) con quelle più aggiornate ci possono essere dei problemi (comunque Vista ha un meccanismo che tiene traccia delle versioni di librerie necessarie per una certa applicazione e le carica in maniera trasparente; quindi possono esistere più versioni delle stesse, e ci pensa lui a "sbrogliare la matassa").

A parte il problema degli aggiornamenti (che è sempre importante, eh!), non vedo però altri particolari "nocivi".

bist

28-08-2007, 21:26

Se non sbaglio alcuni tool che compilano nativamente un'applicazione .NET controllano le classi utilizzate e compilano solo quelle (suppongo staticamente a questo punto).

E' più vantaggioso averle a disposizione tutte e caricare quelle che servono dinamicamente (ammesso che il .NET faccia così, lo spero!).

Sicuramente, ma a volte è preferibile avere lo stesso set di librerie perché (e capita, purtroppo) con quelle più aggiornate ci possono essere dei problemi (comunque Vista ha un meccanismo che tiene traccia delle versioni di librerie necessarie per una certa applicazione e le carica in maniera trasparente; quindi possono esistere più versioni delle stesse, e ci pensa lui a "sbrogliare la matassa").

A parte il problema degli aggiornamenti (che è sempre importante, eh!), non vedo però altri particolari "nocivi".

Il meccanismo per le diverse versioni delle librerie che citi è anche implementato dal .NET Framework (quindi anche su XP stai in teoria tranquillo per i casini con le dll, a patto appunto di utilizzare .NET). Che fosse adottato direttamente dall'OS con Vista non lo sapevo e mi fa molto piacere (se ho capito bene, sono un po' fuso adesso).