Newsgroup: it.comp.java
Titolo: java meglio di c++?

--
Su diversi libri ho letto che JAva è migliore del c++ poichè maggiormente
orientato all'esecuzione dinamica.
Cosa vuol dire?

 ha scritto nel messaggio
news:IaWE7.7579$sq5.4...@news.infostrada.it...


A mio avviso, Java ha in più del C++ "solo" migliaia di classi che ti che la
Sun a messo a disposizione e la possibilità di scrivere applicazioni
web-oriented. Per il resto, perde su tutti i fronti... C'è che dice che Java
è meglio di C++ perché è tutto OOP, ma a parte che la OOP di Java è maniera
meno solida che in C++, C++ offre ANCHE la OOP, quindi non sei obbligato a
usare SEMPRE le classi. E poi Java è di una lentezza incredibile... va be
che deve essere interpretato per essere cross-platform ma allora non fate
applicazione stand-alone... non capisco perché Sun lo abbia usato per
scrivere "Forte"... per avviarsi ci sta un sacco! In definitiva... se vuoi
imparare uno dei due linguaggi, passa a C++, che poi Java ti viene un gioco;
non è vero il contrario invece. Se invece vuoi qualcosa per applet, dai
un'occhiata al linguaggio Jython. Java è una gran fregatura, forse tutti lo
usano perché vogliono farlo diventare il linguaggio dei telefonini e
apparecchi vari... io (purtroppo) lo sto studiano perché all'uni il prof. ha
scelto questo linguaggio per insegnare a programmare (sarebbe stato meglio
Pascal, infatti la prima email che gli ho spedito era di protesta in merito
alla sua scelta).
Ciao
--
Luigi
http://web.tiscali.it/luigi_web
byte...@hotmail.com
ICQ 46240443

 alla sua scelta).
Non so gli altri, ma io penso che con questo dovrai attendere a lungo la
prossima risposta ai tuoi quesiti...
Baci, Juda.

La diatriba è abbastanza sciocca e infantile.
Non ha alcun senso chiedersi se è meglio java o C++ piuttosto che un'altro
linguaggio. Nella vita reale esistono tantissimi scenari in cui si può
scrivere una applicazione, per i quali esistono linguaggi più o meno adatti.
Se un giorno ti confronterai con il mondo reale, quindi scrivere programmi
per risolvere problemi specifici e non per purismo didattico, scoprirai che
conviene non storgere troppo il naso sul linguaggio da adottare.
Ciao, Marco


 scrivere una applicazione, per i quali esistono linguaggi piů o meno
adatti.
Infatti nel campo web, Java č migliore di C++.


 Baci, Juda.
???


> Non ho aperto io il thread. Ho detto solo quello che penso.
E io ho commentato quello che pensi.
Ho risposto in modo analogo anche a chi ha aperto il thread.
Ciao, Marco


...


 OOP di Java č maniera meno solida che in C++
definisci "solida". Perche' dal mio punto di vista, java in termini di
OOP e' decisamente meglio del C++. Via l'ereditarieta' multipla delle
classi (*), benvenuto alle interfacce...
Ma sai com'e'... ognuno viene da esperienze diverse e mi chiedo come
mai le tue ti abbiano portato a questa conclusione.
a presto,
Paolo Polce
London / UK
(*) un mio amico e collega irlandese, un gran bravo programmatore,
dice sempre "usa per quattro, cinque anni l'ereditarieta' singola su
un linguaggio che supporta la multipla (come il c++) e capirai perche'
la multipla non serve a niente, anzi e' solo un casino".
Sinceramente, sono d'accordo con lui.

 classi (*), benvenuto alle interfacce...
L'ereditarietà multipla secondo me è una buona cosa. Anche le classi della
libreria standard C++ ne fanno uso. La OOP di Java non mi piace molto,
perché sei costretto a usarla sempre (per quanto riguarda l'uso delle
classi) ed inoltre gli oggetti sono dei puntatori alla classe e questo crea
degli inconveniente ad es, nel momento dell'assegnamento da un'oggetto
all'altro, che li rende puntatori allo stesso oggetto. Almeno in C++ se vuoi
un effetto simile dichiari tu un puntatore alla classe. Invece in Java devi
fare per forza così e se non lo sai hai ovviamente grossi problemi. Io
studio da poco Java, e nel libro (ma praticamente ovunque) leggo che uno dei
punti di forza di Java rispetto a C++ è l'assenza dei puntatori... peccato
che hanno dimenticato a scrivere che il "male" non è assente ma è (peggio)
nascosto e non gestibile! Inoltre si possono creare classi base astratte (è
una domanda, io non lo so)? Oppure metodi virtuali? Se quest'ultimi non si
possono dichiarare, come si fa a gestire il polimorfismo? E poi cosa intendi
per interfacce? Solo la dicharazione dei metodi per poi definirli in
un'altro modulo?


nascosto e non gestibile! Inoltre si possono creare classi base astratte (č
addirittura ingestibile? ;)
a mio avvio conosci java da troppo poco per poterlo confrontare con C++
ciao_O
_______________________________________
http://jame.sourceforge.net
 
[ last release jame4.2e ]
_______________________________________
http://digilander.iol.it/schiele

a mio avvio conosci java da troppo poco per poterlo confrontare con C++
a mio avviso...


Si, č da poco che lo uso.
Tu conosci C++?


 un'altro modulo?
L'interfaccia è un concetto basilare nella progettazione OOP. Non solo in
Java.
Ciao, Marco

 Java.
Si, ma cmq l'interfaccia è in sostanza la dichiarazione dei metodi, che
viene separata dalla definizione (implementazione). Ma non capisco come
questo possa sostituire l'ereditarietà multipla...


 questo possa sostituire l'ereditarietà multipla...
Perchè le stesse interfacce vengono "implementate" da più classi senza alcun
problema.
Sono costruite per questo.

 questo possa sostituire l'ereditarietà multipla...
Infatti non la sostituisce. Al limite le classi possono implementare più di
una interfaccia, che non è assolutamente la stessa cosa.
In questa parte il comportamento di java è più vicino alla corretta
interpretazione della OOP. Ritengo che in java l'ereditarietà multipla sia
stata esclusa volutamente e con ragione, è una tecnica che in fase di
progettazione software fa casino e basta.
E non è un parere solo mio.
Ciao, Marco

 possono dichiarare, come si fa a gestire il polimorfismo? 
Vorrei sapere con queste poche conoscenze (non ti offendere ;-)) come
fai a paragonare C++ e JAVA.
Allora... 
Le interfacce definiscono il "comportamento" di un oggetto...
un tizio che canta probabilmente implementa la interfaccia "cantante",
di cui scrive il metodo "canta(brano)" che nell'interfaccia e'
astratto.
Un tizio con la passione per le immersioni, probabilmente implementa
l'interfaccia "sommorzatore".
Uno a cui piacciono entrambe le cose si puo' definire tipo
class Tizio extends Uomo implements cantante, sommorzatore.
Et voila'... eccoti quello che la ereditarieta' multipla vorrebbe
fare, ma che per fare combina solo casini.
Polimorfismo? Come sai ci sono due tipi di polimorfismo: quello delle
classi e quello dei metodi (meglio conosciuto come overload).
L'overload funge come in C++ (non mi vengono in mente differenze, ma
e' l'una di notte ed ho bevuto almeno cinque birre ;-)) ).
Il polimorfismo fuziona con Classi e interfacce...
Es... ho una classe Morph che mi trasforma un uomo in qualcosa di
diverso
// con classi
class Morph {
public void trasforma(Uomo unUomo);
}
ovviamente gli puoi passare il tizio di prima come parametro...
// con interfacce
ho una classe che fa diventare soprano qualsiasi cantante (nota che
non devi esser uomo per cantare, potresti essere un uccello... vedi
l'importanza delle interfacce)
class sopranatore { // bel nome, eh?
public void sopranizza(cantante unCantante);
}
qui gli puoi passare sia il tizio di prima sia un qualsiasi altro
oggetto che implementa l'interfaccia cantante (un canarino, magari).
Spero di averti chiarito un po' le idee.
Se ti piace la programmazione ad oggetti, studia meglio il java, lo
apprezzerai. Io ormai mi sono fissato con la programmazione per
composizioni. Con java mi riesce molto facile scrivere test per le mie
applicazioni prima ancora di scrivere il codice vero e proprio.
Con c++ e' davvero una rottura.
Tuttavia, come dicevo a chi ha cominciato il thread (Luca?), ci sono
occasioni in cui c++ e' piu' adatto.
A presto,


classi e quello dei metodi (meglio conosciuto come overload).
Ce ne sono quattro :
Coercion, Overloding, Polimorfismo per inclusione (Overriding),
Polimorfismo parametrico (in Java non c'e', ma serebbe bello averlo)
[cut]
Per concludere (IMHO):
Nessun linguaggio e' meglio di un altro in senso assoluto, e' una
questione di valutazione del problema, e delle capacita/conoscenze
del/dei progettista/progettisti. Tutto quello e' stato fatto in Java,
lo si puo' tradurre in C++ senza cambiare troppo l'architettura della
soluzione, il contrario non e' sempre vero (anzi); il C++ e' molto
piu' espressivo di Java, e permette piu' paradigmi di programmazione
utilizzabili contemporaneamente!!! Questa potrebbe essere indice di
potenza o di sicuro fallimento, questo dipende da chi usa il
linguaggio. Infatti come tutti sappiamo in linguaggio di per se non fa
niente, si deve sempre vedere chi lo usa.
Scusate per le divagazioni filosofiche
[}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{]
SunGray aka Gabriele Lana  
www.sungray.com
contact me @ : 
sun...@tiscalinet.it
[}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{]

 in maniera mutuamente esclusiva, 
Non sono d'accordo sul principio, perche' (come anche da te affermato)
e' raro, ma ancor peggio credo sia indice di un errato approccio al
problema.
Se un oggetto deve "fare qualcosa", dal mio punto di vista vuol dire
che bisogna creare un interfaccia che definisca quel comportamento.
Se si vogliono fare piu' cose, piu' interfacce... ma ripeto, vedo
davvero remota la possibilita' di derivare da due classi, credo sia il
modo sbagliato di comporre gli oggetti. (ovviamente il "IMHO" e'
sottinteso :)).
Ti diro' di piu', anche in ereditarieta' singola, se un mio oggetto e'
il derivato di un derivato, mi comincio a preoccupare... penso di aver
identificato male qualcosa...
Oggetti molto molto piccoli si compongono in maniera molto pulita e ti
danno la possibilita' di scrivere ottimi test per la tua applicazione
(vedi eXtreme Programming & MockObjects).


Tu conosci C++?
si e non mi piace


 un'altro modulo?
Forse prima di esprimere un giudizio dovresti approfondire la conoscenza di
Java.
Francesco Ciani

 E non è un parere solo mio.
Già


 composizioni.
In che senso?


 Polimorfismo parametrico (in Java non c'e', ma serebbe bello averlo)
Quale sarebbe il Coercion?
E il polimorfismo parametrico non è l'overloading dei metodi?
Grazie


(vedi eXtreme Programming & MockObjects).
Per applicazioni piccole/medie puo' andare bene, ma prova a progettare
un framework come quello della libreria standard di Java, senza
ereditare da una classe in cascata per piu' di due volte. Per
applicazioni medio/grandi, situazioni di questo tipo capitano spesso!!


E il polimorfismo parametrico non è l'overloading dei metodi?
no, si ha con la metaprogrammazione template


 no, si ha con la metaprogrammazione template
Puoi farmi un'esempio? (Anche se siamo nel NG sbagliato... oppure on PVT)


 più di una interfaccia, che non è assolutamente la stessa cosa.
Una cosa interessante, che spesso ho trovato non e' evidente a chi
fa 'sti discorsi (che peraltro imho lasciano sempre il tempo che
trovano... il linguaggio perfetto e' sempre il prossimo ;-), e' che in
Java l'ereditarieta' multipla esiste *sulle interfacce*. 
Un'interfaccia puo' ereditare di piu' d'un altra - provare per credere.
:-) Questo perche' al solito l'ereditarieta' e' meglio usata
semplicemente per indicare un'associazione isA - non per fattorizzare
implementazione. 
Cio' detto, resta il 5% di casi in cui si vorrebbe ereditarieta' multipla
su classi, e il design equivalente basato su interfacce, classi astratte
e delega e' meno efficace ed elegante. 
Pragmatico, appunto. Anche se ogni volta che devo costruire qualcosa
compatibile con EJB *e* uso "normale", mi trovo in quel dannato 5%.. :-) 
-- 
Life's something u don't get out alive..
ObjectZone - 
http://space.tin.it/computer/csadun

 stand-alone piuttosto che web-oriented.
Sbagli. Il java è un linguaggio di programmazione a pieno titolo, con il
quale si può _anche_ fare (molto agevolmente) programmazione via rete.
Sicuramente è molto più agevole da usare del c++ ed ha un arma segreta
di cui nessuno stranamente ha parlato: le classi interne e le classi
interne anonime. Sono soprattutto queste che fanno fare un balzo
concettuale enorme rispetto al c++ e lo rendono molto più adatto in
contesti importantissimi come la gestione degli eventi (basta pensare
alla gui per tutti).
Saluti dalla Maison Ikkoku.

 Sbagli. Il java è un linguaggio di programmazione a pieno titolo, con il
Ma io non dico mica che essendo web-oriented non sia un linguaggio di
programmazione vero e proprio... lo so che non è javascript!
Ciao


 builder...
Già fatto. Proprio uno-due mesi fa ho realizzato una classe per
disegnare grafici. Accetta tante coppie (x,y), fa l'autoscaling, scrive
le quote, fa un sacco di calcoli e poi disegna (puoi disegnare fino a 5
grafici contemporaneamente). Ogni volta che cambi la dimensione della
finestra si riscala, puoi selezionare runtime diverse opzioni
(proporzionale sull'asse x, proporzionale sull'asse y, proporzionale ai
due assi), insomma, non è proprio un programma leggero dal punto di
vista dell'utilizzazione della memoria che dei calcoli.
Come dicevo la lentezza è solo all'inizio, al caricamento della vm.
Tutti i rescaling li fa in tempo reale, senza attese sconce. Tieni conto
che io ho solo un athlon 650 con 128M di ram, e lavorando a 1280x1024
persino quando faccio il maximize per andare a tutto schermo non devo
attendere più di qualche decimo di secondo.
Certo, probabilmente usando il c++ avrei potuto ottenere una routine
ancora più veloce, ma tieni conto che:
1) Non avrei avuto un prodotto multipiattaforma, in grado cioè di essere
usato "as is" su AIX, linux, Mac, Windows, ...
2) Mi sarei dovuto imparare tanti diversi contesti grafici: le API
grafiche di win, il libtool per ambienti unix (non tutti), le librerie
di vattelapesca per AIX, etc. etc.
3) Anche conoscendo perfettamente l'interfaccia grafica ci avrei messo
molto di più, non potendo usare quei meravigliosi strumenti che sono le
classi interne.
Tieni conto che i processori diventano sempre più veloci, la ram ormai
la vendono un tanto al chilo, i problemi di criticità temporali ormai
sono ridottissimi. Non stiamo più parlando del 486 dove se non
ottimizzavi tutto eri perdudo.
E poi, cazzo, il java _È_ ottimizzato! (per quello che fa) :-)
(ah, a chi fosse interessato posso mandare i sorgenti)
Saluti dalla Maison Ikkoku.

(ah, a chi fosse interessato posso mandare i sorgenti)
Io lo sono, se me li mandi mi fai un piacere!!!


 Io lo sono, se me li mandi mi fai un piacere!!!
Li metto qui in attach.
Togli solo la dichiarazione di package all'inizio dei file (si
riferiscono al mio classpath) e gli include a com.auryn.*. Mettili in
una stessa directory e compila... Se fai java Grafici parte un esempio.
Ah, non è propriamente rifinito e presentabile... ;-)
Saluti dalla Maison Ikkoku.

Ma come faccio a farlo funzionare?
Quale è quello principale da mettere nella pagina web? Devo poi compilarle
tutte e tre?
Grazie


 Quale è quello principale da mettere nella pagina web? Devo poi 
No, nessuna pagina web :-) (per la serie il java non è web-based). Li
metti in un unica directory, togli i riferimenti package e com.auryn.*,
li compili con javac e lo fai partire con java Grafici.
Così parte solo un esempio. Puoi poi usare la classe Grafici seguendo le
indicazioni nella documentazione (devi farle con il javadoc).
Saluti dalla Maison Ikkoku.