Newsgroup: it.comp.lang.c++
Titolo: Domanda seria: C++ o Java?

Ho sempre programmato in C e conosco
un poco di c++, un poco di java e un po' di
progettazione a oggetti.
A prescindere dalla portabilita' del java, vorrei sapere
da voi esperti di c++ e java quali sono i vantaggi di
un linguaggio sull' altro.
Per quel poco che so, programmare in java "dovrebbe" risultare piu'
sicuro,
ma, sempre IMVHO, si potrebbe programmare "in java " utilizzando il c++
Qui il discorso sulla differenza va a vertere sulle librerie standard
dei due linguaggi.
che non conosco (specialmente quelle c++) e su cui non posso fare una
valutazione
comparativa.
In poche parole, io devo decidere quale linguaggio affrontare per
sviluppare
applicazioni serie. Non ho (ancora) vincoli di portabilita' o
piattaforma e 
quindi volevo un parere da chi chi sviluppa su questi linguaggi.
Del C ne ho le scatole piene in quanto mi fa spendere 
il 90% del tempo di sviluppo in debugging (solitamente puntatori
impazziti)
Vi ringrazio miolto delle eventuali risposte a questa domanda 
(che sara' stata postata almeno milioni di volte)
Matteo Della Torre

 impazziti)
I puntatori in C++ impazziscono un po' meno, ma insomma,
anche li` li hai e spesso rompono.  Il Java li elimina.
Il grosso del vantaggio di produttivita` e` in questo.
Alex

 *ENORME* della programmazione generica ("template").
che fortunatamente entrerà presto a far parte anche di Java...
-- 
Ugo
__________________________________________________________________________
"La perfezione si ottiene non quando non c'è nient'altro da aggiungere, 
 bensì quando non c'è più niente da togliere." Antoine de Saint-Exupéry
__________________________________________________________________________
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Enterprise Java Consulting
@mail: Ugo.L...@Flashnet.it
Home Page: 
http://www.ugolandini.net
Mentoring: 
http://www.projectoo.com
Work Phone: 06/5814740
Fax Phone: 06/233207542 
Cell Phone: 0347/6310749 - 0347/4783580
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

 
nel mio caso le prestazioni possono essere importanti,
devo sviluppare software di calcolo numerico  (in particolare
reti neurali) , roba con moltissime operazioni e poco accesso ai dati
(che stanno in enormi strutture in memoria).
il fatto che java sia "semi interpretato" (scusate l'espressione
un po' idiota ma avete sicuramente capito) ne rallenta 
la velocita' di esecuzione - sempre nel caso di calcoli intensivi -
rispetto al c?
Grazie mille
Matteo Della Torre

 che fortunatamente entrerà presto a far parte anche di Java...
Davvero una buona notizia, che finalmente (quando sara`
implementata e universalmente disponibile) portera` Java
incondizionatamente al di sopra del C++ in termini della
produttivita` permessa al programmatore (supponendo, ovvio,
che i template Java saranno equipollenti a quelli C++, in
particolare permettendo la splendida pattern che Coplien
chiamo` "Patter Without A Name" quando la identifico` 5
anni fa); ricordo "Pizza", il linguaggio sperimentale che
univa Java, genericita`, e qualcosa d'altro, e anche se
(trattandosi appunto di un robo sperimentale) non ho mai
potuto basarci su del "codice di produzione", si trattava
di un mix veramente interessante.
Alex

 wrote in message
news:390002D9...@unimo.it...

Non necessariamente, perche` NON E` DETTO che sia "un fatto":
cioe`, puoi benissimo procurarti un "compilatore Java" che
genera codice nativo per una data macchina, sia a partire
dal sorgente originale oppure dal "codice intermedio" che si
rappresenta normalmente come bytecode per la VM Java.  E`
anche possibile che questa compilazione bytecode->nativo sia
"trasparente, automatica, just-in-time" (anche se e` probabile
che un compilatore-nativo-ottimizzante che parta dai sorgenti
abbia a disposizione informazioni semantiche piu` ricche e sia
quindi in grado di ottimizzare meglio, ma in merito c'e` ancora
un ragionevole dibattito fra i super-esperti del settore).
L'handicap di prestazioni implicito nel *LINGUAGGIO* Java,
rispetto al C++, e` invece dovuto proprio alle feature, che
il linguaggio presenta come intrinseche, e che danno tanti
vantaggi in termini di *produttivita`* del programmatore;
prima fra tutte, la "garbage collection".  Si applica "in
generale", ma puo` darsi che tu riesca ad aggirarlo per il
tuo problema particolare; se "tutte" le grosse strutture sono
allocate verso l'inizio, e poi la memory-footprint del tuo
programma resta sostanzialmente invariata sin verso la fine,
senza alcun importante "dinamismo" della memoria, puo` darsi
che tu *NON PAGHI* la GC ecc.
Potrebbe persino darsi (a seconda della piattaforma che
userai) che il Java standard ti permetta anzi di avere delle
prestazioni migliori del C++ standard, grazie in particolare
al suo supporto per i *THREAD*.
*SE* (e solo se!) hai molteplici processori nella tua
macchina, PUO` DARSI (poi bisogna vedere caso per caso)
che i tuoi calcoli si prestino ad essere "parallelizzati",
cosi` che diversi thread, girando su diversi processori,
CALCOLINO SIMULTANEAMENTE.  Non ti aspettare uno speed-up
di N per N processori, ma, se N e` piccolino, puoi certo
misurare speed-up *IMPORTANTI* rispetto ad N, a seconda
del tipo di problema; ad esempio, uno speed-up di 3 con
una macchina fisica a 4 processori sarebbe certo molto,
molto utile.
Non che il C++ ti *impedisca* di avere molteplici thread,
ma e` una feature *non direttamente supportata dal C++
standard* -- devi ottenerla usando librerie aggiuntive,
tipicamente non portabili fra piattaforme diverse; in
Java, invece, puoi usare il Java standard e fare tutto il
multi-threading che ritieni opportuno.
Perche` questo ti dia vantaggi pratici, bisogna, ovvio,
che la tua macchina-virtuale, o compilatore-nativo-Java,
sfruttino bene l'arrangiamento multiprocessore della tua
(eventuale) piattaforma d'interesse, se no il tutto resta
solo teorico e anzi, se predisponi il multi-threading ma
poi di processori sotto mano ce n'e` uno solo, rischi di
avere dei piccoli (o grossi, se hai mal operato:-)
RALLENTAMENTI rispetto alla codifica mono-thread.
Comunque, e` pur sempre una prospettiva interessante.
Un'ultima considerazione che puo` essere pragmaticamente
importante e` che in applicazioni numericamente intensive
si possono a volte identificare certe piccole "primitive"
di codice di calcolo -- una minuscola frazione del codice
che consuma una frazione sproporzionata del tempo di
esecuzione.  Un "profiler" e` lo strumento indispensabile
per determinare praticamente se una tale frazione esista,
e quale sia.
Se ad esempio scopri che il 5% del tuo codice occupa il
95% del tempo di esecuzione, merita sicuramente dedicare
a quella cruciale frazioncina un enorme sforzo di
ottimizzazione.
Se usi Java, puo` darsi che ti convenga per questa parte
usare codice C super-spinto, connesso al resto, il "grosso"
del programma che resta nel ben piu` comodo Java, con la
JNI, "Java Native Interface".  Nel codice C, puoi di nuovo
usare i puntatori e qualsiasi sporco trucco ti faccia
risparmiare anche una micro-fettina di tempo d'esecuzione.
L'uso dei template per l'ottimizzazione di codice numerico
e` un po' un argomento ancora "di avanguardia", ma qualche
risultato gia` si trova, come la libreria di template
Biltz++ per il linguaggio C++; in pratica, l'uso dei template
spinge al massimo il concetto di fare tutto il fattibile a
tempo di compilazione, cosi` che il tempo di esecuzione sia
assolutamente al massimo della velocita` possibile.
Oggi Java i template non li ha, ma, se e quando li avra`,
si puo` ben sperare che anche per esso emergano simili
possibilita` di super-ottimizzazione (i template sono
soprattutto una questione di enorme comodita` e riuso di
codice senza overhead, ma le loro possibilita` ottimizzatorie
non vanno certo, in prospettiva, trascurate).
Alex

rispetto al c?
Java e' notoriamente piu' lento dei linguaggi compilati. 
La causa e' nella interpretazione da parte delle macchine virtuali.

 [CUT]
Inoltre grazie mille per le tue esurienti risposte
Matteo Della Torre

source o da bytecode?
Credo che Visual J++ possa farlo.

 source o da bytecode?
Un vecchio riferimento, ancora dei tempi di Java 1.02,
e` 
http://sunsite.org.uk/javarc/dev/kit/ibmhpcj/
Uno + dettagliato, stessa data:
http://macarlo.com/ibmjavacompiler.htm
Un altro approccio (commerciale, da bytecode):
http://www.naturalbridge.com/
il loro prodotto si chiama "BulletTrain" e costa
$999, dice di supportare Java 2.
Sicuramente qualsiasi motore di ricerca potra`
aiutarti a continuare ed espandere la ricerca...
Alex

 per quella piattaforma).
....

il C++? Se il futuro è di Java tanto vale puntare su quello....o no??
(Almeno) due cose. Primo, ci sono situazioni in cui la maggiore
efficienza e' irrinunciabile. Secondo, milioni di linee di codice C++ in
giro per il mondo. 
-- 
God is Real, unless declared Integer.
ObjectZone - 
http://space.tin.it/computer/csadun

 giro per il mondo.
quindi: sotto con il C++? (volevi dire questo??)
Stefano

:

No, sotto con entrambi. :)


source o da bytecode?
Il gcc ha un front-end per il java (mi sembra gcj).
--
 (o-  | c:\> win2000patch001.exe
 //\  | This Microsoft(c) patch fix all bugs present. All rigth reserved.
 V_/_ | Insert Linux boot disk to continue ... loading kernel ...
http://pinguin.linuxbox.com
 r.salmaso(at)
flashnet.it

 giro per il mondo.
Certo, ma nessuna di queste due considerazioni suggerisce
che sia minimamente sensato per un "principiante che vuole
imparare un linguaggio di programmazione" mettersi a studiare
il C++.
Eventualmente potra` venir buono come terzo o quarto
linguaggio, SE l'ormai-ex-principiante si trovera` a
dovere spingere le prestazioni al 100% ovvero a fare
la manutenzione di codice esistente (per quest'ultima
ragione e` piu` facile che gli servano il Cobol, il
Basic, il Fortran, eccetera, linguaggi nei quali molti
PIU` "milioni di linee di codice" sono "in giro per
il mondo").
In un certo senso parlo contro il mio stesso interesse,
perche` noi (sostanzialmente per le due ragioni che dici,
piu` altre secondo me meno valide) siamo sostanzialmente
imperniati sul C++; piu` programmatori troviamo, che siano
pienamente competenti su questo orrendamente difficile
linguaggio, meglio e` per noi, ovviamente.
Ma secondo me il futuro (anche nostro...!) e` degli
*ambienti multi-linguaggio*, imperniati cioe` sull'uso
di componenti sviluppati in molteplici linguaggi diversi,
ciascuno per i compiti ad esso piu` adatti. In un quadro
come questo il C++ potra` avere il suo spazio (per il
codice antico pur sempre in manutenzione, cosi` come lo
avranno Cobol, ecc; per il codice che richiede massime
prestazioni, cosi` come lo avranno l'Assembler o l'HPF),
ma non certo il ruolo del protagonista, che sara` invece
piu` probabilmente giocato da linguaggi meno astrusi e
piu` "umani" (Java, forse, ma anche Delphi, Basic di
qualche tipo, ML di qualche tipo, Python...), senza poi
scordare i linguaggi specializzati (come SQL e suoi eredi)
che anche oggi svolgono ruoli del tutto cruciali; linguaggi
che, ciascuno nel suo ambito, massimizzano la _produttivita`
di ciclo-di-vita del programmatore_, parametro cruciale
nel determinare il costo di produzione e manutenzione del
software.
Per cui, i miei consigli ai principianti della
programmazione sono, e restano: Delphi, Java,
Python, magari Visual Basic (un po' becero e burino,
OK, ma pragmaticamente puo` tornare utile!-), linguaggi
piu` facili, meno ostici, non meno utili; per C++, se
vi occorrera` o vi interessera`, ci sara` tempo poi.
Alex

vi occorrera` o vi interessera`, ci sara` tempo poi.
Eheh no problem. Teste diverse, opinioni diverse. Io un bel progettino in C++, 
niente di troppo grande, ma giusto per prenderci un po' la mano, lo 
consiglierei. Questo perche', nella mia esperienza, di puntatori, reference, 
stream, templates e compagnia cantante al principiante non basta leggerne: ci 
deve pasticciare un po'. E pasticciarci imho serve: la differenza tra un 
programmatore solo visual basic, e uno che ha pasticciato un po' con C++, nella 
mia esperienza, si vede. Senza nulla togliere, s'intende, al programmatore 
visual basic.


Mi chiedo: il Java è + portabile perchè ha nello standard funzioni che il
C++ standard non ha, ad esempio accesso ai database e socket. Però su
windows/linux quanti hanno installato l'interprete per farci girare i
programmi? E poi col Java si possonno usare le api (sia di linux che
windows)?
Ciao e grazie
-=Azathoth=-

Se il futuro è di Java tanto vale puntare su quello....o no??
Questo dipende da quello che devi fare, non esiste ancora un linguaggio
che sia in assoluto e sempre la scelta migliore per ogni situazione. In
genere la scelta del linguaggio e' determinata dal problema
che si vuole risolvere e dai vincoli che vi ruotano attorno.
Paolo

windows)?
Non essendo un programmatore java, non saprei dirti, ma penso che
non sia possibile, almeno non senza perdere la portabilita' (cosi'
come in C/C++)
Paolo

 windows)?
Non in modo portabile, certo, se non attraverso le librerie
standard Java che a loro volta appoggiano sulle API delle
specifiche piattaforme.  Si possono pero` avere (a prezzo
della portabilita`) metodi con "implementazione nativa", che
risiede in DLL preparate in C secondo gli standard JNI (o,
sulla VM Microsoft, in qualsiasi DLL che esponga servizi via
COM o STDCALL).
Alex

 visual basic.
A parita` di tempo ed energia investiti, si puo` arrivare ad
avere una discreta padronanza di VB, Delphi, Java, _e_ Python,
*oppure* un livello equivalente ("discreta padronanza") nel
SOLO C++, che e` circa complesso come gli altri quattro messi
assieme.
Non vi e`, secondo me, alcun dubbio su quale forma di investimento
del proprio tempo ed energia abbia maggiori ricadute positive per
il principiante, sia a livello pratico sia formativo, fra queste
due alternative.
Meglio probabilmente sarebbe affrontare LA META` dello sforzo,
direi Java e Python (che nella versione JPython interopera alla
perfezione con Java, naturalmente), e dedicare il tempo cosi`
risparmiato ad altri temi: algoritmi, strutture dati, design
patterns, metodologie.  Questa opzione secondo me preferibile
non e` concessa, sempre a parita` di investimento totale di
tempo e di sforzo, dalla scelta "solo C++".
Secondo me l'effetto che tu credi di osservare relativamente a
chi "ha pasticciato un po' con il C++" e` dovuto solo alla
maggiore spesa di tempo e di energia che quest'ultimo ha dovuto
profondere per avere anche solo i rudimenti piu` banali del
C++; se lo stesso tempo, la stessa energia, fossero stati spesi
piu` produttivamente, il ritorno sarebbe stato migliore.
Alex

 come in C/C++)
Confermo.  Ma in C, o C++, non hai comunque alcun modo pienamente
portabile per l'accesso a database, eccetera, eccetera.
Alex

 che si vuole risolvere e dai vincoli che vi ruotano attorno.
Altrettanto sacrosanto.  Meglio imparare MOLTEPLICI linguaggi,
per non "fissarsi" troppo su specifici paradigmi di soluzione.
Il C++ puo` avere un suo spazio didattico in questa sequenza
(non certo al primo posto in ordine temporale), come di certo
lo hanno Java, Pascal in qualche variante, Python, un qualche
linguaggio tipo LISP (magari Scheme, oppure Common Lisp),
un qualche linguaggio tipo ML (magari OCAML), SQL (del tutto
irrinunciabile, cosi` come la teoria dei DB relazionali che
gli sta dietro), e altri linguaggi fuori dal mainstream, ma
molto istruttivi proprio per questo, come Icon, Dylan, Mozart,
Prolog, Smalltalk, e chi piu` ne ha piu` ne metta:-).
Attenti solo a non spendere TUTTO il tempo e l'energia a
disposizione a imparare linguaggi, perche` moltissimi elementi
dell'informatica sono piu` importanti dell'N+1-esimo linguaggio:-).
Alex

 dell'informatica sono piu` importanti .......
Potresti elencarne qualcuno  ?   ;-)
Stefano
.......dell'N+1-esimo linguaggio:-).

 istallazione di Netscape, di Internet Explorer, di molte >altre
applicazioni ancora.
Dunque, senza avere installato il jdk, avendo un programmino in java (non
applet per browser) posso farlo girare? In parole povere: posso prendere
notepad, scrivere il sorgente e farlo funzionare senza jdk? Grazie.
-=Azathoth=-

 piu` produttivamente, il ritorno sarebbe stato migliore.
probabile. Ma chi puň dirlo?
-- 
Ugo
__________________________________________________________________________
"La perfezione si ottiene non quando non c'č nient'altro da aggiungere, 
 bensě quando non c'č piů niente da togliere." Antoine de Saint-Exupéry


Qualche osservazione:
La complicazione del C++ e' anche cio' che da' a questo linguaggio
maggior potenza espressiva della maggior parte dei linguaggi citati e
forse il miglior rapporto tra potenza espressiva e diffusione.
Per una testimonianza sull'importanza della potenza espressiva del C++
vale la pena di leggere "Multiparadigm Design for C++" di J. O. Coplien.
Quali altri linguaggi o combinazioni di linguaggi oggi potrebbero
sostituire adeguatamente il C++ negli esempi del libro?
Che il C++ sia un linguaggio complesso non c'e' dubbio, e probabilmente
dispone di meno reti di salvataggio di linguaggi di complessita'
analoga, come Ada. Mi domando pero' se sia tanto piu' facile acquisire
competenza nei molteplici linguaggi necessari, a quanto pare dai
messaggi precedenti, per sostituirlo.
Se poi quello che interessa davvero e' la produttivita', penso che i
confronti tra linguaggi general purpose siano alquanto sterili di fronte
a generatori di applicazioni ed a soluzioni orientate a settori
specifici. Penso a prodotti come PowerBuilder, SAP o Forte' (per quel
poco che ne so).
Ciao,
Nicola

 sono daccordo.
Ne approfitto per farti i miei complimenti riguardo gli articoli sui
patterns presenti sul tuo sito, veramente chiari e ben fatti, e per
domandarti quando riempirai gli "slot" ancora vuoti.
EMG

piu` produttivamente, il ritorno sarebbe stato migliore.
Ipotesi interessante. Quindi mi dici che il C++ e' piu' complesso (tanto quanto 
gli altri 4 linguaggi messi assieme) pero' impararlo non da' sostanzialmente 
alcun vantaggio dato che nella stessa unita' di tempo imparare gli altri 4 
linguaggi darebbe risultati migliori. Dovrei indagare sulle tua nozione di 
"complessita'" e di "risultato migliore". Ma - scherzavo! - non e' importante. 
;-)
Saluti,
 -cs
-- 
God is Real, unless declared Integer.
ObjectZone - 
http://space.tin.it/computer/csadun/

 riferimento fa molta confusione)
Poiche` non puoi avere _altro_ che passaggio-per-riferimento (e
non vedo quale confusione questo termine possa causare, visto che
e` un termine classico della scienza informatica, talmente ben
noto da essere divenuto persino una keyword in linguaggi con una
diffusione di massa, come Visual Basic -- vedi i ByVal e ByRef
di quest'ultimo), non puoi agevolmente esemplificare la *distinzione*
fra i due casi, per-riferimento e per-valore, come potresti fare
in C++, in Visual Basic, eccetera.
E` come dire che in C++ non puoi esemplificare entrambi gli approcci
fondamentali alla gestione delle eccezioni, "terminating" e
"restartable", visto che la semantica delle eccezioni C++ e`
solo, sempre, e rigorosamente "terminating".  Non vuol dire che
sia un errore del linguaggio avere fatto questa importante
semplificazione semantica, solo che nessun singolo linguaggio ad
alto livello ti permette di esemplificare TUTTO (non a caso Knuth
si e` sempre rifiutato di "tradurre" a qualsiasi linguaggio di
alto livello il suo capolavoro "The Art of Computer Programming",
che infatti continua ad oggi ad avere tutti gli esempi in una
specie di assembler artificiale).
Alex

 Potresti elencarne qualcuno  ?   ;-)
Gia` fatto in tanti altri post, comunque ti consiglio
di acquistare "The Art of Computer Programming", di Knuth;
come "linguaggi" ci troverai solo uno strano "assembler
artificiale", usato proprio perche` nella sua assoluta
poverta` non "maschera" nessuna delle problematiche da
illustrare; troverai invece un primo, interessante insieme
di "elementi dell'informatica piu` importanti" che non sia
imparare l'N+1-esimo-linguaggio di programmazione.
Brooks, "The Mythical Man-Month", e` un altro testo assai
consigliabile, e di lettura molto piu` agevole, su ALTRE
classi di "elementi dell'informatica" molto importanti.
Ed e` solo l'inizio...
Alex

 curata dall'OMG. Come immagino tu sappia, e immagino tu abbia usato una
frase
No, IDL non e` UN linguaggio, ma piu` di uno; l'IDL (Interface Definition
Language) di Corba, e quello di COM, in particolare, entrambi identificati
come "IDL" in ogni verso, differiscono parecchio (il secondo e` una
estensione di un altro IDL ancora, quello del DCE-RPC dell'OSF, piu` antico
di entrambi; non conosco invece l'esatta genesi storica dell'IDL OMG).  E`
quindi giusto dire "gli IDL", se si vuole fare riferimento ai vari linguaggi
di questo insieme, ben distinti pur nelle loro simiglianze.
Non esiste UN IDL, piu` di quanto non esista UN "modo di fare un
buon programmatore".  Il che ci riporta al punto fondamentale.
Ho sempre sostenuto che persone diverse apprendono ottimalmente
in modi diversi, _particolarmente_ per quel che riguarda una
delle scelte fondamentali relativamente al "primo linguaggio di
programmazione da apprendere": linguaggio RIGIDO, che "guida" il
piu` possibile lo studente lungo binari ben definiti, come il
Pascal e i suoi eredi; oppure, linguaggio FLESSIBILE, che al
contrario permette di "smanettare sin da subito", conducendo ad
uno stile di studio meno accademico e piu` interattivo, come ad
esempio Smalltalk.  Senza dubbio un "programmatore maturo" sara`
familiare con ambo i tipi di approcci (e capace di scegliere il
migliore per un dato problema), ma la "vexata quaestio" riguarda
quale dei due sia megli PER INIZIARE.  La mia tesi in merito e`
che DIPENDE DALLO STUDENTE -- dal suo carattere, nel senso piu`
lato del termine.  E l'ho sostenuta tante, tante volte.
Che per certe questioni "da guerre di religione" io ritenga che
non esiste UNA soluzione unica, non significa che la pensi allo
stesso modo per TUTTE le questioni, piu` o meno fra loro
"perpendicolari", che conducono alla scelta di una metodologia
di studio (o piu` in generale di formazione).
In particolare, penso che, nell'informatica come in ogni altro
settore, di persone che (per carattere, formazione, cultura
nazionale, chissa`) sono facilone e superficiali, ce ne siano
sin troppe; il mercato e` saturo.  Pessima idea, dunque, cercare
di incoraggiare la formazione di altre ancora di queste persone.
L'approccio al "C++" (e le virgolette sono d'obbligo) di cui CS
si fa campione e`, a mio vedere, proprio l'epitome di questa
"pessima idea".  "Un progettino C++", fatto usando circa il 10%
o meno delle potenzialita` del C++, "tanto per farsene una
infarinatura", mi sembra un PESSIMO modo di iniziare a muovere
i primi passi nell'informatica.  La "conoscenza" (virgolette, ci
vorrebbero, quintuple) cosi` acquisita sara` per definizione
totalmente facilona, totalmente superficiale.
    A little knowledge is a dang'rous thing,
    Drink deep, or taste not, the Pierian spring
(citando, me lo si perdoni, a memoria:-).  Meglio, molto meglio,
scegliere un ambiente PIU` SEMPLICE, e svilupparne una RAGIONEVOLE
PADRONANZA, che non scegliere il piu` complesso di tutti, per poi,
ovviamente, finire per "infilarci appena appena l'alluce per
sentire se l'acqua e` fredda" (a parita` di tempo ed energia
a disposizione per l'apprendimento).
CS porta, a principale sostegno delle sue tesi, le sue esperienze
in termini di selezione e formazione del personale.  Le mie sono
del tutto diverse, e qui si lavora in C++: ho spesso rilevato come
una persona che inizia con una BUONA competenza in un paio di
linguaggi (dei piu` disparati, dal Pascal al Concurrent Prolog)
e` assai piu` facile e rapida da portare ad un buon primo livello
operativo in C++, di quella che arriva invece con una "infarinatura
di C++", livello "da libro di Schildt", per intenderci; se non altro,
non ha da DIS-imparare un tot di sottili errori in merito.  (In effetti
fra le esperienze di formazione piu` ardue ci sono state quelle di
persone arrivate con OTTIME competenze di C -- e nozioni scarse e
molto superficiali di C++; queste persone CREDONO di sapere gia`
un tot di cose, di approcci operativi, e invece devono disimpararli
per lavorare bene in una "squadra" orientata appunto al C++).
Alex

 
Ne crea, ne crea. Questa del passaggio per riferimento è una "common
misconception", così come viene definita nei testi d'oltreoceano, e
nasce dal fatto che gli "oggetti" java sono degli "object reference" (in
breve handle). Sono cioè puntatori "classici", che vengono però trattati
come "oggetti". La maggior parte dei principianti java utilizza questa
approssimazione (handle = oggetto), che però non è calzante in tutti i
casi.
In realtà è tutto molto semplice: in java tutto viene passato per
valore, e nulla per reference, ed infatti non c'è bisogno di nessuna
keyword aggiuntiva come in VB. Il fatto che un "handle" sia un reference
però crea comportamenti diversi fra i tipi base e i tipi complessi,
poichè viene creata una copia per valore di un puntatore, che,
"puntando" allo stesso oggetto, crea la semantica di cui parli. Se gli
"oggetti" fossero passati per riferimento, questo implicherebbe che un
"oggetto" java di per sè dovrebbe essere un qualcosa di più concreto di
un semplice puntatore, e ti porterebbe a difficoltà nell'esemplificare
la semantica anche di un semplice assegnamento:
a = b;
Questo è per valore o per reference?
 
Vedere "Thinking in Java" di Eckel o "Practical Java" di Haggar per
ulteriori delucidazioni in merito.
ciao
-- 
Ugo
__________________________________________________________________________
"La perfezione si ottiene non quando non c'è nient'altro da aggiungere, 
 bensì quando non c'è più niente da togliere." Antoine de Saint-Exupéry


[...]
Sono contento che anche tu ritieni che non ci sia un solo modo d'imparare. Il 
che - mi pare - e' il succo essenziale del discorso. 
Il resto e' fumo, o opinione. Io non bollo di "errori" o "assurdita'" chi ha 
opinioni diverse dalle mie, ma ognuno, del resto, ha il suo stile, e il mondo 
e' bello perche' e' vario, almeno su un ng. 
Per quanto riguarda IDL, chiunque e' in grado di inventarsi o riusare un 
acronimo e appiccicarlo a quello che vuole. Microsoft, in particolare, tende a 
farlo tre volte al mese. Ci ha provato, guarda un po', anche con Java - 
attaccando il nome a qualcosa che Java non era.
Io mi baso sulla letteratura: con IDL, nella stragrande maggioranza dei casi si 
intende OMG IDL. E' se si intende qualcos'altro, che occorre precisare. A 
parte, probabilmente, nelle pubblicazioni Microsoft.
Del resto, ho giusto scoperto chiaccherando con un collega che IDL e' anche 
"Interactive Data Language". Hmm, un'altro "errore clamoroso" come quello su 
PL/1? :)
Detto questo, i giochi a chi ce l'ha piu' lungo mi hanno sempre fatto 
sorridere, quindi mi fermo qui. 


:

No. Una JVM e' in grado di *eseguire* bytecode java. Ma per compilarlo a 
partire dai sorgenti, hai bisogno di un compilatore. Il JDK e' un "DK" 
(development kit) proprio perche', oltre alla macchina virtuale, contiene un 
compilatore java, e vari altri strumenti utili allo sviluppo.
La JVM Microsoft (jview e wjview) peraltro e' 1.1, e in alcune parti 
incompatibile con la specifica standard (per essere equilibrati, a volte da' 
semplicemente un'interpretazione diversa da quella Sun a parti specificate in 
modo ambiguo) o incompleta. Ad esempio, RMI richiede una patch apposita per 
funzionare con Internet Explorer. Puoi dare un'occhiata ai forum su 
http://java.sun.com
 per notizie su problemi specifici. Data la tecnica di 
resolution e linkage di Java, cio' non e' necessariamente un ostacolo - una 
classe java compilata puo' funzionare o meno a seconda di cosa fa e di quali 
features usa. Se usa features 1.2, con ogni probabilita' non funzionera'.


 dei casi si intende OMG IDL. 
Mi spiace contraddirti ma la definizione di IDL e' data dal contesto 
e non dalla "stragrande maggioranza dei casi".
In ambiente corba vale l'IDL OMG, in ambiente COM vale l'IDL COM.
Entrambe le tecnologie possono essere utilizzate in ambiente
distribuito e possono interagire. Quindi meglio chiamarle 
con il giusto nome. 
Per quanto riguarda la "paternita'" del nome IDL, l'OMG e' nato 
nel 1989. Se non ricordo male (ma potrei sbagliarmi) l'RPC era 
gia' fuori.
Fausto

 PL/1? :)
No, un caso tipico di "overload"; succedono spessissimo nel mondo
dei TLA.  I "morti per IRA", ad esempio (a seconda del contesto, ma
anche quello spesso non chiarisce appieno), possono essere gente che
si e` arrabbiata troppo, vittime del terrorismo, o poveracci a cui
hanno fatto difetto i reni *o* la respirazione...
Sul PL/I (e invito tutti gli interessati a leggere le FAQ che possono
trovare a 
ftp://rtfm.mit.edu/pub/usenet-by-hierarchy/comp/lang/pl1/
)
la Q9 cui ti riferisci risponde...:
"""
     There is some controvesy [SIC] over the name -- whether it is PL/I
     or PL/1.  The first manuals (for the first compiler, the
     IBM PL/I (F) compiler) called it PL/I, not PL/1. The ANSI
     standard calls it PL/I.  The title of the first reference
     manual is:
     "IBM System 360 PL/I (F) Language Reference Manual", 1966.
"""
In altri termini, chiamare il linguaggio "PL/1" (con la cifra invece
della lettera dopo la barra) e` come chiamare il "C++", che so,
"C**": una violazione sia della storia (perche` storicamente il
linguaggio e` nato con il nome in una ben precisa grafia) sia degli
standard ufficiali (solo ANSI, credo, nel caso del PL/I; ISO, nel
caso del C++).  Come chiamare un certo altro linguaggio "Giava"
(anzi, peggio, perche` di standard *ufficiali* per Java non ce
ne sono [ancora], purtroppo; solo pseudo-standard *proprietari*).
E quindi, ribadisco, _errore clamoroso_.  Che ci sia in merito
"some controvesy" (anche inserendo una R fra E ed S:-) non cambia
le cose: anche sulla esistenza e gli scopi dei lager nazisti "c'e`
controversia", ma cio` non mi impedisce di ritenere che chi
fomenta queste controversie stia (come minimo, per essere benevoli)
commettendo errori clamorosi.
Se qualche produttore commerciale vuole chiamare un certo suo
prodotto "Giava" o "Bazic", o "G++" o "Fortetran", ecc ecc, saranno
sue scelte di marketing (posso ritenerle cretine e controproducenti,
ma di marketing so di non essere un esperto) ma non toccano per nulla
il fatto che i VERI nomi dei linguaggi in questione sono e restano
"Java", "Basic", "C++", e "Fortran".  E lo stesso, naturalmente, vale
per "PL/1", "Kobol", "Essequelle" o altri storpiamenti a piacere.
Alex

 notepad, scrivere il sorgente e farlo funzionare senza jdk? Grazie.
La JVM esegue file-oggetto, di tipo .class (o loro impacchettamenti), NON
file-sorgente; devi disporre di strumenti atti a produrre i .class che
ti servono, e questi strumenti tipicamente fanno parte del JDK.
Alex

 gia' fuori.
Si`, RPC e` un concetto assai precedente al 1989.
http://www.faqs.org/faqs/dce/faq/
 chiarisce alla 1.09:
"""
Q 1.09:  Is DCE IDL the same as all the other IDL's in the world?
A:
    No.
    IDL stands for "Interface Definition Language," and the idea
    of using a special language to define the interface between
    entities is not unique to DCE.  In particular, OMG's IDL for CORBA
    is used for the same purpose as DCE's, but the two languages
    are not identical; see Q 1.08 for more information.  There are
    other Interface Definition Languages as well.
    IDL also stands for "Interactive Data Language", which
    is a completely unrelated product.
"""
Alla 1.08 ci sono varie note interessanti sui rapporti fra il DCE
(e di consequenza OSF, X/Open, Open Group, in vari periodi) e l'OMG.
Alex

[...]
Chi ha voglia di intendere, ha gia' inteso. Il resto e' bandwith waste.


gia' fuori.
Non ti sbagli.
Una nota interessante su questi discorsi (e sul perche' li trovo in genere 
piuttosto pedanti, e soprattutto inutili) e' relativa alla semantica di tali 
acronimi.
Cosa intendi per "remote procedure call" e "RPC e' fuori"? Il concetto? La 
prima implementazione? La prima implementazione *di successo*? La prima 
implementazione di successo in una certa piattaforma? La prima implementazione 
standardizzata? La prima implementazione standardizzata dall'ANSI? o dall'ISO?
Con sigle e acronimi, tutto sta ad intendersi. Meglio, a *volersi* intendere - 
che di solito non e' difficile, al di fuori dei dipartimenti marketing.
Altrimenti, ogni post dovrebbe diventare come un'enciclopedia, con note 
esplicative e rimandi opportuni. 
Pedante, appunto. 


 esplicative e rimandi opportuni.
Appunto, e' il contesto che determina il significato. Quindi se il 
contesto e' troppo vago, meglio specificare. E' ovvio che se parliamo 
di un progetto COM o CORBA ove il soggetto e' ben chiaro, inutile
ripeterlo.
Fausto

 Remote Procedure Call, tanto per chiarire i TLA in gioco, una tantum).
Del che c'e' poco da scandalizzarsi, visto che OSF aveva appena fregato
alla Sun (o all'Unix International) l'acronimo RPC. D'altronde erano i
tempi in cui gli stupidissimi produttori di sistemi Unix si facevano la
guerra, lasciando spazio ad NT...
Ciao,
Nicola

Conviene durante la stesura di specifiche.
Vero. Il che, ne converrai, non accade frequentemente in un ng. 


controvarianza.
Covarianza...non controvarianza. Se non ricordo male, B. Meyer ha
dimostrato che la programmazione generica e' un sottoinsieme della OOP
in un linguaggio con covarianza.
Comunque in merito ai template, covarianza e controvarianza, consiglio
la lettura dell'articolo di C. Pescio ("Programmazione ad oggetti e
programmazione generica") pubblicato su computer programming N. 62.
Non esaurisce l'argomento, ma fornisce preziose indicazioni in merito ai
differenti approcci seguiti da OOP e GP ed i loro limiti e vantaggi in 
C++.
Esiste la possibilita' che detto articolo sia disponibile anche alla
home page dell'autore... ma non ricordo l'indirizzo.
Paolo

per non "fissarsi" troppo su specifici paradigmi di soluzione.
Purtroppo imparare (bene) piu' linguaggi e' una operazione
che come tu stesso fai capire, richiede molto tempo. Molto meglio
spendere tale tempo in altre cose decisamente piu' importanti.
Personalmente pur utilizzando armai da tempo esclusivamente il C++
(in verita' al momento uso anche CLIPS, che ha poco a che vedere col ů
LISP), ho avuto una forte esperienza in pascal, qualcosa di basic (ai
 tempi dei commodore vic20, c16 e c64), lisp, e un minimo di assembly e
prolog + altri linguaggi visti piu' o meno velocemente a lezione anni
fa.
Oggi preferisco di gran lunga l'approccio OO, e in C++ uso i template
per rimediare ad alcune carenze del modello OO del C++.
Medito da tempo lo studio di Java, impegni permettendo...
Paolo

 home page dell'autore... ma non ricordo l'indirizzo.
 
http://eptacom.net/pubblicazioni/pub_it/oopgen.html
Max

 home page dell'autore... ma non ricordo l'indirizzo.
http://www.eptacom.net
-- 
Ugo
__________________________________________________________________________
"La perfezione si ottiene non quando non c'č nient'altro da aggiungere, 
 bensě quando non c'č piů niente da togliere." Antoine de Saint-Exupéry


 home page dell'autore... ma non ricordo l'indirizzo.
Dovrebbe essere questo:
http://www.eptacom.net/artic/Pescio
EMG