Newsgroup: it.comp.java
Titolo: ma java ci è o ci sarà?

Ciao a tutti, sono un giovane studente di ingegneria informatica.
Il mio professore sostiene che java sia un linguaggio poco evoluto e 
raffazzonato. Sostiene che il suo successo sia dovuto a una bolla 
momentanea destinata a sgonfiarsi, che in questo momento sia meglio 
puntare sul clos e sul c++, il primo per la sua grande espressività, il 
secondo per la sua maggiore velocità.
Cosa ne pensate?

antonio ha scritto:

Caro Antonio,
ovviamente ognununo è libero di esprimere la propria opinione, e come si può ben 
immaginare la ragione non è mai da una parte sola, ma ognununo alla fine deve 
essere capace di prendere le proprie scelte.
Molti dei professionisti che orbitano attorno a questo NG non sono figli 
unicamente di java, anzi, come tanti ti potranno affermare, la capacità di un 
vero "ingegnere informatico" non sta solo nella conoscenza di java, ma in tutta 
una serie di linguaggi e stili di programmazione che vengono correntemente usati 
per raggiungere dati obbiettivi.
Ogni linguaggio di programmazione è idoneo per una parte delle soluzioni 
ottenibili, e quindi, a maggior ragione, la scelta di come raggiungere un dato 
obbiettivo sarà condizionata anche dal linguaggio di programmazione scelto.
Ad esempio, per ora, non è un ottima idea realizzare il motore grafico 3D di un 
videogames utilizzando java, poichè le prestazioni sono inferiori del C++, ma 
d'altra parte ci sono soluzioni, come le webapps, thinclient, reti neurali, che 
richiederebbero fin troppo lavoro e difficoltà per essere realizzate in C++! :D
Come al solito,
quello che dicono i docenti non va preso come se fosse un DOGMA, anzi...il più 
delle volte è il dubbio che ti salva! :D
Ciao,
jRed

antonio confermo al 100% quel che ha detto jRed...
Nel mio caso particolare ho iniziato a prog in c++ è ora uso quasi
sempre java... ma solo perchè sono le applicazioni stesse che me lo
chiedono...
Credo che ogni prog prima di scrivere il codice di qualsiasi appl
dovrebbe chiedersi qual'è il mmigliore per farlo, il c++ è l'ideale
se devi scivere un pezzo di OS efficente e veloce ma non lo è per
tutte... Percio ti consiglio di provare più linguaggi anche
semplicemente raccogliendo della doc, alla fine saprai da solo e senza
che nessuno te lo abbia imposto qual'è il ling giusto per il tuo prog
ciao


Definire una bolla momentanea una cosa che non ha fatto che crescere 
negli ultimi 10 anni è alquanto azzardato, almeno nel settore informatico.
Non vorrei che questo professore basi le sue affermazioni su argomenti 
decisamente vecchi.
Andrea

 ha scritto nel messaggio 
news:4392fdac$0$337$5fc...@news.tiscali.it...

Ogni linguaggio di una certa fama ha i suoi punti di forza e punti deboli.
Certamente se la velocita' di esecuzione di un programma e' essenziale 
(quindi si parla di appliczione a basso livello), javaA non e' il massimo e 
c++ brilla.
Laddove invece la mantenibilita' del codice, semplicita' di utilizzo, 
facilita' a integrare librerie ecc e' fortemente richiesta allora java e' un 
passo avanti rispetto al c++.
Pensiamo alla reflaction ad esempio, caratteristica mancante al c++. 
Chiamare un metodo tramite reflaction non e' certo il modo piu' performante 
per farlo (anche se con il tempo le prestazioni sono sempre migliori), 
tuttavia vuoi mettere i benefici che porta a livello delle caratteristiche 
descritte sopra?!

 secondo per la sua maggiore velocità.
E poi basta con 'sta storia che Java è lento! ERA lento, prova a 
scaricarti la 1.6.0 beta e lancia la demo delle Swing!
Sono anni che lavorano per migliorare l'efficienza (hotspot, ecc. ecc.) 
e ancora la prima cosa che si sente dire di Java è che "è lento".
bye e benvenuto in Java, in ogni caso
DKano

 DKano
Non lo so...NetBeans 5 continua ad essere un mattone spaventoso anche per un 
centrino 1600. 

antonio ha scritto:

Che si tratta di uno strano miscuglio di affermazioni pragmatiche e
accademiche, nel complesso una fesseria.
Java non è perfetto, ne dal punto di vista formale che architetturale.
Tralascio i discorsi sul successo e le previsioni di sgonfiamento non
essendo la preveggenza il mio campo, ma se  arriva a suggerire di
"puntare" sul C++ in alternativa al Java penso che debba fornire
qualche altro chiarimento. E' noto a chi lavora che in molti settori
dove Java è utilizzato il C++ è l'ultima delle alternative. Inoltre,
questa cultura di "puntare" su un linguaggio a priori senza neanche
sapere in che settore si andrà a lavorare lo trovo particolarmente
poco serio.

 bye e benvenuto in Java, in ogni caso
Francamente mi aspettavo più commenti come questo, da tifoso. Se ne 
trovano purtroppo tanti nei forum di linux, ma non penso che serva a 
qualcosa negare l'evidenza. Credo che qualsiasi cosa abbia i suoi punti 
deboli, e il più evidente, ma non l'unico, di java, è la lentezza. In 
questo campo non si può che migliorare, e chi ha provato un ambiente 
smalltalk, uno dei padri di java e vero pioniere tra le altre cose della 
virtual machine, sa quanto java sia ancora indietro da questo punto di 
vista.
ciao a tutti

 deboli, e il più evidente, ma non l'unico, di java, è la lentezza.
Come abbiamo gia' detto, java e' piu' lenta ma non di molto e in molti campi 
questo non e' assolutamente un problema. 

 Francamente mi aspettavo più commenti come questo, da tifoso. Se ne 
Si ma, ripeto, non se ne può più. Una cosa è dire che si può migliorare,
che sono stati fatti passi avanti ecc. Un'altra è bollare Java come
"lento" qualunque cosa accada...
bye
DKano

 questo non e' assolutamente un problema. 
vero che a volte non è un problema, contestavo solo la negazione 
dell'evidenza

 fare l'equivalente di una jsp?
Una persona con un minimo di intelligenza non proporrebbe mai qualcosa 
del genere a un suo allievo. Clos non lo conosco, ha i suoi estimatori 
nell'intelligenza artificiale, e c'è veramente un professore che ogni 
tanto ci dice che è il miglior linguaggio a oggetti che esiste ;-)


 tanto ci dice che è il miglior linguaggio a oggetti che esiste ;-)
Un giorno uno strano omino disse: "640k should be enough for anybody."
Evidentemente si sbagliava! ;)
Ciao,
jRed

 del genere a un suo allievo. 
Ovviamente no, ma sei stato tu a citare "clos e C++" come alternative a 
Java.
bye
DKano

 Un giorno uno strano omino disse: "640k should be enough for anybody."
Si, ogni tanto, mentre cerco l'ennesima espansione di memoria per un pc, 
me lo sento risuonare in testa :-)
bye
DKano

 vista.
Le VM di nuova generazione sono decisamente più performanti di quelle
Smalltalk. Che sia stato il pioniere va bene, ma non esageriamo
La comunità oggi si sta chiedendo cosa verrà dopo Java, the next big
thing, e per ora non c'è una risposta. L'ideale sarebbe un linguaggio
altamente dinamico come Ruby, magari che giri sopra una nuova super VM e
con tutto il supporto del bytecode esistente. BTW, se ti interessano
questo argomenti, ti consiglio di leggerti "Beyond Java"
ciao e buona tesi
uL
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

Secondo me la si sta complicando molto:
Un programma può
a) essere gestionale (comprese le web application)
b) gestire hardware - mandare i missili sulla luna
Nel caso a) Java è sicuramente il linguaggio più robusto e più
supportato a livello di librerie
Nel caso b) Java è totalmente inutile.
Il caso a) ricopre il 90% delle applicazioni informatiche
Il caso b) ricopre il 90% delle lezioni universitarie.

 a) essere gestionale (comprese le web application)
Ammetterai che già questo è un minestrone esagerato. Comprendi non so
quante architetture completamente diverse fra loro. Difficile dire che
java sia più robusto, ad esempio, di un applicativo client-server
nativo windows che gira su windows.
Le valutazioni vanno fatte, a mio modesto avviso, cum grano salis e non
a priori senza avere sottomano la natura del problema. Se poi ciò
complica molto come dici tu... beh, nessuno ha detto che è semplice.

 complica molto come dici tu... beh, nessuno ha detto che è semplice.
Concordo, ma qui non c'era un problema da esaminare, semmai
un'affermazione. Io ho solo dato una possibile spiegazione...

Il caso b) ricopre il 90% delle lezioni universitarie.
Forse queste percentuali sono esagerate (parlo sptt della (a)), ma
rendono bene l'idea del distacco che esiste tra il mondo accademico e
il mondo reale.
E' perfettamente inutile che all'università si insegni clos (o coma
cavolo si chiama - ai miei tempi c'erano Eiffel e Ada) quando poi
nessuno lo usa al di fuori del mondo accademico...
Oggi alle aziende che fanno gestionali (il 90%) servono programmatori
Java o .NET (aggiungo anche RPG e Cobol)...
Ci sono poi gli ambiti di nicchia come Perl, Php, e ormai anche il C++.
Quindi escludendo che sia sensato insegnare ancora il Cobol o l'RPG
(tanto ci sono eserciti di programmatori con tanto skill e poco
lavoro), l'università dovrebbe insegnare Java o C#... dal mio punto di
vista non fa molta differenza tra l'uno e l'altro: Java è più maturo
e con più librerie/framework disponibili; C# è più completo e meglio
strutturato come linguaggio in sè.

 lavoro), l'università dovrebbe insegnare Java o C#... dal mio punto di
O tutte e due? Oppure la teoria della programmazione ad oggetti prima e 
poi i linguaggi, magari. A parte la preferenza personale per Java 
rispetto a qualunque windoz-cosa, sempre meglio avere più informazioni, 
no? Seguendo la logica "mi preparo per il lavoro", così facendo si 
lasciano più possibilità
bye
DKano

lasciano più possibilità
Diamo per scontato che prima di insegnare un linguaggio OO vengano
insegnati anche i principi dell'OO.
Certo è ovvio che più cose si imparano all'università meglio è.
Ed è altrettanto ovvio che personalmente preferisco se insegnano Java
rispetto a C#.
Ma il punto è: preferisco qualcuno che non conosce niente di Java ma
conosce C#, piuttosto di un che conosce perfettamente clos e poi non sa
da che parte cominciare per scrivere due pagine web che presentano
informazioni lette da un database :)

 informazioni lette da un database :)
Ma come non lo sa, con due istruzioni clos, no? :-)
bye
DKano
PS Non ho nulla contro il povero clos, manco lo conosco...

 centrino 1600. 
È la RAM, imho. Quanta ne hai?
-- 
non vincono, non vinceranno, non hanno domani
la forza è nel puntello impugnato da oneste fortissime mani

 campi questo non e' assolutamente un problema.
Poi anche li bisogna vedere... lanciare e catturare un'eccezione in Java
è per esempio fino a 4 volte più veloce che farlo in C++ (su
un'eccezione standart, tipo un IndexOutOfBound un paio di volte più
veloce). Comunque ad onor del vero un'approccio LBYL risulta ordini di
grandezza più performante in ogni caso :)
Oppure possiamo pensare al crivello di Eratostene. Nel libro di
Horstmann/Cornell viene mostrato come l'implementazione di Java da loro
proposta sia pià veloce (anche se non di molto) di molte (qui non si
capisce quale sia il termine di confronto) C++. Il che è comunque un bel
risultato.


 dell'evidenza
Io direi "nella maggior parte dei casi non è un problema".


 tanto ci dice che è il miglior linguaggio a oggetti che esiste ;-)
Questolo ho sentito dire per quasi tutti i linguaggi ad oggetti più o
meno storici.
Per alcuni è clos. Per altri è OCaml, per altri è Python, per altri
Ruby, per altri Smalltalk, per non parlare di Eifell. E così via. 


 si ritrova a girare su una macchina virtuale,
IMHO il fatto non è questo. Ho usato spesso interfacce grafiche in
linguaggi interpretati (prima in Perl, poi in Python). E nessuno era
sostanzialmente lento.
Anzi, il consiglio generale è proprio quello di fare le gui in un
linguaggio più di alto livello possibile (mi pare Raskin stesso lo
avesse suggerito).
Sinceramente non conosco abbastanza gli internals di Java (anche perchè
io lo uso specialmente su MacOS X, dove la responsabilità di ogni
lentezza può benissimo essere della libreria fatta da Apple), ma ho
alcune idee sul perchè potrebbe essere lenta. E le idee portano verso
come è scritto Swing, non verso Java (per esempio facendo
un'applicazione Java con gui Cocoa non vedo differenze significative con
una con GUI ObjectiveC + Cocoa).
Una prima cosa che mi può venire in mente è che l'approccio molto pulito
di avere la maggior parte dei controlli con MVC puro possa in qualche
modo introdurre un overhead. 
L'altro è che Swing è costruito su AWT, che è costruito sulle primitive.
Quindi due livelli di indirezione almeno, laddove, per esempio, QT è
costruito direttamente sulle primitive (e in effetti un'applicazione QT
è leggermente più pesante di una che usa direttamente Carbon, su MacOS).
Ma in questo non sono particolarmente esperto, il mio è più uno spunto
per avere una risposta che un parere effettivo :)


 completa ed abbastanza esaustiva).
Devi tenere in considerazione anche gli strumenti che accompagnano 
l'ambiente.
Non conosco la soluzione da te proposta, ma dubito che si possano utilizzare 
framework (sempre che ne esistano) della potenza di quelli sviluppati sopra 
java. 

 linguaggi piů eleganti.
Semplicemente non saresti altrettanto produttivo. E' questo quello che 
conta. 


500m!
non dirmi che e' poca! 


Comunque non intendo che non gira.
Capita pero' che si pianta e devi aspettare 30 secondi solo perch'e hai 
selezionato una riga di testo.
Questo puo' essere veramente irritante ;) 

 Ma come non lo sa, con due istruzioni clos, no? :-)
Buona, questa :-)
Scorpio.


 selezionato una riga di testo.
Uhm, talvolta capita anche a me. Io ne ho 512 MB. Ad ogni buon conto
ribadisco, non credo che sia determinante il processore. Entro certi
limiti.
-- 
non vincono, non vinceranno, non hanno domani
la forza č nel puntello impugnato da oneste fortissime mani

 quelli sviluppati sopra java.
Forse me ne è sfuggito qualcuno, ma di framework più potenti di Twisted
non ne conosco. Specie per come scala. Comunque il mio era solo una
nota, parlare di Twisted qui oltre sarebbe solo OT.


 PS Non ho nulla contro il povero clos, manco lo conosco...
Tra l'altro č davvero un bell'oggetto. Purtroppo (o perfortuna) ha
alcune cose che lo rendono unico, quindi l'apprendimento non č
automatico.
Č uno di quegli affari che se uno li sa usare, gli fanno risparmiare
tempo a palate. Sfortunatamente (o fortunatamente) non si č diffuso
eccessivamente per varie ragioni, anche se č qualcosa di tutt'altro che
morto. Ha la sua nicchia e li prospera.
Č una di quelle cose che apprese "aprono la mente". Personalmente non ho
mai avuto tempo di apprenderlo. Le mie skills in Lisp sono troppo
elementari (e piů che altro dovute alla mia formazione teorica che ad
esperienza sul campo con tale linguaggio) per comprenderlo a pieno: il
manualozzo di Steele č li e attende.
-- 
non vincono, non vinceranno, non hanno domani
la forza č nel puntello impugnato da oneste fortissime mani

 trovarle incomplete...
Io credo che Java non sia mai stato solo un "linguaggio". È nato come
piattaforma. E credo che il "resto" della piattaforma (la libreria e la
macchina virtuale) siano le preponderanti cause del suo successo
[ assieme, come ho già detto, alla semplicità del linguaggio -- ma il
linguaggio non ha allontanato, più che avere avvicinato, imho ]
In effetti basti pensare che qui siamo su
it.comp.java, non su it.comp.lang.java
-- 
non vincono, non vinceranno, non hanno domani
la forza è nel puntello impugnato da oneste fortissime mani


Non parlo di cose che non consoco quindi puo' anche essere.
Ma per java abbiamo strumenti per ogni cosa e parecchio potenti.
Per esempio in un sito/applicazione web classico puoi usare
-persistenza: hibernate, ecc ecc (sono tanti)
-front-end: struts, tapestry, spring, jsf (forse il piu' potente), cocoon 
ecc (ce ne sono ancora molti)
-business object: spring (che io sappia)
-ti serve un motore di ricerca per il tuo sito? hai lucene
-vuoi aggiungere dei report in pdf? hai fop e altri ovviamente
..
Questo non e' certo solo merito del linguaggio ma anche della popolarita' 
raggiunta. 

 sicurezza che se sfruttate bene danno i loro frutti...
Quali sarebbero questi problemi?
Gestone della memoria? In C++ la gestisci a mano se non sai usare il 
linguaggio. Vogliamo parlare di come invece in C++ gestisci 
automaticamente *tutte* le risorse (memoria, appunto, compresa) mentre 
in Java *devi* gestirti a mano *tutte* le risorse tranne la sola memoria 
(l'unica gestita dal GC)?
Poi quale problema degli errori? Il C++ ha le eccezioni esattamente come 
Java.
Ciao.

 genere non amano java
Trovo giusto che i professori non si "innamorino" di un linguaggio: e' 
un errore che nessun programmatore dovrebbe fare. Detto questo non e' 
affatto vero che java abbia preso poco piede in ambito accademico: a 
Padova a Fondamenti di Informatica 1 e 2 si insegna Java e poi lo si usa 
nel 95% dei progetti.

 sono la Garbage Collection e la gestione delle Eccezioni.
La gestione delle eccezioni non manca certo nel C++.
Per quanto riguarda la GC, questa in realtà presenta aspetti 
controversi. E non sto affatto parlando di efficienza perché gli 
algoritmi attuali sono molto efficienti (a patto però spesso di un 
enorme spreco di memoria).
Il problema è che la GC rende semplice scrivere codice relativamente 
semplice e poco sicuro (da un punto di vista di gestione degli errori), 
mentre complica notevolmente la scrittura del codice in caso di codice 
complesso e con un'attenta, completa e corretta gestione degli errori 
(che ovviamente non è però necessaria in tutte le tipologie di 
applicativi). Questo perché si occupa di gestire la sola risorsa memoria 
(che non è certo l'unica con la quale si ha a che fare), rendendo 
*impossibile* la gestione automatica di *tutte* le risorse (memoria 
compresa) che approcci diversi possono avere. Per esempio l'uso corretto 
dell'idioma RAII in C++ ti evita di gestire "a mano" *qualunque* risorsa.
Questo significa che l'uso di un GC porta, nei casi sopra citati in cui 
serva una gestione degli errori seria, a scrivere codice più lungo, più 
prolisso, di manutenzione meno semplice, e più prono agli errori.
Certamente viene richiesto al programmatore C++ di saper scrivere codice 
in modo corretto, requisito più "rilassato" in linguaggi "più semplici" 
  (ma anche meno potenti) come Java.
Con questo non voglio dire che il C++ sia meglio da Java, però vorrei 
far notare come molte affermazioni date per assolute (tipo la GC rende 
più sicuro e semplice il codice) siano puramente propaganda, e non hanno 
nessuna valenza tecnica. In realtà, come detto sopra, ci sono casi un 
cui la GC semplifica la vita ed altri in cui la complica. Sta al 
programmatore informato e non guidato da spot pubblicitari, valutare i 
singoli casi e scegliere l'approccio più adatto, ricordandosi sempre che 
in informatica *non* esiste il modo corretto di fare le cose, ma che 
ogni metodologia ha *sempre* i suoi lati positivi ed i suoi lati 
negativi, la cui proporzione può variare in base al problema da risolvere.
Ciao.

 Ma per java abbiamo strumenti per ogni cosa e parecchio potenti.
Certo. È uno dei punti di forza. Ma quello che voglio dire è
semplicemente che queste cose non è Java l'unica ad averle. Anzi.
Il punto è che, tanto per dire, un fottio di banche usano già Java in
modo massiccio. Quindi in pratica è davvero molto comodo per lavorare,
ma non devo certo venire qui a raccontare la diffusione di Java.
Non solo, spesso e volentieri esempi su riviste/rete/libri sono fatti in
Java (mi viene in mente, per dire, il Silberschatz). Anche molti
progetti interessanti lo usano. Spesso demo tecnologiche sono pure
quelle fatte in Java.
E soprattutto la GUI. Per quanto maledettamente pesante, Swing si
comporta davvero bene in ambiente multipiattaforma.
Esempio con Tk ho tirato un grafo di bestemmie per -- non -- riuscire ad
avere un client che si comportasse in modo uniforme su Mac, Windows e
Linux. Alla fine riscrivendolo -- evidentemente come volevo fare le cose
io non andava -- ci sono uscito: su Windows era brutto, su Linux osceno,
su MacOS faceva vomitare.
Con QT ho lavorato un po' meglio. Peccato che devi comunque
pacchettizzare un macello di librerie con qualunque cosa distribuisci (e
a meno di pagare devi rilasciare sotto GPL -- non ho indagato il
problema se potessi rilasciare in BSD, ma temo di no, cosa che mi
avrebbe fatto molto piacere all'epoca).
Tra l'altro adesso con Matisse si ha un GUI visual editor che
semplicemente è allo stato dell'arte, per lo meno per quanto ho visto
io. Se il GUI Editor di Netbeans 4.1 era funzionante, rimaneva comunque
meno raffinato di InterfaceBuilder di MacOS e (dicono, io non ho modo di
usare) i vari tools Microsoft.
NetBeans 5 invece offre un prodotto davvero di prima classe. Credo che
farò fatica a trovare qualcosa di anche vagamente altrettanto decente
per le GUI di un progetto in wx/QT che devo affrontare (spero QT, di
imparare wx non ho proprio un treno di voglia, specie in quanto a me
fare GUI viene generalmente a noia).
Tra l'altro mi chiedo se con la sostanziale eliminazione dei layout
nestati che spesso si vedevano, le GUI in Swing diventeranno più
leggere.


 Smalltalk. Che sia stato il pioniere va bene, ma non esageriamo
credo che tu non le abbia provate. Visualworks, che ancora viene 
aggiornato insieme ad esempio a Squeak, difficilmente ti chiede più di 
20 mega di ram, e va anche su pc vecchi di diversi anni. Continua a 
suggerire soluzioni che poi vengono implementate in java. Ci sono 
framework che dopo essere sviluppati in smalltalk sono poi portati su 
java. Forse sto facendo un po' il tifoso, ma credo che sia uno di quei 
linguaggi che, come ha detto qualcuno, aprono la mente. Mai sentito 
parlare di Kent Beck?

 [CUT]
quoto tutto

 
era evidente che gli esempi citati erano messi lì soltanto come esca :D
Anche io ritengo poco serio, e sarebbe un grande errore in questo 
momento buttarsi sulla tecnologia sbagliata solo per una propria 
preferenza incondizionata. Imparare la tecnologia java richiede tempo e 
fatica, ciò che impari oggi non è detto che si userà domani. Io sto 
valutando se in questo momento vale la pena nuttarsi proprio su java. 
Nonostante alcuni miei commenti negativi non mi dispiace java, non mi 
piace molto l'anarchia del proliferare di una serie esorbitante di 
framework e tecnologie, ma probabilmente questa è una faccia della 
medaglia dell'open source.

 sono la Garbage Collection e la gestione delle Eccezioni.
Le eccezioni sono comuni a molti linguaggi compreso C++. Per il resto
il GC non è (in se) una peculiarità che aggiunge tutto questo valore
a Java, semmai nel contesto di gestione "managed" della memoria. Il
fatto che l'accesso alla memoria è astratto dal linguaggio rende java
estremamente robusto in contesti dove la sicurezza è fondamentale,
risparmiando il problema dei buffer overflow.
Naturalmente questo non è peculiare di java, ma è una caratteristica
che lo contraddistingue in positivo dal C/C++ in diversi ambiti (uno a
caso, il web) dove è fondamentale la sicurezza.

 Nel caso b) Java è totalmente inutile.
Gravissimo errore!
La NASA come la maggior parte delle agenzie spaziali è molto avanti con la 
ricerca in ambito software!
Il sistema di trasferimento dati e comunicazione con i due robottini mandati su 
marte è completamente scritto in java!
E direi una cosa sola, questo è grande traguardo in fattore stabilità e 
efficacia del codice.
(Considerando che le missioni sono durate più del previsto!)
Scusate l'offtopic,
ma a volte è meglio una precisazione, che un flame troppo lungo!
Ciao,
jRed

Ragazzi credo che il problema non sia nel linguaggio in sè, quanto che
nelle Universita si predispone lo studente ad imparare un set di
linguaggi in particolare. Per me andrebbe rivalutata l'astrazione, si
dovrebbe fare come in molte università statunitensi, dove i lingugi
deml momento vengono studiati alla fine del corso di laurea. Più che
un corso in linguaggi di programmazione, andrebbe inserito un corso che
spieghi i fondamenti della programmazione ad oggetti, astraendo i
concetti da un linguaggio concreto

 Java.
Tiro ad indovinare. Visto che si mischiano spesso librerie C, C++
moderne e C++ antiche alla fine ci si ritrova con alcuni pezzi che usano
i return code, altri che usano le eccezioni.
La cosa io non la trovo particolarmente sconvolgente, ma č spesso cosě.
-- 
non vincono, non vinceranno, non hanno domani
la forza č nel puntello impugnato da oneste fortissime mani

 Clos era quasi offensivo.
Perchč passare da un estremo all'altro?


 linguaggio non ha allontanato, più che avere avvicinato, imho ]
Niente da obiettare. Volevo solo evidenziare il fatto che di passi in avanti
Java ne ha fatti molti, e sebbene nessuno di noi abbia la sfera di
cristallo, credo che sia ragionevole supporre che, a fronte di una nuova
tecnologia applicativa 'X',  vi sarà una libreria Java in grado di
utilizzare 'X'. Questa è un'altra buona ragione per investire in Java.
Saluti,
Scorpio.

 i return code, altri che usano le eccezioni.
Il codice misto complica la vita, ma ci vuole poco a "wrappare" i return 
code in eccezioni.
Ciao.

 medaglia dell'open source.
Non hai torto: il proliferare di framework rischia di poter diventare un 
tallone di Achille. Però fortunatamente Sun è IMHO molto attenta a cogliere 
le idee positive e migliori che provengono dal mondo open source che gravita 
intorno a Java e a trasferirle nella "libreria standard". Per esempio 
considera le radicali modifiche e semplificazioni apportate alla specifica 
EJB proprio in virtù di quelle critiche e migliorie che sono state avanzate 
da implementazioni alternative agli Entity bean...
Scorpio. 

 code in eccezioni.
Ci vuole poco si. Ma è tutto lavoro da fare. A non doverlo fare, ci
vuole ancor meno. Non che questa sia un'obiezione "seria", beninteso. Ho
solo cercato di interpretare quanto scritto.
-- 
non vincono, non vinceranno, non hanno domani
la forza è nel puntello impugnato da oneste fortissime mani

 utilizzare 'X'. Questa è un'altra buona ragione per investire in Java.
Su questo sono assolutamente d'accordo.


 parlare di Kent Beck?
Si, stai facendo il tifoso. E si, lo conosco e so come la pensa. Proprio
ieri abbiamo avuto il permesso di invitare Kent a Java conference di
quest'anno, così tutti avranno il piacere di ascoltarlo. E gli daremo il
permesso di dire tutto quello che vuole, anche - se vuole - che Smalltalk
è meglio di Java. Ma non si faceva una questione di linguaggio, tutti
sanno che Smalltalk è il più puro dei linguaggi ad oggetti (anche se Ruby
potrebbe presto occupare la sua piccola nicchia): e proprio questo è il
motivo per cui tutti - proveniendo da C e questo era il senso della frase
sopra - usano Java. Ti riconsiglio di leggere "Beyond Java" dove questi
argomenti sono trattati ampiamente, con tanto di interviste a diversi
personaggi sul perchè il mondo usa Java e non Smalltalk o Ruby (che non
sono e probabilmente non saranno mai pronti per il prime time
nell'enterprise), e su come d'altro canto il mondo stia cominciando forse
ad essere pronto per passare a qualcosa di nuovo, che però non esiste
ancora e nessuno sa ne' come sarà ne' quando si farà
I punti interessanti della discussione sono: ora che Java è una commodity
ed è ovunque, cosa ci sarà dopo Java? Diventerà Java superdinamico come
Ruby o abbiamo bisogno di un nuovo paradigma e nuovo relativo linguaggio?
E il mondo è pronto? E quale azienda/consorzio si farà carico di tutto ciò?
Sul presente di Java e i confronti con altri linguaggi/ambienti invece mi
sembra inutile e stupido discutere, visto che Java è il nuovo Cobol e sta
nella maggior parte dei sistemi informativi mondiali: dalle casse dei
supermercati (i più grandi del mondo per chi è curioso), alle carte di
credito, ai sistemi bancari, all'infrastuttura per fare billing delle vs
telefonate, ai sistemi di intercettazione telefonica, per citare a caso
quelli in cui sono stato coinvolto personalmente che non sono scontati
come webapp e giochi j2me. Chi dice il contrario o non ha mai lavorato nel
mondo enterprise (tre anni fa alla Normale alcuni prof mi chiesero se Java
era ancora usato e se Jim Waldo ancora lavorava in Sun!) o lavora in Ms...
e, bada bene, proprio il successo di java potrebbe essere la ragione per
cui non potrà stare al passo con i tempi.
uL
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 solo cercato di interpretare quanto scritto.
Se lo devi fare in C++ lo devi fare anche in altri linguaggi. Java non 
te lo permette, il Python sì, me è comunque lavoro che devi svolgere.
Ciao.

 cui non potrą stare al passo con i tempi.
La trovo una frase molto azzeccata.

 manutenzione più semplice.
Sai benissimo anche tu che tutto questo è soggettivo. Non solo, le
opinioni diffuse (con quello che contano...) non sono esattamente di
questo parere.
Io posso dirti una cosa a braccio fra Python e C++, su Java non riesco a
fare un confronto perchè cambia moltissimo il mio modo di lavorarci e
complessivamente ho molta meno esperienza che in C++ o in Python.
In Python sono circa cinque volte più rapido a lavorare che in C++
(nonostante conosca il C++ da molti più anni), il mio codice è molto
meno soggetto ad errori (e gli errori che faccio sono abbastanza stupidi
da essere oltremodo facili da scovare) e il codice è estremamente
ordinato e leggibile, anche da chi non conoscesse Python (questa è una
caratteristica di Python, nel suo sviluppo la leggibilità è
assolutamente chiave).
Ultimamente sto lavorando molto con Java, e quello che posso dirti è che
l'unica cosa che mi spiace davvero è che sostanzialmente senza una
progettazione *molto* formale e in qualche modo anti-intuitiva (per come
ragiono io) perdo un sacco di tempo, mentre in C++ e in Python
generalmente per sottoproblemi non eccessivamente complessa posso
formalizzare molto meno e progettare più su "larga scala". Ma questo
potrebbe benissimo dipendere dalle mie particolari skills.


 manutenzione più semplice.
Sai benissimo anche tu che tutto questo è soggettivo. Non solo, le
opinioni diffuse (con quello che contano... ;) ) non sono esattamente di
questo parere.
Io posso dirti una cosa a braccio fra Python e C++, su Java non riesco a
fare un confronto perchè cambia moltissimo il mio modo di lavorarci e
complessivamente ho molta meno esperienza che in C++ o in Python.
In Python sono circa cinque volte più rapido a lavorare che in C++
(nonostante conosca il C++ da molti più anni), il mio codice è molto
meno soggetto ad errori (e gli errori che faccio sono abbastanza stupidi
da essere oltremodo facili da scovare); inoltre il codice è estremamente
ordinato e leggibile, anche da chi non conoscesse Python (questa è una
caratteristica di Python, nel suo sviluppo la leggibilità è
assolutamente chiave).
Ultimamente sto lavorando molto con Java, e quello che posso dirti è che
l'unica cosa che mi spiace davvero è che sostanzialmente senza una
progettazione *molto* formale e in qualche modo anti-intuitiva (per come
ragiono io) perdo un sacco di tempo, mentre in C++ e in Python
generalmente per sottoproblemi non eccessivamente complessa posso
formalizzare molto meno e progettare più su "larga scala". Ma questo
potrebbe benissimo dipendere dalle mie particolari skills.
Dicevo, a parte questo ho idea che in breve tempo la mia produttività in
Java supererà quella in C++, nonostante fra i due linguaggi preferisca
il secondo [ puramente su base personale, senza pretese di "è meglio 


 il secondo [ puramente su base personale, senza pretese di "è meglio 
Io sono sicuramente più produttivo (per quanto, da tecnico, disprezzi 
questo termine, che è la causa della pessima qualità di molto del sw in 
circolazione) in Java che in C++ per un certo insieme di applicazioni, 
ma lo sono molto meno per altri insiemi.
Potrei dire che la bravura di un progettista è proprio quella di 
scegliere lo strumento adatto al problema da risolvere, ma non lo dirò 
:-) perché so che concordi con me.
Ciao.

scusa ti ho mandato il post in pv per errore, lo riposto qui
uL ha scritto:
 > per imparare un nuovo
 > linguaggio non c'è niente di meglio di vi/notepad e quindi non te lo
 > consiglierei
E magari per imparare la grafica al computer si dovrebbe usare paint.
Un ambiente di sviluppo è utile sia per imparare dai propri errori sia
per osservare il codice scritto da altri nelle classi delle librerie in
modo veloce. Non credo che ci sia un modo migliore di imparare.
 >
 >
 >>e ancora ne avrà bisogno per un po'... almeno fino a quando la potenza
 >>di calcolo non sarà illimitata e soprattutto gratis
 >
 >
 > intendevo il mondo degli sviluppatori business. E non per le capacità di
 > calcolo, ma per la mentalità degli sviluppatori C per cui 1.upTo(10) {|x|
 > blocco } è troppo avanti. Sulla questione delle performance mi sembra una
 > battaglia di retroguardia, come quando si sosteneva che un uomo poteva
 > creare linguaggio macchina molto meglio di un fortran.
questo è ancora vero. Infatti ancora in tantissime applicazioni
embedded si scrivono routine assembly per gestire le parti cruciali del
codice.
 > Le virtual machine
 > sono destinate ad ottenere performance superiori di qualsiasi gestione
 > manuale della memoria, e già siamo sulla buona strada, vedi per esempio
 > 
http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html?ca=dgr-lnxw01JavaUrbanLegends
Senza mettere in discussione i risultati del test, chi cerca le
prestazioni in c non usa malloc, usa lo stack. Ci sono
tante altre cause di overhead in un linguaggio a oggetti basato su vm, è
una conseguenza naturale dell'astrazione. Quando astrai perdi giocoforza
il contatto con le caratteristiche di basso livello, con 2 conseguenze:
l'ottimizzazione diventa più difficile sia per il programmatore sia per
il compilatore. Il c sarà sempre più veloce di
qualsiasi linguaggio a oggetti, per il semplice motivo che è più vicino
al linguaggio macchina.
 >
 >
 >>credo che tu non le abbia provate.
 >
 >
 > credi male ;)
allora non capisco la tua affermazione. Che ide usi (a parte vi,
ovviamente, quello sì che è veloce)?
 >
 >
 >>Forse sto facendo un po' il tifoso, ma credo che sia uno di quei
 >>linguaggi che, come ha detto qualcuno, aprono la mente. Mai sentito
 >>parlare di Kent Beck?
 >
 >
 > Si, stai facendo il tifoso.
Questa perdonami ma è una caduta di stile. Sono sicuro che hai molta più
esperienza
di me, e proprio per questo potresti argomentare le tue affermazioni sul
tema. Poi ognuno ha le sue preferenze che non è vietato esternare, io
per ora ho le mie ma mi guardo intorno perché c'è da imparare da tutto e
da tutti. La sun non ha bisogno di paladini.
 > E si, lo conosco e so come la pensa. Proprio
 > ieri abbiamo avuto il permesso di invitare Kent a Java conference di
 > quest'anno, così tutti avranno il piacere di ascoltarlo. E gli daremo il
 > permesso di dire tutto quello che vuole, anche - se vuole - che Smalltalk
 > è meglio di Java.
Perché solitamente questo permesso non lo concedete? :D
 > Ma non si faceva una questione di linguaggio, tutti
 > sanno che Smalltalk è il più puro dei linguaggi ad oggetti (anche se Ruby
 > potrebbe presto occupare la sua piccola nicchia): e proprio questo è il
 > motivo per cui tutti - proveniendo da C e questo era il senso della frase
 > sopra - usano Java. Ti riconsiglio di leggere "Beyond Java" dove questi
 > argomenti sono trattati ampiamente, con tanto di interviste a diversi
 > personaggi sul perchè il mondo usa Java e non Smalltalk o Ruby (che non
 > sono e probabilmente non saranno mai pronti per il prime time
 > nell'enterprise)
ho già detto la mia idea, che poi è una considerazione abbastanza ovvia:
perché è supportato da un'azienda come sun che  ha creato uno standard.
  Senza standard e senza supporto non si può entrare in modo massiccio
nel mondo business, come un artista non può vendere 10 milioni di dischi
senza un contratto con una multinazionale.
Poi anche perché la sintassi simil-c ha fatto credere a qualcuno di non
dover fare troppi sforzi per passare a java, ma anche questa non è una
dimostrazione della forza del linguaggio, anzi.
Comunque leggerò beyond java perché mi interessa approfondire l'argomento.
 > , e su come d'altro canto il mondo stia cominciando forse
 > ad essere pronto per passare a qualcosa di nuovo, che però non esiste
 > ancora e nessuno sa ne' come sarà ne' quando si farà
 >
 > I punti interessanti della discussione sono: ora che Java è una commodity
 > ed è ovunque, cosa ci sarà dopo Java? Diventerà Java superdinamico come
 > Ruby o abbiamo bisogno di un nuovo paradigma e nuovo relativo linguaggio?
 > E il mondo è pronto? E quale azienda/consorzio si farà carico di 
tutto ciò?
 >
 > Sul presente di Java e i confronti con altri linguaggi/ambienti invece mi
 > sembra inutile e stupido discutere, visto che Java è il nuovo Cobol e sta
 > nella maggior parte dei sistemi informativi mondiali: dalle casse dei
 > supermercati (i più grandi del mondo per chi è curioso), alle carte di
 > credito, ai sistemi bancari, all'infrastuttura per fare billing delle vs
 > telefonate, ai sistemi di intercettazione telefonica, per citare a caso
 > quelli in cui sono stato coinvolto personalmente che non sono scontati
 > come webapp e giochi j2me. Chi dice il contrario o non ha mai 
lavorato nel
 > mondo enterprise
Il fatto di lavorare in un'azienda non credo che apra gli occhi,
semplicemente aumenta la propria specializzazione in un campo, nel tuo
caso java. Tu presenti il fenomeno java come al culmine della sua
maturazione. La mia sensazione dall'esterno è che java sia pronto per
una marea di applicazioni, sicuramente molte di più di quelle che hai
elencato, ma ancora stia aspettando delle risposte per affermarsi in
tanti di questi campi, la concorrenza c'è ed è forte, soprattutto quella
delle veccie tecnologie. Questa tua posizione mi giunge nuova nella sua
assolutezza.
Poi basta guardare questa pagina per vedere quando queste liste lascino
il tempo che trovano: 
http://www.whysmalltalk.com/production/index.htm
Questo basta per dire che smalltalk è molto usato? Non credo.
 > (tre anni fa alla Normale alcuni prof mi chiesero se Java
 > era ancora usato e se Jim Waldo ancora lavorava in Sun!) o lavora in 
Ms...
 > e, bada bene, proprio il successo di java potrebbe essere la ragione per
 > cui non potrà stare al passo con i tempi.
bella questa. basta pensare a cosa è successo col dos per rendersi conto
di quanto questa equazione spesso sia vera :D
 >
 > uL
 >
senza rancore :)
antonio

 antonio
e quale rancore? I newsgroup esistono apposta per questo. 
Io dico solo che se si parla di quanto Java potrebbe essere (o avrebbe
potuto essere, magari a 
scapito della diffusione) più OO, è un discorso (personalmente non molto
interessante). Se si parla 
di cosa Java potrebbe diventare nel prossimo futuro, è un'altro ancora
(personalmente molto 
interessante). Ma se stiamo parlando della diffusione di Java la cosa è
molto meno opinabile (e 
neanche interessante ;))
ciao


 neanche interessante ;))
"Though a language can last half a century to support legacy applications,
I know no language can 
keep its leadership and its luster forever. Java's reign will end. It's
not a question of if, but when."
Direttamente dal libro di B.Tate, mi sembrava pertinente alla discussione
(discutiamo di quando e 
come finirà la supremazia di java, non se questa supremazia esista). E ora
vado a sorbirmi Chicken 
Little con i bimbi, va, che in fondo è festa


 
http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html?ca=dgr-lnxw01JavaUrbanLegends
The common code path for new Object() in HotSpot 1.4.2 and later is 
approximately 10 machine instructions (data provided by Sun; see 
Resources), whereas the best performing malloc implementations in C 
require on average between 60 and 100 instructions per call (Detlefs, 
et. al.; see Resources).
Guarda caso "the best performing malloc implementations in C" è 
descritta in un documento del 1993.
Ma facciamo una prova:
///  file test.cpp
#include <vector>
class A
{
public:
     A(int a, float b, double c): a_(a), b_(b), c_(c) {}
private:
     int a_;
     float b_;
     double c_;
};
int main()
{
     const int max = 1000000; // 1 milione
     std::vector<A> v;
     v.reserve(max);
     for (int i=0; i<max; ++i)
     {
         v.push_back(A(i, i, i));
     }
}
/// file Test.java
class A
{
     private int a_;
     private float b_;
     private double c_;
     public A(int a, float b, double c)
     {
         a_ = a;
         b_ = b;
         c_ = c;
     }
}
public class Test
{
     public static void main(String[] argv)
     {
         final int max = 1000000; // 1 milione
         A[] v = new A[max];
         for (int i=0; i<max; ++i)
         {
             v[i] = new A(1, 1, 1);
         }
     }
}
compilando ed eseguendo (prendendo i tempi) ottengo questo:
C++:
./test  0,02s user 0,01s system 97% cpu 0,037 total
Java:
java Test  0,58s user 0,36s system 93% cpu 1,012 total
Per riempire un vettore con 1 milione di oggetti in C++ ci metto 0,037s 
  contro i 1,012s di Java.
Per quanto questo test possa valere poco dai suoi risultati Java mi pare 
ancora pittusto distante (siamo, in questo caso, nell'ordine di 30 vole 
più lento).
Da notare che ho usato std::vector (che è una classe di libreria) e non 
gli array predefiniti (tipo C, per intenderci), che avrebbero 
probabilmente fatto qualcosa meglio, ma non avendo le stesse 
caratteristiche di sicurezza degli array Java (come vector ha) non 
sarebbe stata una prova equa.
Ciao.

 sarebbe stata una prova equa.
Il tuo test non dimostra nulla...diciamo niente di più del fatto che il 
rubinetto di sinistra è quello dell'acqua calda! (passami l'ironia...) :D
Credo che la cosa fondamentale di cui rendersi conto per chi vuole "programmare" 
in java...sta proprio nel fatto che java non è un linguaggio velocistico e 
spinto nelle prestazioni!
E che *ovviamente* ci mette di più a riempire un array gira su una macchina 
virtuale...che emula una serie di componenti che vengono cosi virtualizzate...e 
con un minimo di fantasia...ognuno può trarre le giuste conclusioni!
Java è frutto di una scelta...che non è quella di sostituire il C++...e credo 
che in tutto questo discorso non si è posta attenzione sul perchè di questa 
scelta! Risposta del topic originale di questa discussione!
Ciao,
jRed

 giuste conclusioni!
Dillo a quelli dell'IBM e alla persona alla quale ho risposto che paiono 
convinti del contrario.
Ciao.

> Forse questo vale per ingegneria, in generale comunque non e' cosi'.
Secondo me vale solo nella sua università... 

 sarebbe stata una prova equa.
beh, usare lo stack, misurare lo startup della VM e far allocare oggetti
più grandi a Java non mi sembra proprio equo. Cmq fai una classe più
completa e realistica, in modo che sia realmente paragonabile a quella
java e vediamo cosa viene fuori. Che sia 30 volte più veloce è escluso,
che vada al doppio è più realistico.


 ha gli attributi impliciti di Object.
Mi scuso per la fretta (sarà l'ora). Mi ero dimenticato di inserire dei
parametri decenti alle dimensioni dell'heap di Java (che altrimenti ha un
minimo ridicolo e deve crescere per fare spazio), ora Java crea due
milioni di oggetti in 0.386 (al netto dello startup della VM) contro i
0.305 di c++. E c'è sempre l'header di Object che, se non sbaglio, sono 16
byte. Per cui Java sta allocando circa il doppio dello spazio in più o
meno lo stesso tempo. Non male, eh?
time java -Xms64M -Xmx64M Test
Elapsed:0m0.386s
real    0m0.513s
user    0m0.347s
sys     0m0.110s
time test
real    0m0.305s
user    0m0.192s
sys     0m0.093s
Kernel linux 2.6, gcc 3.3.6 e Java5 su un laptop PiV 3Ghz con 1Gb RAM
ciao


 Elapsed:0m0.386s
time java -Xms64M -Xmx64M Test
java -Xms64M -Xmx64M Test  0,63s user 0,29s system 97% cpu 0,941 total
Io non vedo nè il tuo codice nè differenze
Ciao.

 più veloce è escluso, che vada al doppio è più realistico.
Cosa significa per te una classe più completa e realistica?
Ciao.

uL ha scritto:
 > antonio ha scritto:
 > non siamo d'accordo, un IDE non ha questi scopi ed è considerato dannoso
 > per chi impara dalla
 > maggioranza dei formatori (e da uno che sta ancora all'uni non me
 > l'aspetterei ;)). Ma questo è off
 > topic, stavamo parlando della diffusione di java.
siamo alle solite. Io cerco di proporre degli argomenti a favore mie
ipotesi, tu tiri in ballo delle persone che non nomini. Quali formatori? 
  Quelli che hanno visto la prima interfaccia grafica a 30 anni? Perché 
sarebbe dannoso?
 >
 >
 >>questo è ancora vero. Infatti ancora in tantissime applicazioni
 >>embedded si scrivono routine assembly per gestire le parti cruciali del
 >>codice.
 >
 >
 > infatti, embedded, ossia equivalente a processori di dieci anni fa. 
Per un
 > processore moderno
 > (ormai orientati al multicore) è praticamente impossibile ottimizzare a
 > mano meglio di quanto
 > possa fare un compilatore
altra opinione personale. E mi fai venire in mente una cattiveria: non è 
che java è stato spinto anche dai produttori di hardware?
 >>qualsiasi linguaggio a oggetti, per il semplice motivo che è più vicino
 >>al linguaggio macchina.
 >
 >
 > questa è una semplificazione, semplicemente non vera. Dipende dal tipo di
 > applicazione. Leggi un
 > po' di paper in materia, ce ne sono diversi anche nei link dell'articolo
 > di B.Goetz.
non è una semplificazione è un'ovvietà, le vm non sono nate per le
prestazioni, ma per la flessibilità, poi si può sempre migliorare, ma
più di tanto non si può fare e il motivo l'ho spiegato. I paper di
benchmark, ma questo non devo essere io a dirtelo, non valgono in genere
una cippa perchè si può dimostrare tutto e il contrario di tutto. Non 
credo che tu sia così ingenuo da credere
 >
 > E' chiaro che una VM (Java o non Java) è scritta soprattutto in C, che a
 > sua volta è compilato in
 > linguaggio macchina. Quindi per quanto riguarda le performance 
teoriche VM
 > < C < ML vien da
 > se'. Ma tutto ciò è accademico, come usare il crivello di eratostene per
 > un bench. Ti posso dire che
 > diverse applicazioni lato server sono migrate da c a java per *aumentare*
 > le performance e non
 > diminuirle.
le servlet sono più efficienti a regime di una cgi perchè restano in
memoria dopo la prima chiamata, al contrario delle cgi che devono creare
un nuovo processo ogni volta. Ma questo non ha niente a che vedere con
le prestazioni della vm, la lentezza della creazione del processo è 
dovuta al sistema operativo tanto come la richiesta di memoria dinamica. 
Ma con te queste spiegazioni non servono, dovrei dire forse: esistono 
numerosi esempi che affermano il contrario di ciò che dici.
 >>allora non capisco la tua affermazione. Che ide usi (a parte vi,
 >>ovviamente, quello sì che è veloce)?
 >
 >
 > intellij Idea, quando il progetto me lo permette. Ma mi parlano bene di
 > Netbeans 5. Quel coso con
 > il nome leopardiano invece non lo conosco :) Ma non stavamo parlando di
 > ide java, ma di
 > smalltalk, o sbaglio?
no, parlavo di java, i cui ide sono la dimostrazione lampante della sua
lentezza. Ho citato l'ambiente smalltalk in quel determinato contesto 
perchè ha una vm che si è evoluta in 30 anni e l'apertura dell'ambiente 
di sviluppo impiega 1 secondo là dove ad esempio eclipse ne impiega 30. 
E per me e per qualsiasi utente queste si chiamano prestazioni, non i 
test da strapazzo. Vorrei chiudere qui la mia discussione su smalltalk 
perché, sebbene mi ci trovi bene e lo ritenga molto utile nella 
formazione di un programmatore so benissimo perché non può sostituire 
java. Sinceramente neanche mi interessa che lo faccia, conosco 
abbastanza anche java e c++ e ci metterei poco a imparare le basi di un 
nuovo linguaggio OO.
 >
 >
 >>Questa perdonami ma è una caduta di stile. Sono sicuro che hai molta più
 >>esperienza
 >>di me, e proprio per questo potresti argomentare le tue affermazioni sul
 >>tema. Poi ognuno ha le sue preferenze che non è vietato esternare, io
 >>per ora ho le mie ma mi guardo intorno perché c'è da imparare da tutto e
 >>da tutti. La sun non ha bisogno di paladini.
 >
 >
 > Ognuno può avere le proprie preferenze: anche a me piace Ruby come
 > linguaggio OO, per
 > esempio. Ma generalizzare le proprie convinzioni o addirittura smentire i
 > fatti è un'altra cosa. Java
 > oggi è il linguaggio più usato nel mondo, posto che la misurazione dei
 > parametri indiretti di cui
 > sotto sia la più affidabile. Cobol è ancora il linguaggio con più 
righe di
 > codice in produzione,
 > invece. E anche Visual Basic ha lasciato un sacco di legacy. Quindi se si
 > parla di diffusione di Java, i
 > fatti sono li' e vanno "solo" interpretati
Non mi interessa negare che java sia diffuso, è interessante capire 
*quanto* è diffuso e soprattutto sarà in futuro diffuso. Se leggi bene 
ho solo contestato la tua sicurezza che non si accompagna ad altrettanta
eloquenza nello spiegare le ragioni di ciò che credi
 >
 > ottimo! Leggere un libro "critico" sullo stato dell'arte di java scritto
 > da esperti del settore: questo è
 > il modo giusto di procedere, poi magari ne riparliamo. Nota: perchè non
 > c'è "Beyond Ruby" (che ha
 > gli stessi anni di java) o "Beyond Smalltalk" (che ne ha molti di più 
ed è
 > giustamente riconosciuto
 > come il papà di tutti i linguaggi OO moderni)?
il titolo non promette nulla di critico, visto che contiene un marchio 
intorno al quale peraltro gravitano un mucchio di soldi. Nel caso non te 
ne fossi accorto ci sono libri che parlano anche di altri linguaggi e 
dicono quanto sono belli e utili.
Nonostante questo ho cominciato a leggerlo (naturalmente dalla sezione 
contenders :P), e mi sembra che faccia un'analisi molto oggettiva e 
interessante, con la quale sono pienamente d'accordo.
 >
 >
 >>Il fatto di lavorare in un'azienda non credo che apra gli occhi,
 >>semplicemente aumenta la propria specializzazione in un campo, nel tuo
 >>caso java.
 >
 >
 > beh, non solo. Si vede anche il mondo enterprise che fa. E non fa CLOS, e
 > non perchè siano tutti
 > stupidi, anzi. E neanche Smalltalk (qualcosa "enterprise" ho visto in una
 > nota banca italiana: ora lo
 > stanno  migrando a Java) E se l'azienda è grande e i clienti non sono i
 > soliti  (ie ti da l'opportunità
 > di non fare le solite webapp), ti si aprono pure gli occhi. L'università
 > ha altri pregi, ma certo non
 > quello di percepire correttamente cosa succede nel mondo, non è il suo
 > scopo. Se sei fortunato e
 > hai i professori giusti (che implica di solito non stare in italia) forse
 > puoi avere la fortuna di sapere
 > cosa è probabile che succederà fra 5 anni.
Le tendenze enterprise sono quantomeno effimere, il conoscerne i 
dettagli non apre di certo gli occhi per come lo intendo io. Per me 
avere gli occhi aperti non significa sapere cosa succede *ora* nel 
mondo, per  questo basta una piccola ricerca o farsi un giro nelle 
aziende, come dici tu. Significa innanzitutto conoscere dove può 
arrivare realmente la tecnologia, e questo vuol dire sapere cosa siamo 
in grado di fare al giorno d'oggi. Lo stato dell'arte enterprise è 
frutto del compromesso, che il più delle volte tappa le ali alle idee 
più geniali perché di solito non vale la pena imbarcarsi per primi verso 
soluzioni alternative. A guidare le scelte di una media impresa, prima 
della maggiore produttività e della la qualità, è il più basso rischio. 
Ma non perché i dirigenti siano degli incompetenti, semplicemente non 
hanno gli strumenti per compiere le proprie scelte, c'è bisogno di una 
legittimazione esterna forte prima di compiere una scelta.
"Nessuno è mai stato licenziato per aver acquistato da IBM"
Credo che questo famoso slogan renda l'idea della situazione
 >
 > Tu presenti il fenomeno java come al culmine della sua
 >
 >>maturazione.
 >
 >
 > non lo presento io così, è così: Java dopo dieci anni *è* al culmine 
della
 > maturazione. Basta farsi
 > un giro per le aziende... o leggere le statistiche sui parametri 
indiretti
 > come numero degli
 > sviluppatori, numero dei libri, numero di partner, numero di job posting,
 > numero di applicazioni
 > (open source e closed source), numero di ng, numero di post sui ng, 
numero
 > di user group, ecc.
 > Anzi, da qui potrebbe anche aver raggiunto il picco e scendere: ma 
non c'è
 > ancora "the next big
 > thing" e quindi porbabilmente non succederà a breve
Finalmente un'analisi interessante
 >
 >
 >>Poi basta guardare questa pagina per vedere quando queste liste lascino
 >>il tempo che trovano: 
http://www.whysmalltalk.com/production/index.htm
 >>Questo basta per dire che smalltalk è molto usato? Non credo.
 >
 >
 > e che c'entra? Io ho solo elencato le cose di cui mi sono occupato
 > personalmente, un po' diverse
 > dalle solite, per dare un'idea della natura variegata dei progetti java e
 > della pervasività. L'esistenza
 > stessa di questa lista Smalltalk implica che c'è bisogno di 
rassicurare le
 > persone sull'effettiva
 > usabilità a largo spettro, in effetti ce n'era una uguale per Java agli
 > inizi... ora ne è rimasta una
 > sulle applicazioni grafiche con Swing, e sai perchè? Perchè proprio 
quello
 > è ancora oggi il punto
 > debole sia per le performance che per la facilità di ottenere risultati
 > decenti. Si chiama marketing.
ma và?
Questa è retorica spicciola, hai ridetto la stessa cosa che ho detto io, 
e in più la vorresti usare contro di me (??)
 >
 >
 >>senza rancore :)
 >>antonio
 >
 >
 > e quale rancore? I newsgroup esistono apposta per questo.
esatto. E in ogni newsgroup c'è sempre qualcuno a cui piace fare il 
fratello maggiore, che si sente già arrivato e ha tanto da insegnare a 
tutti. Uno dei diletti di queste persone è educare i nuovi arrivati. Il 
tuo atteggiamento si inquadra in questo stereotipo, evidentemente non 
hai bisogno di ascoltare nessuno e il tuo parere è per te abbastanza 
autorevole da non aver bisogno di essere argomentato adeguatamente. Sei 
comunque abbastanza intelligente da capire che ti controbatte non lo fa 
per presunzione ma solo per discutere, come è giusto fare in un newsgroup.
ciao,
antonio

 Io non vedo nè il tuo codice nè differenze
Le differenze sono che il *tuo* codice java ed il *tuo* codice cpp (con
l'unica modifica di creare gli 
oggetti sull'heap, come è giusto che sia) creano due milioni di oggetti
nello stesso tempo. Immagino 
tu possa farti le modifiche da solo: se vuoi stasera posto il codice
"modificato" e le impostazioni. E, 
ripeto, Java deve creare anche l'header di Object (8 byte) più il padding.
A te le conclusioni


 ciao,
infatti, non voglio convincerti di niente, il senso critico è segno di
intelligenza. (ma non c'entra con 
la preparazione)
Il mio punto è, in sintesi, lasciando solo il nocciolo e fuori la
dialettica e l'OT:
- Java è oggi il linguaggio più diffuso al mondo, e ha sostituito il
cobol. Indici a piacere, ce ne 
sono tanti e qualcuno l'ho elencato
- Java non è il linguaggio più OO che c'è perchè doveva somigliare a C++,
e questa è stata una 
delle ragioni del suo successo: potrebbe però diventare un ostacolo nel
prossimo futuro. Le 
tendenze moderne sono verso linguaggi più dinamici, e il vecchio dibattito
con la scuola 
nordeuropea, che sembrava ormai finito (a favore di Stroustrup e amici),
ritorna d'attualità: Kent 
Beck sarà sicuramente contento, e glielo chiederemo a maggio
- Lato prestazioni, Java deve migliorare sulle GUI, e ci si sta lavorando
per Mustang e successivi. 
La JVM di per se' è più veloce di quasi tutto quello che c'è in giro.
C/C++ è teoricamente ed 
ovviamente più veloce di qualsiasi cosa, ma in un'applicazione reale che
usi oggetti reali le VM 
(Java o non Java) stanno beneficiando di tecniche sofisticatissime di
gestione della memoria che 
negli ultimi tempi addirittura mettono in discussione questa supremazia. 
- Queste tecnicheovviamente sono applicabili non solo a Java ma anche ad
altri ambienti. Però 
Java, grazie alla sua diffusione, ha le VM più sofisticate. D'altronde
basta fare un quicksort in java 
(che sta nelle librerie runtime ) ed uno in c per vedere che lato
prestazioni "pure" le cose non sono 
più come qualche anno fa
- D'altronde, la virtualizzazione (a diversi livelli, dalla CPU in su) è
argomento caldo ed è la 
tendenza attuale delle infrastrutture IT, cosa che rafforza i punti
precedenti. In un prossimo futuro 
potrebbe essere molto complicato spremere il massimo dalle CPU moderne
senza sofisticate 
tecniche di virtualizzazione 
Confutazioni circostanziate e discussioni sui punti di cui sopra mi
interessano, i battibecchi  no.
peace,


 convinti del contrario.
Non estremiziamo. Dai test che hai effettuato...come vedi...e come era 
ovvio...C++ rimane più veloce di Java...ma cosi deve essere, e mi stupirei del 
contrario (non solo io)!!!
Esistono profonde differenze tra i due linguaggi, ricordiamoci bene il fatto che 
Java è nato negli anni 90, quindi con tutta un altra mentalità.
Integra automatismi nella gestione della memoria e degli oggetti...e come è 
logico un automatismo che ti permette di risparmiare codice ti penalizza un po' 
durante il Run-Time. (ma questo è stato previsto fin dall'inizio!) ;)
Mentre C++ ha origini ben più remote venendo da C (diciamo anni 70) e non 
integra tutti quegli automatisti dei *nuovi* linguaggi! ;)
Altra piccola cosa...non credo che sia una buona strada comparare il 
codice...perchè è vero che ti appare quasi uguale sintatticamente...ma i due 
run-time sono totalmente diversi!
Diversa gestione della memoria, diversa gestione delle risorse...sono cose che 
fanno la differenza!
Poi la java virtual machine è scritta in C++...e come fa una cosa scritta in 
java che gira su una base di c++ ad essere più veloce di una cosa scritta in c++ 
e basta? :D
C'è uno strato intermedio...che non puoi non vedere! :D
La cosa più *importante* invece è l'evoluzione velocistica della VM...che ha 
fatto passi da gigante...con le ultime versioni...e con il passare del 
tempo...il divario si avvicinerà sempre di più (anche grazie a nuove 
architetture hardware)!
Ciao,
jRed

 Cosa significa per te una classe più completa e realistica?
non so, qualcosa che abbia uno stato, lo cambi, si rappresenti, parli con
altri oggetti, faccia 
qualcosa di diverso da una struct. Altrimenti uso il C che è ancora più
veloce, è più semplice, e 
pure più portabile. Comunque l'articolo di "quelli dell'IBM" discute i
vantaggi che una VM con 
moderni GC ha (e avrà con l'escape analysis in mustang) rispetto alla
malloc, tutto qua: non vedo 
come il tuo codice smentirebbe la cosa. se pensi però che in qualche modo
lo faccia, postalo nel 
forum di alphaworks.
ciao


 tecniche di virtualizzazione
scusami ma non riesco a capire dove entra in gioco la virtualizzazione 
spinta in questo discorso. A me sembra soltanto un vecchio problema di 
compilazione
antonio

 nuovi linguaggi col blocco note.
Una piccola postilla: se hai fatto degli esami di certificazione, avrai
notato che nella maggior parte dei test devi risolvere con la mente ciò
che di norma ti risolve l'ide con i vari code completion, parsing dei
sorgenti in tempo reale, suggerimenti, help, etc...
Non dico che non sia utile (anzi, utilissimo!!!) ma se non ti poni mai
il problema del tipo ritornato dal metodo add() di Collection (giusto
per fare un esempio) sicuramente avrai sempre in aiuto l'ide a
suggerirti, però non lo sai. E didatticamente parlando il "non sapere"
non è risultato utile.

 compilazione
La virtualizzazione in parte c'entra...come centra l'ottimizzazione del livello 
inferiore del java...cioè della virtual machine...e di quello inferione l'OS!
Quali risultati ottieni ottimizzando al massimo il livello superiore se le 
fondamenta non sono ben ottimizzate?
Secondo te quanto è specifica la compilazione di un windows? e di un linux? 
quanto uso fanno delle specifiche istruzioni (tipo SSE, MMX) degli specifici 
processori?
Ciao,
jRed

Vincent Vega ha scritto:

Ogni strumento, anche utile, deve essere utilizzato con intelligenza. Ho 
visto un test della sun (credo intermedio), e giustamente pone l'accento 
su dettagli che, sono d'accordo con te, è utile conoscere. Sono anche 
d'accordo sul fatto che il completamento automatico non sempre è un bene 
quando si sta imparando, vedo invece bene l'evidenziazione inline degli 
errori. Se leggi qualche post più in alto ho spiegato il perché è utile 
secondo me un ide sia utile in una determinata fase. Prima della 
programmazione vera è propria ritengo che sia necessaria la conoscenza 
teorica prima di tutto dell'oop, poi della filosofia e della sintassi 
almeno di base del linguaggio che si vuole imparare.
Un'ultima cosa: per l'esempio da te citato, è secondo te meglio leggersi 
la documentazione della classe Collection o avere a disposizione il 
codice e con un click vedere come è stata implementata add nella 
libreria standard?

 degli specifici processori?
rispondevo a uL, che parlava di necessità delle vm per poter ottimizzare 
il codice sui processori moderni. Se ho capito bene parlava di 
virtualizzazione come strumento per l'ottimizzazione, e questo 
contestavo. Per il resto nulla da obiettare!
ciao,
antonio

 compilazione
Ci sono cose difficili da fare staticamente, tutto qua. Comunque tutto era
partito dal fatto che oggi 
un compilatore sa fare delle cose impossibili da fare a mano (su
architetture complesse), magari 
domani la stessa cosa sarà vera per le virtual machine nei confronti dei
compilatori


 contestavo. Per il resto nulla da obiettare!
Tranquillo, le obiezioni sono la parte centrale di un NG, l'importante alla fine 
è discutere in maniera costruttiva, c'è sempre molto da imparare anche per Ugo! :D

 la differenza sia di un ordine di grandezza.
proverò e vi farò sapere.
antonio

 writes:
a> Ciao a tutti, sono un giovane studente di ingegneria informatica.
a> Il mio professore sostiene che java sia un linguaggio poco evoluto
a> e raffazzonato.
Ed è un docente. Ohi mamma. Mi auguro non sia di Padova.
Java NON è innovativo, James Gosling  ha solo preso una bella serie di
buone idee e le  ha messe insieme. Non lo ha mai  voluto essere. Non è
detto nemmeno  che sia  perfetto, purtroppo dietro  ci sono  "lotte di
potere economico".
a> Sostiene che il suo successo sia dovuto a una bolla
a> momentanea destinata a sgonfiarsi,
Beh, forse non ha tutti i torti ma vive in un mondo che è ben separato
da quello reale.
Java purtroppo soffre di essere stato scambiato per il cobol del terzo
millennio. Questo è  vero. Ma il cobol si usa ancora  (per la sfiga di
chi deve scriverlo).
D'altro canto c'è una classe  di applicazioni per cui il supporto Java
c'è, è ottimo ed è libero (mi  riferisco a ciò che gira sotto Tomcat o
JBoss) e questo è un qualcosa che va considerato.
a> che in questo momento sia meglio
a> puntare sul clos e sul c++,
clos ????? Lo ha scritto lui ?
Quanto  al C++,  nel momento  in  cui sarà  definito il  comportamento
standard  per   l'ereditarietà  a   diamante  ci  rifarò   un  pensie-
rino. Altrimenti C, C K&R per essere precisi.
(ah, e a quel paese cin e cout, datemi la printf()).
-- 
 /\            ___
/___/\__|_|\_|__|___Gian Uberto Lauri_____________________
  //--\ | | \|  |   Integralista GNUslamico  
\/		    e allevatore di bug da competizione

> bye e benvenuto in Java, in ogni caso DKano
c> Non lo so...NetBeans 5 continua ad essere un mattone spaventoso
c> anche per un centrino 1600.
Usare un editor serio ?


 imparare anche per Ugo! :D
se non ho nulla da obiettare è perché sono d'accordo ;)
ciao,
antonio

 Usare un editor serio ?
Sentiamo allora quale consigli? 

> Usare un editor serio ?
b> Sentiamo allora quale consigli?
Emacs + JDEE per la scrittura del codice. Lo uso in ufficio e "semino" la
gente che usa NetBeans/Eclipse/JBuilder. E' un pelino lento a partire su
un PII 300 MHz con 256 mega di ram (il mio vecchio fido portatile riscattato
a 0 lire), ma sulla macchina aziendale č un fulminastro.


 ottimizzare il codice e l'utilizzo delle risorse.
Eehhehe lo sappiamo tutti che gli ordini non si discutono, ma se non ci fosse 
stato chi ha discusso (non dico gli ordino ma almeno) le idee, non ci sarebbe 
mai stata vera innovazione!
Poi io ti prendo in esempio il caso di windows vista...possiamo dire che sono 
state ricerche molto fuori dal comune, perchè 128mb di sola grafica...è 
ridicola...diciamo requisiti da videogames...!
Tagliando fuori tutto l'hardware un po' datato...non credo che sia una ottima 
strada da percorrere! ;) (ma questa è una mia opinione...)
Ciao,
jRed

 grafica...è ridicola...diciamo requisiti da videogames...!
E sì, ma io credo nel dipartimento marketing della microsoft e 
nell'occhio di Bill. Fino ad ora ci hanno preso :D

 nell'occhio di Bill. Fino ad ora ci hanno preso :D
Seguo da molto la loro storia nessuno dice che non ci hanno preso, anzi sono 
loro a dettare le "leggi" del mercato! Ma a volte ci vuole buon senso, e dosare 
le novità nella giusta maniera...
Entrando nello specifico sarebbe più utile ultimare WinFX (per mandare in 
pensione l'ormai poco efficace NTFS) piuttosto che concentrarsi troppo sugli 
effetti grafici, ma semplicemente perchè loro stavano già a buon punto! ;)
Ciao,
jRed
PS: cmq alla fin fine è venuta su una bella discussione!

 a 0 lire), ma sulla macchina aziendale è un fulminastro.
Parliamone di JDEE...
;; CEDET
;; Load CEDET
 (load-file "~/.elisp/cedet/common/cedet.el")
;; Enabling various SEMANTIC minor modes.  See semantic/INSTALL for more
ideas.           
;; Select one of the following
 (semantic-load-enable-code-helpers)
;; (semantic-load-enable-guady-code-helpers)
;; (semantic-load-enable-excessive-code-helpers)
;; Enable this if you develop in semantic, or develop grammars
;; (semantic-load-enable-semantic-debugging-helpers)
;; JDE
 (add-to-list 'load-path (expand-file-name "~/.elisp/jde/lisp"))
 (load-file (expand-file-name "~/.elisp/cedet/common/cedet.el"))
 (add-to-list 'load-path (expand-file-name "~/.elisp/elib"))
 (require 'jde)
;; ECB
      (add-to-list 'load-path
                   "~/.elisp/ecb")
      (require 'ecb)
Poi a me da alcuni problemi a completare automaticamente. Io la home la
ho settata, ma lui sostanzialmente dice
Cannot find JDK's tools jar file (or equivalent).Type M-x
describe-function [RET] jde-get-jdk-dir for more info.
Eppure io la variabile jde-jdk l'ho settata correttamente... forse mi è
sfuggito qualcosa. Consigli?
-- 
non vincono, non vinceranno, non hanno domani
la forza è nel puntello impugnato da oneste fortissime mani

 nell'occhio di Bill. Fino ad ora ci hanno preso :D
Beh, insomma, il marketing in generale si, lui spesso ha preso cantonate.
Come quando disse che internet non serviva... perň ha un sacco di soldi e
riesce a recuperare in fretta.


 riesce a recuperare in fretta.
Secondo me il prossimo "botto" sarà quello sul DRM. Non credo che tutto 
il mondo "playabile" accetterà di passare attraverso MediaPlayer. Ho 
letto che la SUN sta cercando di costruire uno standard aperto in 
alternativa, confido vivamente in questa possibilità.
Su .NET non mi pronuncio, ma onestamente non mi pare che stia avendo 
questo gran successo (la creazione del ng it su c# ha fallito 
l'approvazione per scarso numero di voti già alcune volte).
pole
-- 
ammentos - a lightweight persistence framework for JDK5
http://ammentos.biobytes.it
Flash tutorial: 
http://ammentos.biobytes.it/quickstart/quickstart.htm

> aziendale è un fulminastro.
EF> Parliamone di JDEE...
EF> ;; CEDET ;; Load CEDET (load-file
EF> "~/.elisp/cedet/common/cedet.el")
Io ho questo. Uso lo Emacs da CVS e me lo metto in /usr/local/share.
Con Darwin devo ancora compilarmelo, non sono ancora riuscito a far
partire X.
(setenv "JAVA_HOME" "/usr/lib/j2sdk1.4-sun")
(setq load-path
      (nconc (list "/home/saint/vm-7.07"
		   "/usr/local/share/emacs/site-lisp/jde/lisp/"
		   "/usr/local/share/emacs/site-lisp/cedet/cogre"
		   "/usr/local/share/emacs/site-lisp/cedet/contrib"
		   "/usr/local/share/emacs/site-lisp/cedet/ede"
		   "/usr/local/share/emacs/site-lisp/cedet/eieio"
		   "/usr/local/share/emacs/site-lisp/cedet/semantic"
		   "/usr/local/share/emacs/site-lisp/cedet/common"
		   "/usr/local/share/emacs/site-lisp/elib")
	     load-path))
(load-file "/usr/local/share/emacs/site-lisp/cedet/common/cedet.el")
Le cose relative a semantic non le tocco.
EF> Cannot find JDK's tools jar file (or equivalent).Type M-x
EF> describe-function [RET] jde-get-jdk-dir for more info.
Questo è diverso.
Io tengo una parte del classpath comune nella configurazione generale.
Ci ho messo tutti i jar dei vari duntime base dello SDK J2SE , J2EE e ant.
Poi, _per progetto_, aggiungo le varie librerie. Usando Customize e
dei modulini in lisp che fanno tutto il lavoro per me. Se vuoi i
modulini, scrivimi, saint chiocciola fsfe punto org.


 modulini, scrivimi, saint chiocciola fsfe punto org.
Prima vorrei capire un po' di più come funziona sta cosa. Il punto è che
devo agganciare la teoria sottostante, perchè Java è in se installato un
po' diversamente su MacOS X (penso che lo avrai visto), pertanto temo di
dovere adattare un po' di cosa.
Per esempio il tutorial relativo a come settare le faccende io lo ho
seguito passo passo e avrebbe dovuto funzionare. Immagino tuttavia di
avere dato i Path sbagliati.
Per esempio dentro il custom-set-variables ho
'(jde-jdk-registry (quote (("1.5" .
"/System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home/") ("1.4"
. "/System/Library/Frameworks/JavaVM.framework/Versions/1.4/Home/"))))
"/System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home/" è
secondo me il path corretto, in quanto contiene 
+-[13:07]-------------------------------------------[riko:Dome2]-+
\_[riko] $ ls
/System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home/
appledocs     bin           docs.jar      lib           src.jar
appledocs.jar docs          include       man
o forse dovrei usare 
"/System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home/libs"?


> modulini, scrivimi, saint chiocciola fsfe punto org.
EF> Prima vorrei capire un po' di più come funziona sta cosa. Il punto
EF> è che devo agganciare la teoria sottostante, perchè Java è in se
EF> installato un po' diversamente su MacOS X (penso che lo avrai
EF> visto), pertanto temo di dovere adattare un po' di cosa.
Concettualmente non cambia molto passando  da Linux a Mac OS X -ovvero
microkernel con flavour BSD-, cambiano solo i path.
EF> Per esempio il tutorial relativo a come settare le faccende io lo
EF> ho seguito passo passo e avrebbe dovuto funzionare. Immagino
EF> tuttavia di avere dato i Path sbagliati.
Possibile. Anche se a volte si imbrana e non capisce subito che alcuni
jar ci sono.
EF> Per esempio dentro il custom-set-variables ho
EF> '(jde-jdk-registry (quote (("1.5" .
EF> "/System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home/")
EF> ("1.4"
EF> . "/System/Library/Frameworks/JavaVM.framework/Versions/1.4/Home/"))))
EF> "/System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home/"
Parrebbe che tu abbia 2 jdk installati, devi indicare in ogni progetto
quale usi.
Da me la vita è più semplice (e antiquata), ma non usiamo ancora servlet
container con java 1.5. Quindi non ho ancora esplorato la cosa.
Il mio registry punta alla home directory in cui ho installato il JDK
$ ls /usr/lib/j2sdk1.4-sun
bin        demo     lib      README       THIRDPARTYLICENSEREADME.txt
COPYRIGHT  include  LICENSE  README.html
debian     jre      man      src.zip
che come vedi ha al di sotto la directory dei comandi binari, lib e jre.
(consiglio, comincia ad usare  il comando Control-h Control-v sui nomi
delle variabili, Control-h Control-f per le funzioni)


 Come quando disse che internet non serviva...
Premetto che non conosco i dettagli sui fatti. Ma sicuramente internet 
era troppo open per fare business sulla tecnologia in sè (come piace a 
lui, ovviamente ;) ), e quindi ha provato a farsi il suo standard 
proprietario. Mi  sembra da questo punto di vista una strategia valida.
Anche la xbox per citarne una non è che sia andata granchè bene, e anche 
i palmari a quanto pare non stanno avendo quella diffusione che 
prospettavano a microsoft. Ma non vorremo per questo discutere il senso 
degli affari del signor Gates?
Non è mica possibile indovinare tutto...i dipartimenti marketing fanno i 
loro studi su base probabilistica in base ai dati che hanno, e spesso 
vengono fuori risultati contro logica. Ma a quanto pare con la logica 
non si fanno i soldi :)

 non si fanno i soldi :)
Eehhee...credo che qui molti potrebbero avere da ridire...e diciamolo tra 
noi...se non ci fosse stato un fine logico ben preciso (chiamalo sogno, 
intuizione o quello che ti pare...) il signor Gates non sarebbe dove è ora...
La stessa cosa per java...diciamo che è nato nel momento giusto...nella maniera 
giusta! :D (per questo non è perfetto!) :D
Ciao,
jRed

 delle variabili, Control-h Control-f per le funzioni)
Dentro Emacs, immagino... questi fanno autocompletamento? Basato sul
contenuto del buffer oppure "IntelliSense"?
-- 
non vincono, non vinceranno, non hanno domani
la forza è nel puntello impugnato da oneste fortissime mani

 l'approvazione per scarso numero di voti già alcune volte).
Questo però, Pole, al massimo può essere sintomo del fallimento del
linguaggio C#, non del framework .NET in sè. Sarebbe comunque grave, perchè
fosse così il forte dubbio che .NET equivalga, de facto, a 
VB.NET
riceverebbe un'altra conferma. E a ben vedere non sarebbe una gran bella
cosa....
Scorpio.

 cosa....
Esatto. Il fatto è che quell'architettura non sembra ancora nemmeno ben 
definita: pare che stiano decidendo di tagliare fuori il supporto per 
alcuni linguaggi, windows Vista non è basato su .NET come era stato 
promesso, C# 2 è ancora di là da venire, mancano librerie per fare tante 
cose; tutto questo mentre sul lato Java è appena uscito il JDK5 e già 
sono disponibili le build di mustang, EJB3 è praticamente una realtà 
etc. etc.
Per dirla con Schildt, Java è al centro di una cultura di cambiamento e 
innovazione: a differenza della maggior parte degli altri linguaggi Java 
è sempre stato tra i primi ad integrare le novità (basti pensare ai vari 
xml, webservices e chi più ne ha più ne metta, fino ad arrivare per 
esempio all'integrazione nel sistema MHP per la TV digitale). E' per 
questo motivo IMHO che dopo dieci anni è ancora la scelta migliore per 
una grande varietà di applicazioni.
Ciao!
pole
-- 
ammentos - a lightweight persistence framework for JDK5
http://ammentos.biobytes.it
Flash tutorial: 
http://ammentos.biobytes.it/quickstart/quickstart.htm

> lo possono trovare il non plus ultra, a ciascuno i suoi occhi.
EF> Aquamacs si basa su GNU Emacs 22 da CVS, patchato e stabilizzato.
Bon, allora anche lui si basa su una versione non ancora rilasciata :)
:) :) :).
Il supporto Carbon  è arrivato con la 22,  ci lavora su principalmente
un giapponese (Yamamoto Mitsuhara se non ricordo male).
EF> Un ottimo supporto per font e utf8 (cosa che a me torna *molto*
EF> comoda).  Poi stampa "bene", interfacciandosi all'os.
UTF8  è  una  cosa che  viene  inclusa  in  GNU  Emacs mi  pare  dalla
21. Probabilmente, dove c'è, usa il supporto di sistema.
Bidi  (per gli  alfabeti  che vanno  "contromano")  ha ancora  qualche
problemino mi dice mia moglie che lo usa. 
EF> Se un po' ti fidi del mio giudizio:
EF> 
http://rik0.wordpress.com/2005/11/30/mac-emacs-aquamac/
Non c'è  problema, mi fido del  tuo giudizio e mi  riprometto di darci
una occhiata. Ho solo abbandonato Mac OS X.
EF> Dentro Emacs, immagino... questi fanno autocompletamento? Basato
EF> sul contenuto del buffer oppure "IntelliSense"?
No,  documentano le  variabili e  le funzioni.  Java non  ha inventato
molto, nemmeno con  JavaDoc :) (Gosling è l'autore  di una delle prime
implementazioni di Emacs in C).
Il completamento lo ottieni  coi comandi jde-complete-* per quello che
riguarda  i  completamenti  che  richiedono reflection(*),  ha  invece
meccanismi  interni (c-flow,  abbrev-mode)  per quel  che riguarda  le
espansioni del tipo ife ->  if-then-else (c-flow) o il riuso di parole
già inserite, anche in un altro buffer.
(*) JDEE  lavora in questo modo:  avvia una istanza  di beanshell (una
volta sola), quindi per le cose  specifiche di Java usa quella e legge
i risultati. Eventuali menù vengono  generati da Emacs che si basa sul
toolkit con cui è stato compilato  e sono molto più lesti di quelli di
Eclipse. Per  mostrare i metodi di  un oggetto (o quelli  che fanno il
match  con  una  sottostringa)  usa  questo meccanismo,  idem  per  la
generazione  automatica degli  statement di  import.  Il riordinamento
degli statement di import lo fa invece lavorando nel buffer.
-- 
 /\            ___
/___/\__|_|\_|__|___Gian Uberto Lauri_____________________
  //--\ | | \|  |   Integralista GNUslamico  
\/		    e allevatore di bug da competizione

Uh Enrico eri l'ultimo che mi aspettavo di vedere su it.comp.java :-)
-- 
Ciao
Fabio

 è sempre stato tra i primi ad integrare le novità (basti pensare ai vari 
Era quello che tentavo di dire a inizio thread parlando di comunità 
"affiatata". E' chiaro che nmila persone che concorrono allegramente 
allo scopo di tenere il liguaggio (e librerie) aggiornate e competitive 
sono meglio dei tiramenti di bill che decide da solo. Non credo che in 
altri linguaggi (anche non proprietari) ci sia attualmente qualcosa di 
simile, o sbaglio?
bye
DKano

 simile, o sbaglio?
IMHO non sbagli affatto ;)


 una grande varietà di applicazioni.
IMHO concordo pienamente!
Ciao,
jRed

 writes:
p> a differenza della maggior parte degli altri linguaggi Java
A differenza di altri linguaggi Java ha dietro un hacker non un
ufficio marketing :).


 già inserite, anche in un altro buffer.
Mi sa che me lo devo studiare per bene :))
Solo che diventa maledettamente lento tenere cedet e jdee etc etc.
L'avvio di Emacs aumenta sensibilmente.


 Uh Enrico eri l'ultimo che mi aspettavo di vedere su it.comp.java :-)
Il fatto che Java non mi piaccia, non significa che non lo usi :)
E soprattutto se "parlo male" di qualcosa è perchè almeno un po' lo
conosco :)
Tra l'altro in questo thread mi sono perfino trovato a "difendere" Java
(non che ne abbia bisogno, beninteso, visto il successo che ha
evidentemente di lati positivi ne ha più di quanti voglia
riconoscergliene).


 troppo ad alto-livello per qualcosa di veramente concreto! ;)
Non credo che il problema sia "essere di alto livello". Semmai essere
progettato in modo discutibile, o meglio, incoraggiare a sviluppare in
maniera discutibile.


 maniera discutibile.
Concordo. L'idea di un framework che sta alla base di n linguaggi, con un
grande, grandissimo numero di oggetti per la programmazione in ambiente
windows, web, servizi web etc non è assolutamente da buttar via. Tutt'altro.
Il problema di .NET è che, al di là del fatto di essere molto più giovane
(con tutte le lacune ed i difetti del caso) della tecnologia Java, presenta
un "equivoco di fondo": quattro linguaggi, di cui due,J++.NET e C++.NET,
sono estremamente di nicchia (per non dire inutili), uno, Vb.NET, va ad
ereditare il grande successo di VB, e C#, l'unico creato ex-novo, che -
inutile girarci intorno - è " Java made in Microsoft". E come Java, il suo
studio ed apprendimento richiede un certo impegno.
Normale che le aziende, in periodo di vacche magre, abbiano la tendenza a 
puntare su VB
rispetto a C#. Con quali risultati ? Beh, di avere tutto subito: accesso ai 
dati, interfacce grafiche IMHO migliori di quelle che a parità di tempo si 
possono ottenere in Java, possibilità di porting su web. Sulla carta: i 
bagni di sangue non sono così infrequenti, sebbene neppure J2EE scherzi in 
merito.
Purtroppo, o per fortuna a seconda dei punti di vista, se .NET legherà il 
suo successo solo a 
VB.NET
 che appunto incoraggia a sviluppare "alla buona", 
difficilmente potrà scalzare Java dal favore che ha riscontrato un po' da
tutti in questi ultimi anni.
Scorpio.

 tutti in questi ultimi anni.
Nella mia certamente non significativa esperienza dove si è adottato 
.NET si è adottato C#, e si trattava o di gente che provava il salto da 
Java o di progetti totalmente nuovi; mai di vecchi progetti VB. IMHO la 
scommessa, finora non vinta, di MS era quella di imporre .NET come 
strumento nell'ambito dello sviluppo enterprise, settore in cui 
probabilmente non ha mai giocato un ruolo determinante. Finora non c'è 
riuscita secondo me per due motivi fondamentali: 1) perché è un settore 
in cui già esistono da tempo soluzioni molto efficaci e consolidate; 2) 
perché si tratta di una comunità che non ragiona alla MS. Ovvero non è 
un ambito in cui si apre il Visual Studio, si scrivono oggetti COM e si 
fanno girare su windows, ma un mondo fatto di standard, pattern, 
protocolli aperti e (soprattutto) concorrenza. E in questo mondo aperto 
probabilmente giocare da soli non paga, come hanno da tempo capito le 
varie SUN, IBM, Oracle etc.
A tutt'oggi la mia impressione è che con questa scommessa Microsoft si 
sia probabilmente giocata la comunità di sviluppatori VB senza peraltro 
ottenere significative quote di penetrazione nella comunità enterprise.
Ma là dentro ci sono indiscutibilmente dei geniacci, ne verranno fuori 
in un modo o nell'altro, magari registrando meglio il target. Uno dei 
pregi di MS è la capacità di apprendere dai propri errori e di 
effettuare anche brusche virate stando bene in piedi, come quando, una 
volta preso coscienza che internet era il futuro, tirarono fuori il 
miglior browser del mercato.
Ciao :)


 tutti in questi ultimi anni.
Fortunatamente Java è affiancato da una buona community...e in questa trova una 
grande spinta...invidiabile da qualsiasi altro linguaggio! ;)
Ciao,
jRed
PS: Per non togliere nulla al "drag-n-drop" e al 
VB.NET
, ma a volte si vedono 
certe soluzioni...troppo semplici...e precotte, che non danno a mio parere 
solidità! Ma altre volte, queste funzionalità sono utili e permettono risparmio 
di codice e tempo, se dosate con parsimonia! ;)

 miglior browser del mercato.
Ok, portatelo a letto, avrà bevuto troppo! :D
A parte gli scherzi, IE non era male, veloce, innovativo, solo che non è stato 
rinnavato molto con il tempo, rimanendo troppo rigido per certi versi...
(clamoroso il problema della gestione delle PNG o il parsing dei CSS...)
Ciao,
jRed

 (clamoroso il problema della gestione delle PNG o il parsing dei CSS...)
...o dei buchi degli activex (guardacaso, altra tecnologia più o meno in 
contrasto alle applet Java, che però fin da subito giravano nella loro 
bella sandbox).


 writes:
p> fantastico rispetto ai suoi rivali (ed era gratis, almeno di
p> facciata), poi...
Come no! Non azzeccava un colore che fosse uno sotto X11 (salvo che si
usasse quella piaga di CDE) -si, ho provato Exploder per Slowlaris, su
invito  di un amico  che allora  lavorava per  l'impero del  male.  Ha
avuto dalla  sua che Netscape era  ed č elefantiaco (no,  piů grosso e
dentuto) e che č di sistema.
p> Un po' come quando sei a scuola in una classe di
p> persone non esattamente bravissime.
Paragone perfetto!


 dove è ora...
non vedo il nesso tra la logica, scienza che da delle premesse trae 
delle conclusioni sulla base di regole, con i sogni e le intuizioni.
Se bastasse la logica, che è alla portata di tutti, tutti saremmo ricchi!
La moderna teoria dei mercati finanziari ha abbandonato la pretesa di 
studiare l'andamento dei mercati su base logica, perché l'esperienza ha 
dimostrato che raccogliere dati e trarre delle conseguenze da questi non 
porta a nessun risultato.
La mia personale conclusione è che non si possa far altro che rinunciare 
a capire i meccanismi del mercato con la ragione e affidarsi ad altri 
strumenti. Come l'intuizione, i sondaggi, o l'abuso di posizione 
dominante :D

 dentuto) e che č di sistema.
Vabbé, mai detto che IE potesse avere altra (valida) casa all'infuori di 
Win :P


 Vabbé, mai detto che IE potesse avere altra (valida) casa all'infuori di Win :P 
Peccato non sarebbe stata male un po' di portabilità, in fin dei conti, sarebbe 
stato comodo per molti trovare un browser famigliare anche fuori win! ;)
(ad esempio molti impiegati delle PA che si stanno spostando verso i sistemi 
free...)
Ciao,
jRed

> 21. Probabilmente, dove c'è, usa il supporto di sistema.
EF> Si, e su MacOS però c'erano state magagne (per esempio con alcune
EF> configurazioni era frequente che le accentate venissero
EF> visualizzate come quadratini).
Risolvibile creandosi il fontset(?). Yamamoto è una persona cortesissima :)
BTW, ho  letto quello che  hai pubblicato...  Ho qualche  dubbietto su
Aquaemacs - per  la verità conoscevo l'altra versione  vecchiotta e in
ogni  caso  non  lo userei  mai  perché  _a_me_  serve Emacs  non  una
applicazione Mac  OS X  :) :), ma  è Software  Libero e quindi  per la
libertà zero ciascuno è libero di usarlo come vuole.
EF> Lo so. Gosmacs, il primo in ambiente Unix. ;) Diventato in seguito
EF> proprietario.
Preparato il giovine :) :) :)
EF> Mi sa che me lo devo studiare per bene :))
La tecnica vincente è usarlo guardando pian pianino cosa fa.
EF> Solo che diventa maledettamente lento tenere cedet e jdee etc etc.
EF> L'avvio di Emacs aumenta sensibilmente.
Infatti. Emacs lo lanci al logon e lo lasci lì (col tempo ci fai tutto
quello che riguarda gestire testi. Di qualsiasi tipo).
Per ogni modulo  che carichi deve fare un seek  sul disco per caricare
il bytecode, poi verifica se il bytecode è aggiornato in modo coerente
rispetto  ai sorgenti.  E nel  caso si  faccia partire  JDEE  e magari
attivi la beanshell...
Per usi da command line (*) usi emacsclient o gnuclient.
(*)  Include l'uso  per caricare  in Emacs  un file  col  doppio click
sull'icona in un file manager.
Tornando a Java.
Java non è perfetto, non  c'è liberamente distribuibile e completo per
tutte  le  piattaforme HW+SW,  le  implementazioni  a  volta sono  ...
sopratutto  per quel  che riguarda  applicazioni interattive  con GUI.
Stranamente le implementazioni per Windows sono buonine, corricchiano.
Quelle per Unix e Linux, ringraziate  la scelta di usare motif a volte
fan  cascare  le  braccine.  Sarebbero da  testare  abbondantemente  i
binding per GTK o QT.
Ha il  grande vantaggio di  essere un linguaggio  coerente (sensazione
che C++ non mi ha mai dato, e  che C bemolle ha fatto di tutto per non
avere) e, se il codice non è scritto da cani, è molto più portabile di
altri... C'è pysol per Mac OS X :) :) :) :) :) ?
C bemolle ha una implementazione libera supportata da Novell, ci hanno
fatto dei  tool che  paiono molto interessanti,  ma alcuni  di questI,
come  beagle,  hanno delle  caratteristiche  che  dipendono molto  dal
sistema.


 VB.NET...
Attenzione, io parlavo di VB, non di VB.Net. Quando parlo di
incoraggiare a sviluppare alla buona, mi riferivo sostanzialmente al
vecchio VB. E oggettivamente anche le MFC di buone norme di
progettazione agli oggetti ne violano un po'.
VB.Net per fortuna non lo ho mai dovuto usare. (E non saprei nemmeno
come, visto che non ho macchine Windows con abbastanza spazio per
installare i tools Microsoft, nè abbastanza fondi da buttare a pozzo
perso in qualcosa che non mi ispira).
Comunque secondo quanto ho sentito in giro, pare che l'accoglienza della
comunità VB a VB.Net sia stata per lo meno fredda, per i motivi già
elencati in questo thread.


 writes:
EF> Comunque secondo quanto ho sentito in giro, pare che l'accoglienza
EF> della comunità VB a VB.Net sia stata per lo meno fredda, per i
EF> motivi già elencati in questo thread.
Diciamo che  si erano  dimenticati di reimplementare  alcune proprietà
indispensabili nei  controlli, almeno nella versione  che ci passarono
come demo.  Il risultato era sognarsi la migrazione automatica.
La versione dot  niet di VB è sicuramente meglio della  6, ma se pensi
che c'è gente che  dice che Java è un flop solo  perché non è in grado
di pensare in modo object oriented.


 di pensare in modo object oriented.
Questo è un gran problema,
sopratutto quanto frasi del genere passano per dei professori universitari...
Una cosa può essere discutibile o meno, ma prima di criticare è sempre bene 
sentire tutte le voci in gioco e non prendere opinioni personali come dogmi! ;)
Probabilmente prima o poi verrà lanciata un nuovo modo di programmare, non 
considerando per ora l'AOP che sta avendo una lenta crescita, bisognerà 
conoscere per giudicare! ;)
Ciao,
jRed

 altri... C'è pysol per Mac OS X :) :) :) :) :) ?
http://mail.python.org/pipermail/pythonmac-sig/2005-January/012706.html
Pare di si. E comunque questo per renderlo un'applicazione "mac os" a
tutti gli effetti. Se ci si accontenta di farlo funzionare, sarebbe
bastato compilare SDL da sorgenti, compilarci sopra il sound server e
via.
Dopo di che la portabilità di un linguaggio è separata dalla portabilità
di un dato programma. Se scrivessi delle estenzioni JNI per fare una
data cosa su una data piattaforma, il mio progetto non sarebbe
portabile, ovviamente. 


Nei Forum molte volte ci si perde su argomenti enormi dove tutti, a
parte le sparate eccessive, hanno ragione. Cercherò di schematizzare
l'argomento per avere un riassunto di quanto espresso fin qui.
La discussione coninvolge
a) il mondo Accademico, ricercano cosa è teoricamente meglio
b) il mondo Produttivo, cosa è economicamente conveniente
c) il mondo dei Programmatori, cosa è più comodo usare.
Credo che la maggior parte delle persone coinvolte nel flame
appartengano al gruppo c).
Dobbiamo però fare una netta distinzione tra chi
c1) sviluppa per se (ogni tanto per divertimento scrivo ancora delle
routine in fortran, mentre per lo scripting il Perl è imbattibile)
c2) sviluppa per il mercato (avete mai cercato di vendere un programma
scritto in NewEra -4GL?)
c3) sviluppa da solo (a questo punto puoi scegliere quello che vuoi)
c4) sviluppa il collaborazione su progetti open-source (ha già fatto
una scelta sul tipo di linguaggio da utilizzare)
c5) fa parte di una software house o di un CED con n applicazioni
attive sviluppate in proprio e altrettante da sviluppare in futuro.
Alla fine, anche se tutte le argomentazioni, risultano corrette
soprattutto e quasi solamente quelle espresse dal gruppo c5) saranno
degne di venir prese in considerazione.
1) Se il programma di fatturazione richiede una modifica perchè uno
dei miei clienti ha cambiato la carta intestata, tale modifica la deve
poter fare il cliente stesso, o il mio intervento deve limitarsi a 10
minuti di lavoro, senza fork ad hoc, altrimenti sono destinato a
fallire.
2) Se il mio programma lo voglio vendere all'estero il cambio della
lingua deve essere immediato.
3) Se un mio collega si licenzia devo poterlo sostituire con una
persona altrettanto capace (con le stesse conoscenze) nel più breve
tempo possibile.
4) Se la realtà hardware cambia e si evolve il mio linguaggio deve
essere in grado di adeguarsi.
I punti precedenti, scalbilità, manutenzione, astrazione del codice,
escludono qualsiasi approccio che non sia OO. E tra tutti i linguaggi
OO solo Java, .net e Delphi (?) soddisfano la reperibilità delle
dovute conoscenze nel mercato del lavoro IT.
Oggi conoscere un linguaggio non significa conoscerne la sintassi, era
così fino agli anni '80. Avete mai riguardato un vostro codice Java
scritto l'anno scorso? Personalmente anche se la sintassi è quasi la
stessa (pre Tiger) io lo rifarei completamente; ho usato classi
sbagliate un pò dappertutto. Ci sono errori anche nella parti più
semplici: avete mai fatto un test sulla performance di una String
rispetto ad una StringBuffer...?
La teoria che per ogni cosa c'è il linguaggio giusto, è verissima ma
è solo una teoria e quindi una stronzata.
L'importante non è scegliere il linguaggio giusto ma scegliere la
soluzione che soddisfi maggiormente il rapporto costi/benefici. A me
conviene sviluppare una nuova applicazione in Cobol perchè l'ho già
scritta simile 10 anni fa e in poche ore la adatto alle nuove esigenze.
Se devo sviluppare qualcosa di nuovo e devo assumere dei dipendenti per
questo progetto
mi guardo intorno e la mia scelta sarà determinata da ciò che offre
il mercato tenendo presente che è meglio un buon programmatore Basic
ad uno Java che non sa la differenza tra un boolean e un Boolean.
Il merito ed il limite dell'Università (U maiuscola) Italiana è
quello di aprire la testa degli studenti per fare delle scelte
consapevoli nel mondo del lavoro. Esprimere l'opinione che Java sia una
bolla è una scelta personale smentita dai fatti. 10+ anni di Java sono
per il mondo informatico un'enormità, sono stati un terremoto per la
comunità informatica i cui effetti sono tuttora attivi. Che Java sia
una bolla è da dimostrare, e anche se dovesse decadere non potremo
certo sostenerlo così come non possiamo sostenere che siano stati una
bolla il PC IBM, visto che l'IBM ha ceduto questo settore ai cinesi
perchè da decenni in perdita.
Scusate del disturbo.

 consapevoli nel mondo del lavoro.
Qui ci sarebbe da scrivere un libro, credo che in realtà questo non accade in 
maniera cosi efficace, visto che a volte l'insegnamento è visto come una rigida 
funzione istituzionale, dimenticando il vero spirito informatico che non si basa 
  assolutamente nella rigidità delle istituzioni...
(avete presente tutti quei famosi garage...)
Aprire la testa non vuol dire insegnare java o insegnare c, perchè programmare 
vuol dire ben altro...non ci sono dei confini ben definiti e non è certo 
l'università che può lanciare tendenze o imporre standard nel mondo 
informatico...almeno finchè c'è chi considera java una bolla! :D
Ciao,
jRed

Una ciritica interessante a proposito di Beyond Java:
http://www.artima.com/weblogs/viewpost.jsp?thread=141312