Newsgroup: it.comp.java
Titolo: Differenze Java-C# su wikipedia.

Guardate cosa c'è scritto riguardo alle differenze tra Java e C# su
Wikipedia (
http://it.wikipedia.org/wiki/C_sharp
).
Secondo me c'è qualcosa che non quadra....
Cosa ne pensate (è il caso di cambiarla)?
Ciao.

 Ciao.
-- 
Andrea Francia
http://www.andreafrancia.it/

Cosa ne pensate (č il caso di cambiarla)?
Magari se ci dici che cosa non quadra...

Lollo wrote:

io non trovo neanche il senso di fare un paragrafo "Differenze con Java"
-- 
Davide Consonni

 Davide Consonni
Se si parla a livello sintattico / semantico, non č che non lo trovi, il 
senso: non c'č. E' come voler illustrare le differenze tra il Tedesco ed il 
Greco classico. Se parliamo di architetture .NET vs J2EE, allora si puň 
discutere.
Scorpio. 


Perché no? A me sembra normale che ci sia. Così una persona che conosce 
uno dei linguaggi si fa un'idea di cosa c'e' nell'altro.
-- 
Andrea Francia
http://andreafrancia.blogspot.com/

uno dei linguaggi si fa un'idea di cosa c'e' nell'altro.
Le differenze tra linguaggi esistono ed č ovvio, ma fare un semplice
elenco come quello č poco utile, secondo me. Se mi limito a dire che
in C++ posso allocare oggetti sullo stack e in Java no, farei bene
anche ad approfondire tutte le implicazioni e conseguenze di questa
differenza (che spiegherebbe, tra le altre cose, i diversissimi
modelli di programmazione generica in C++, C# e Java, la diversa
applicazione dell'idioma RAII, ecc...).
Insomma, un elenco di differenze tra linguaggi puň essere piů o meno
interessante. Molto piů utile sarebbe approfondire le differenze.

 Scorpio. 


 interessante. Molto più utile sarebbe approfondire le differenze.
D'accordo. Ma wikipedia è anche generalista, certe aspetti troppo 
tecnici non dovresti metterli.
Comunque sono d'accordo che il contenuto del paragrafo così come è 
adesso è utile solo a chi si accontenta di un confronto superficiale, di 
argomenti piu' evidenti ad uno che ha poca conoscenza dei linguaggi.


 architetture, non è un architettura.
La filosofia che sta dietro a J2EE è diversa da quella che sta dietro a 
.NET, i runtime sono implementazioni....Per me, un'architettura è un po' il 
riflesso di una filosofia.
Scorpio.

 riflesso di una filosofia.
Ho come l'impresione che abbiamo un concetto diverso di architettura.


tecnici non dovresti metterli.
Che vuol dire? "generalista"?
Se tratti una materia tecnica, o lo fai per bene, o ti astieni.

 Ho come l'impresione che abbiamo un concetto diverso di architettura.
Beh, io qui sono stato molto ma molto sintetico.... ma mi piacerebbe davvero 
sapere cosa tu intendi per architettura.
Scorpio. 


Mi sembrava ci fosse scritto nelle linee guida di Wikipedia ma l'ho 
cercato è non l'ho più trovato. Forse me lo sono sognato.



Ecco forse quello che intendevo è scritto qui ma non ho avuto tempo di 
ricontrollare, magari mi ricordo male.
http://en.wikipedia.org/wiki/Wikipedia:Make_technical_articles_accessible


 Scorpio. 


ricontrollare, magari mi ricordo male.
Interessante. Credo però che quelle di Wikipedia siano delle semplici
raccomandazioni di buon senso. Non credo vogliano tarpare le ali a chi
desidera scendere nei dettagli di una particolare tecnologia; purché
lo sappia fare. Ovvio che un'enciclopedia dev'essere accessibile, però
in fin dei conti non stiamo parlando dell'orologio atomico, del moto
browniano o del sistema di controllo dell'Apollo.

 Ad esempio?
Differenze con Java  [modifica]
Sebbene C# sia ritenuto simile a Java, esistono alcune importanti
differenze fra i due linguaggi:
Java non gestisce le proprietà di una classe. (??)
Java non permette blocchi di codice "unsafe" che consentono di gestire
i puntatori. (OK)
Java utilizza i commenti Javadoc-sintax per generare la documentazione
dal codice sorgente, mentre C# utilizza la sintassi XML nei commenti
per lo stesso scopo. (OK)
C# non obbliga la gestione delle eccezioni (handle or declare)
(nemmeno Java.........)
C# supporta gli indicizzatori ed i delegati. (OK)
C# supporta l'overloading degli operatori (tranne quello di
assegnamento) (anche java......)
C# supporta le strutture, le cui istanze sono memorizzate nello stack
e che utilizzano implicitamente ed obbligatoriamente 'ValueType' (che
è derivato da object) quale tipo base . (OK)
C# di default non ha i metodi 'Virtual' come invece ha java. (mi
risulta che i metodi in C# siano Virtual di default come in
Java................)

 Java................)
Niente affatto. C# prevede (esattamente come C++) i metodi virtuali e non.
Perché un metodo sia considerato virtuale, deve essere specificata la
parola chiave "virtual".
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 assegnamento) (anche java......)
Secondo te Java supporta l'overload degli operatori?
Ma che versione stai usando la 8?


 la programmazione su sistemi operativi Microsoft.
Che sia riuscito come framework è fuor di dubbio, credo che la prima
cosa di cui avrebbe bisogno Java per poter riprendere parte del
terreno perduto sarebbe un Garbage colelctor e un gestore della
memoria più parsimonioso.
E poi procedere con una riduzione della libreria standard.
Ad esempio, trovare sia CORBA che RMI per le applicazioni distribuite
mi sembra ridondante, va bene la retrocompatibilità, ma mettere le
librerie utilizzate in modo meno frequente com librerie da far
caricare a runtime all'applicazione che le usa credo che possa giovare
Spero che il nuovo JDK faccia queste cose.
Non è una critica o simile, è solo un mio pensiero.
Ciao Marco

 penalizzante dal punto di vista delle prestazioni. 
Cosa c'entra l'overload degli operatori con le prestazioni?
L'overload degli operatori è puro zucchero sintattico, che ti permette 
di scrivere:
	c = a + b;
Al posto di:
	c = a.plus(b)


 caricare a runtime all'applicazione che le usa credo che possa giovare
Ma come rindondante? Alcuni applicazione hanno come requisito di *dover* 
usare RMI altre CORBA.
In Java ci sono vengono caricate solo le classi usate, e con gli Indezed 
JAR la velocità di caricamento non dipende neanche da quanto il JAR è 
grosso.


 penalizzante dal punto di vista delle prestazioni.
Non ci sono particolari complicazioni e non ci sono penalizzazioni dal
punto di vista delle prestazioni. Tieni presente che l'overloading degli
operatori è presente anche in C++, in cui c'è una grandissima attenzione
per le performance. Non sono neanche d'accordo con chi dice che, in
generale, l'operator overloading sia zucchero sintattico. In linguaggi
come C++, in cui c'è allocazione sullo stack e un tipo di programmazione
generica *VERAMENTE* generica, l'operator overloading è una funzionalità
molto utile. 


 sintattico. "Dietro le quinte" sono sempre chiamate a funzioni.
Il fatto che l'uso di un operatore mascheri un'invocazione a funzione non
implica necessariamente che l'overload degli operatori sia "syntactic
sugar".
Non lo è, infatti, in linguaggi come C++, il cui object model è diverso da
quello Java e in cui vige una programmazione generica (vedi i template)
degna di questo nome. Una classe template, in C++, non è tenuta a sapere
assolutamente nulla del typename a cui si riferisce; per esempio: lo
stesso codice, essendo generico, può agire efficacemente sia su tipi
built-in su cui sia prevista l'addizione, che su classi per le quali è
stata definita.



Si, ho risposto troppo frettolosamente: tutto vero quello che dici
(non conoscevo bene il fatto delle eccezioni checked ed unchecked), ho
fatto un confronto spannometrico (le differenze sintattiche non
comportano molte differenze di codice), i metodi non virtuali
introducono una possibilità di errore e quindi mi sembrava strano che
fossero presenti in C#, le proprietà di una classe costituiscono un
overload dell'operatore = appena differente da  quello tradizionale e
quindi, ancora, mi sembrava strana.
Comunque ho ragionato un pò sulla sintassi di C# e sono riuscito a
intuire la presenza di un precompilatore che lo ricondude molto
facilmente ad un linguaggio più pulito e + vicino al paradigma ad
oggetti (Java) (vedi anche i metodi delegate e gli eventi che in
realtà, sotto sotto, sono classi e interfaccie ironicamente ben
visibili in .NET).
Ciao.

 oggetti (Java)
Anziché "intuire", perché non sfogli un manuale? Insomma, se ci si arroga
il diritto di parlare di un linguaggio, che almeno lo si conosca. Non
capisco che cosa vuoi dire con "ricondurre". Poi, che Java sia più pulito
e più vicino al "paradigma ad oggetti" è tutto da vedere.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 


Non è una critica o simile, è solo un mio pensiero.
Foss'anche una critica, non vedo dove sarebbe il problema.E' giusto dire 
quel che si pensa.
Scorpio. 

 sistemi MS.
Quanto scrivi č vero, ma personalmente tendo a consigliare l'impiego di .NET 
proprio dove si
capisce che conviene avere una forte integrazione con il mondo Windows. 
Altrimenti, ancora
oggi, prediligo Java. Tolta l'integrazione con Windows, .NET IMHO perde 
molto del suo appeal.
Scorpio. 

oggi, prediligo Java. 
Anche io, ancora oggi. In linea di principio, perň, .NET non č
STRETTAMENTE legata a Microsoft. Ci tenevo a sottolineare questo.
L'apertura di Microsoft verso gli standard č effettivamente
straordinaria (nel senso che č fuori dall'ordinario ;-). Io credo che
addirittura la forza commerciali di Microsoft sia il suo stesso
tallone d'Achille: finquando c'č lei che sforna prodotti di sviluppo,
nessuno si imbarca in una concorrenza x-platform. Quanto fatto con
Mono č abbastanza coraggioso e mi fa piacere che lo sviluppo venga
portato avanti.

@ tutti
Chiedo venia, mi sono confuso sull'overloading degli operatori. Non so
per quale motivo mi sono fatto in testa i film in cui l'overloading
faceva tutt'altro... Devo dormire di +...
Ciao a tutti
Marco

 quel che si pensa.
E poi non è che la Sun si offende :)


 tallone d'Achille:
Il suo  = il tallone di .NET ?
Scorpio.

Il suo  = il tallone di .NET ?
di Microsoft

Dalle mie parti, salva la genericità di un'operazione siffatta, 
Non puoi dire "salva la genericità di un'operazione siffatta", perché
il succo del discorso sono proprio i template. In C++ io posso
scrivere genericamente una funzione del tipo:
template <typename T> T add( T a, T b) {
	return a+b;
}
La funzione non sa assolutamente nulla del tipo T.
Poi posso usarla, ad esempio, con un'istruzione:
	std::cout << add<int>(3, 4);
Oppure definendo una classe Number:
class Number {
	friend Number operator+(Number& lhs, Number &rhs);
	friend std::ostream& operator<<(std::ostream& os, const
Number& rhs);
public:
	Number(int x=0): _x(x) {};	
	private: 
	int _x;
};
Number operator+(Number& lhs, Number &rhs) {
	return Number(lhs._x + rhs._x);
}
std::ostream& operator<<(std::ostream& os, const Number& rhs) {
        os << rhs._x; 
	return os;
}
Posso scrivere:
	std::cout << add<Number>(1, 2);