Newsgroup: it.comp.java
Titolo: Comparazione Java vs C#

Salve a tutti,
supponiamo che dpbbiate iniziare un progetto, e dobbiate argomentare una 
vostra scelta in direzione di una o dell'altra tecnologia. Cosa direste?
E poi: quali sono secondo voi le differenze (che non siano 
necessariamente "preferenze") tra i due linguaggi?
Grazie,
il Petrux

 il Petrux
Saluti
Daniele De Francesco

 necessariamente "preferenze") tra i due linguaggi?
IMHO, Java e' piu' "maturo" (Ma non per forza piu' "evoluto").
-- 
Giambo - Occhio al filtro antispam _e_ alla whitelist !

 Salve a tutti,
[cut]
Rettifico: vorrei dare seguito a questo thread aperto tempo addietro su 
it.lavoro.informatica:
Ciao Vincent,
Vincent Vega ha scritto:
 > Fra java e c# si fa prima ad enumerare le ugualianze che non le
 > differenze.
Personalmente vengo da Java e sono approdato a C# quindi penso di
poterli paragonare "con cognizione di causa", senza voler dire quale sia
"il migliore", per carità!
 > In c# trovi effettivamente delle caratteristiche che denotano qualche
 > passo avanti anzichè indietro rispetto a java, dalle cose banali come
 > le properties all'overload degli operatori o le collections (già prima
 > dei generics c'erano le basi per fare le collection strong-typed, c'era
 > da scrivere un po' di codice ma almeno ci avevano pensato).
Giusto, anche se con l'avvento delle Generics le differenze per quanto
riguarda le collection si sono praticamente appiattite. Ma andiamo con
ordine. Dalla mia (seppur limitata) esperienza posso dire che:
- C# ha un meccanismo per gli eventi decisamente "interessante" (basato
in pratica sui delegate).
- C# permette l'overload degli operatori, a me ultimamente è tornato
parecchio utile.
- C# ha introdotto le properties, che permettono di sostituire i vecchi
metodi GetXXX() e SetXXX(...) con delle strutture molto più semplici ed
immediate; parallelamente permettono di esporre i campi di un oggetto
associando alle operazioni di lettura/scrittura di tali campi delle
operazioni "trasparenti" per l'utente.
- Java permette di (ad esempio) creare una classe base visibile solo
all'interno di un package, con membri visibili solo all'interno di un
package e farla ereditare da altre classi pubbliche, che mantengano tale
comportamento non esposto (non public, insomma), questo favorisce
*decoisamente* il riutilizzo del codice tramite ereditarietà.
- Lo sviluppatore Java ha a disposizione una marea di librerie di terze
parti oltre che quelle Sun (java.*).
Il discorso portabilità (che qualcuno nel thread aveva tirato in ballo,
ora non ricordo di preciso...) è relativo. IMHO le scelte politiche di
Sun e MicroSoft sono state quasi agli antipodi. La Sun ha scelto *un*
linguaggio che tramite una piattaforma portabile potesse essere usato
per scrivere software che girasse ovunque (il discorso Solaris, Win,
Linux può anche starci, fermo restando che Sun ha rilasciato già da
tempo le specifiche della JVM, dunque i vari Mac o BSD possono
svilupparsela per conto loro... che io sappia esistono diverse JVM oltre
a quella Sun). La MicroSoft ha scelto *una* piattaforma che gira su *un*
OS (escludendo il progetto mono, che non è certo targato MS) su cui
poter scrivere programmi in *più* linguaggi (C++,J# cio+ Java, VB, C#).
Portabilità sulla piattaforma vs portabilità del programmatore ;-)
Ciao,
il Petrux

> writes:
IP> - C# permette l'overload degli operatori, a me ultimamente è
IP> tornato parecchio utile.
L'utilità dell'overloading degli operatori e` un mito (falso).
Tutto  nasce  dal  fatto  che  usualmente  si  è  abituati  fin  dalle
elementari a  scrivere 2 +  2, ma  non appena 2  + 2 diventa  solo UNA
delle  notazioni  possibili,  l'overloading  degli  operatori  diventa
zucchero sintattico.
-- 
 /\           ___
/___/\_|_|\_|__|___Gian Uberto Lauri_____
  //--\| | \|  |   Integralista GNUslamico
\/                 e coltivatore diretto di Software

 zucchero sintattico.
Sono d'accordo. Tutti sappiamo che, dietro le quinte, viene chiamata una 
funzione operator{+|-|*|/|...|>>}
-- 
Emanuele Torrenti
Registered Linux User #409659
http://torrenti.altervista.org

 necessariamente "preferenze") tra i due linguaggi?
Si fa prima a enumerare le ugualianze/similitudini che le differenze.
Java e C# sono in realtà molto diversi, ciò che li accomuna è una
parte della semantica fra l'altro comune anche ad altri linguaggi.

 L'utilità dell'overloading degli operatori e` un mito (falso).
Non sono d'accordo. Nella scrittura del codice in Java l'overload degli
operatori manca, poi è chiaro che tutto si può aggirare scrivendo
codice su codice.
Andrebbe citato per la cronaca anche l'overload del casting (implicito
o esplicito).

> L'utilità dell'overloading degli operatori e` un mito (falso).
VV> Non sono d'accordo. Nella scrittura del codice in Java l'overload
VV> degli operatori manca, poi è chiaro che tutto si può aggirare
VV> scrivendo codice su codice.
E' solo una questione culturale legata all'esperienza delle persone. 
Manca a  te ad esempio per tua  ammissione.
Chi  è  abituato  ad  usare  solamente la  notazione  algebrica  trova
*comodo* l'overloading degli operatori perchè è abituato a scrivere le
operazioni  con  una  certa   notazione  ed  a  premere  uguale  sulla
calcolatrice.
A  me  invece non  manca  per nulla,  anzi,  comincio  a preferire  le
notazioni funzionali.
Inizialmente,  lavoravo in  Pascal su  un 3B2  all'università, l'over-
loading degli  operatori mi pareva il  non plus ultra  del bello. Poi,
tra l'uso della notazione postfissa prima e prefissa poi l'overloading
degli operatori ha perso via via  fascino, fino a diventare una cosa a
volte interessante (l'implementazione di Python) ma mai essenziale.
L'illuminazione  :) :)  la ho  avuta  da un  sistema di  help on  line
avviato casualmente  sul secondo carattere di  questa istruzione LISP:
(+ 1 1).


 notazioni funzionali.
Anche io preferisco le notazioni funzionali tuttavia l'overload degli 
operatori puň essere utilissimo. Ti faccio due esempi, uno piů
pratico uno piů teorico:
1) Ho una classe ECMAVar che modellizza il comportamento delle var di 
ECMAScript. Facendo l'overload degli op riesce ad avere oggetti "non 
tipizzati" e ad usarli in maniera assolutamente immediata compilando a 
run-time codice C#
2) Sai che figata poter avere dei constraints sui tipi generici riguardo 
agli operatori binari/unari implementati? ;-)
Ciao,
il Petrux - the Black One

 č sulla base di quello che io faccio la scelta tecnologica. 
Appunto.
Java e C# sono due tecnologie che possono vedersi come "competenti" 
l'una con l'altra, proprio per questo mi serve una comparazione.
Ciao,
il Petrux

 Manca a  te ad esempio per tua  ammissione.
In realtà è una questione sostanziale. Gli operatori sono elementi del 
linguaggio e c'è una notevole differenza fra definire un metodo e 
definire il comportamento di un oggetto come operando. Ricordo che non 
esistono solo gli operatori aritmetici, ma se anche così fosse 
utilizzando gli operatori puoi scrivere espressioni complesse quanto 
vuoi conoscendo le regole di ordine di valutazione e di precedenza.
E non manca solo a me, ma anche a Java stesso. Fino a java 1.4 le classi 
wrapper funzionavano come oggetti java puri, poi si sono accorti (un po' 
tardi...) che erano una rogna e fra le nuove caratteristiche di java 5 
c'è la conversione implicita con i nativi. Un accrocchietto ad hoc che 
in pratica cambia il behaviour degli operatori per un ristretto gruppo 
di classi.
Si può dire tutto dell'overload degli operatori, che non è elegante, che 
non è rigoroso, etc... ma di certo non si può dire che non è utile.

> persone. Manca a te ad esempio per tua ammissione.
VV> In realtà è una questione sostanziale. Gli operatori sono elementi
VV> del linguaggio e c'è una notevole differenza fra definire un
VV> metodo e definire il comportamento di un oggetto come
VV> operando. Ricordo che non esistono solo gli operatori aritmetici,
VV> ma se anche così fosse utilizzando gli operatori puoi scrivere
VV> espressioni complesse quanto vuoi conoscendo le regole di ordine
VV> di valutazione e di precedenza.
Se il tuo discorso fosse vero  il LISP non funzionerebbe. Ed invece il
LISP è dimostrato  equivalente ad una macchina di  Turing, non solo, è
nato  prima come formalismo  equivalente alla  macchina di  Turing (Mc
Carty) e poi implementato come  linguaggio in un paio di settimane, se
non ricordo male da Sussman.
Java non  è LISP, "We  were after the  C++ programmers. We  managed to
drag a  lot of them  about halfway to  Lisp."  - Guy  Steele, co-auore
della Java spec ed anche autore  del manuale del Common Lisp noto come
Aluminum  Book, ma  anche in  Java puoi  scrivere espressioni  in modo
funzionale,  pensa ad  un  certo  tipo X  con  quattro operazioni  che
rappresentiamo con \oplus, \ominus, \otimes e \oslash (notazione TeX).
Non  importa  COSA fanno  le  operazioni,  prendono  dei valori  e  li
trasformano. \leftarrow assegna il valore.
Supponiamo  che   nella  notazione  infissa   questi  operatori  siano
associativi a sinistra e di pari priorità.
L'espressione stampata
ris \leftarrow valore1 \oplus ( valore2 \otimes valore3 ) \oslash valore4
(fai  \oplus tra  valore1  e il  risultato  di \otimes  tra valore2  e
valore3 e usi il risultato della \oplus per fare la \oslash)
puoi  anche  rappresentarla in  modo  prefisso  (non occorre  definire
l'associatività e  la precedenza, ma  usi le parentesi. Tolgo  anche i
backslash.
(set 'ris (oslash (oplus valore1 (otimes valore2 valore3)) valore4))
che in pseudo-Java, usando la notazione a metodi è:
ris.set(valore4.oslash(valore1.oplus(valore2.otimes(valore3))));
Non c'è *necessità* di usare operatori.
Che è diverso da dire che gli operatori non possano risultare comodi e
pratici.
Che poi  abbiano introdotto la conversione implicita  dei wrapper, non
aggiunge nulla al discorso. Ma proprio nulla. E' solo una questione di
comodità.   Di gran  lunga  meno importante  (IMHO)  che avere  classi
container tipizzate :). 


> notazioni funzionali.
IP> Anche io preferisco le notazioni funzionali tuttavia l'overload
IP> degli operatori può essere utilissimo. Ti faccio due esempi, uno
IP> più pratico uno più teorico:
Utile nel senso di comodo. Ma la comodità in programmazione comincia
a diventare un criterio molto soggettivo.
IP> 1) Ho una classe ECMAVar che modellizza il comportamento delle var
IP> di ECMAScript. Facendo l'overload degli op riesce ad avere oggetti
IP> "non tipizzati" e ad usarli in maniera assolutamente immediata
IP> compilando a run-time codice C#
Immagino.  Personalmente preferisco  i  linguaggi ove  i valori  hanno
tipo... :)


 pratici.
Che è sostanzialmente ciò che sostengo. Che non sia "necessario" è
lapalissiano, che sia utile lo è altrettanto. L'overload degli
operatori riduce la verbosità nella scrittura del codice e IMHO a java
non farebbe certo male.

 tipo... :)
Anche io.
Però immagina... scenario: un applicazione che gira su un interprete xml 
(o meglio: di un linguaggio xml-based) e che supporta solo javascript 
comunica con una applicazione che gira nel backend, scritta in C# alla 
quale chiede elaborazioni di condizioni logiche in tempo reale secondo 
templates definiti in javascript. Con l'overload degli operatori mi 
definisco una variabile ECMAVar cui passo come argomento del costruttore 
una stringa, sovrascrivo gli operatori e poi la tipizzazione 
(internamente) se la "smazza" l'oggetto ECMAVar e l'utente (tipicamente 
un designer che non è uno sviluppatore) non si deve fare problemi sui 
tipi, pur potendo contare su un backend assolutamente tipizzato.
Ciao,
Giulio

 writes:
VV> Che è sostanzialmente ciò che sostengo. Che non sia "necessario" è
VV> lapalissiano, che sia utile lo è altrettanto. L'overload degli
VV> operatori riduce la verbosità nella scrittura del codice e IMHO a
VV> java non farebbe certo male.
Il punto è che non arrivo  a generalizzazioni ma limito la validità ad
ambiti personali. E sopratutto non lo sbandiero come punto di forza di
un linguaggio rispetto ad un'altro.
Ah  per risolvere  la  prolissità  di Java  preferisco  far fare  alle
macchine  le cose  meccaniche  (visto che  oltretutto  mi costa  molto
poco).


 poco).
Non l'ho capita.

> poco).
VV> Non l'ho capita.
Semplicemente, faccio  generare il codice ad  un editor programmabile,
ne sfrutto le  capacità di completion et similia. E  non ho contato io
cosiddetti wizard.
Devo  anche  dire  che  nonostante  la prolissità  dei  simboli  o  la
laboriosità   di  alcune   operazioni,   ho  notato   che  una   buona
strutturazione del codice in Java permete una concisione inattesa. Non
ho  ancora  usato  Do Bemolle  :),  ma  penso  che valga  il  medesimo
discorso. Idem per altri linguaggi che permettano la programmazione ad
oggetti.
