[Linux-Biella] Java e flame [Era: certificazione ISO 9001 Agenzia delle Entrate]

[Emanuele Aina]

Marco Ermini lamentò:

>> In questo hai ragione, HotSpot è molto veloce e, a parte le carenze
>> della sintassi, le pecche del linguaggio, la vecchiaia delle istruzioni
>> della VM,
> 
> Puoi magari fare qualche esempio? io di questi luoghi comuni ne ho
> sentiti a bizzeffe... poi quando si vanno a vedere i dettagli si
> sciolgono come neve al sole...

Non c'è bisogno di essere scontrosi!

Ne avevo già parlato un mesetto fa coi Daniele (Mastro e Brevi) parlando 
di C#, citando anche questi due articoli: 
http://www.25hoursaday.com/CsharpVsJava.html e 
http://en.wikipedia.org/wiki/Comparison_of_C_Sharp_and_Java


Riassumendo, i maggiori difetti per quel che mi concerne sono questi:

Sintassi. Iteratori non integrati nella sintassi. Non ho mai usato i 
nuovi generics, ma ne ho solo sentito parlare male (brutti, poco 
flessibili). Assenza di enumerazioni.

Linguaggio. Boxing/unboxing automatico di tipi nativi (per esempio int) 
assente. Necessario fare troppi cast espliciti. Impossibile fare 
overload degli operatori in maniera decente.

VM. .NET è decisamente più moderna con supporto diretto per linguaggi 
dinamici e generics a livello di VM. Orribile l'interoperabilità con
librerie native (JNI) e altri linguaggi.

Librerie. Gran parte delle librerie Java, sia ufficiali che di terze 
parti, soffrono solitamente della sindrome del framework totalmente 
interdipendente, con migliaia di interfacce e "componenti" impossibili 
da sostituire a causa di interdipendenze. Dalla libreria di I/O (tre 
classi per aprire un file?) a CORBA (che è orribile già di per sè).


Per quanto non abbia in particolare simpatia ne' Java ne' .NET e Mono, 
ritengo questi ultimi tecnicamente migliori.

Personalmente preferisco Python, ma essendo molto diverso dall'ambiente 
Java non è adatto agli sviluppatori Java, mentre .NET/C# è decisamente e 
volutamente simile.

>> la scarsità della libreria standard
> 
> Tralasciamo il fatto che dovresti darmi una definizione di "librerie
> standard"... ti stai riferendo a Java Standard Edition? perché anche
> la Micro e la Enterprise edition sono assolutamente "standard". E non
> mi venire a dire che sono "scarse", in quale altro linguaggio hai le
> feature, per esempio, degli Enterprise Java Beans imposti come
> standard?

Scusa, Java2SE.

> Vediamo piuttosto quelle di C++... certo sono fantastiche in
> confronto! Guarda che parli con qualcuno che ha sviluppato in C++ per
> anni, ed ha visto quale merda (scusate) si trova in certe
> implementazioni delle STL. Non parliamo del fatto che
> l'implementazione di STL di GNU fa piangere (ammesso che funzioni?...
> che mi ricordi io era una pena usare la multiple inheritance in C++
> visto che la gran parte del codice che usava template semplicemente
> non compilava... spero sia migliorato nel frattempo...). Oppure
> parliamo del fatto che nel mondo Microsoft semplicemente non si usano,
> ma abbiamo ALTRE librerie (ATL)

Perfettamente d'accordo. Se Java è brutto, C++ è un abominio.

Ciò non toglie che esistano cosa migliori.

> Comunque sono ben accetti esempi concreti di:
> 
> - linguaggi con "librerie standard" più ricche di Java

Python è imbattibile in questo. La qualità varia però molto da modulo a 
modulo (e spesso è molto ma molto bassa :( ).

Se si considera CPAN, allora Perl è dominatore assoluto.

Per chi invece vuole essere un filosofo della programmazione, Common 
Lisp dovrebbe essere molto ricco in merito a dotazione standard.

> - esempi di "pecche" del linguaggio Java

Ohibò, ovviamente come tutti i linguaggi anche Java non è perfetto.

Possiamo ribaltare il gioco: tu mi parli male di Java e io parlo male di 
Python/C/C# a tua scelta. O di tutti e tre. :)

> - esempi di "carenze di sintassi" del linguaggio Java (è diverso dal
> punto precedente, o è solo per allungare l'elenco?...)

No, volevo separare la sintassi dal linguaggio, ovvero dal bisogno di 
fare cast, dall'uso dell'overload degli operatori, eccetera.

Comunque possono benissimo finire insieme, non miravo alla lunghezza 
dell'elenco.

> - esempi di "vecchiaia di istruzioni della VM" (?!?)

Vedi sopra.

Credo che Java sia rimasto fermo per troppo tempo prestando il fianco a 
.NET, il quale ha colto l'occasione dignitosamente.

Spero in un po' di sana competizione, specie ora che Java sta diventando 
aperto.

Rimango in attesa che IcedTea entri in Debian.

> C'è sempre da imparare e sono sicuro che mi sono perso un sacco di
> cose... illuminami ti prego

Spero di averti esposto un punto di vista diverso dal tuo portando 
esempi concreti. Perché ho sempre la sensazione che tu mi ritenga un 
imbecille?

>> e le assurde interfacce
>> grafiche,
> 
> Tipo? immagino non ti riferisca agli IDE come Eclipse, che è stato
> "portato" per C++ tanto era migliore delle schifezze che in genere si
> usano per quest'ultimo (a parte in ambiente Windows dove esistono
> ottime IDE per C++).

No, a occhio Eclipse mi piace molto, anche se non l'ho mai usato e non 
uso IDE (vim+make+gnome-terminal).

> Se ti riferisci a Swing o AWT, ti invito, anche qua, a fare degli
> esempi di interfacce migliori che siano anche multipiattaforma e parti
> della "libreria standard" come piace definirla a te, per qualsiasi
> linguaggio (non soltanto C++, ma anche Python o quello che
> preferisci).

AWT è un wrapper verso le librerie native, prendendo il minimo comune 
tra tutte. Gli stessi autori di Java ne parlano male proponendo Swing 
come alternativa.

Swing è poco bella esteticamente (ovviamente per me) e risulta essere 
sempre male integrata nell'ambiente in quanto non usa le librerie 
native. L'API è orrida in quanto ogni widget richiede un thread, 
oggettivamente un pessima idea. Oltretutto è solitamente molto lenta, da 
cui la diffusa percezione della lentezza di Java, nonostante la velocità 
di HotSpot.

Proprio per questi motivi Eclipse usa una sua libreria, SWT, in grado di 
usare le interfacce native, direi con buoni risultati.

>> Considerando anche che gcj può compilare Java in codice nativo, si
>> eliminano del tutto le critiche relative alla VM.
> 
> Considerando che gcj ha delle grosse limitazioni e in effetti PERDI i
> vantaggi insiti nell'usare una VM (la scalabilità, la possibilità di
> profiling, il dynamic binding, e senza considerare che una parte molto
> ampia e molto interessante delle librerie Java - come le Enterprise -
> semplicemente non compila) vedo assai poco interessante gcj.

Certo, non ho detto che la compilazione nativa è obbligatoria, solo che 
sia possibile.

Oltretutto l'ho citato come vantaggio, in quanto un programma compilato 
nativo è più veloce che interpretato, se non altro per il peso 
dell'interpretazione stessa.

>>  > Non parliamo poi di tutti quei programmi in C o C++ che hanno memory
>>  > leak - se ne trovano ancora persino in software sotto osservazione
>>  > continua a livello mondiale come le glibc o Apache... figurati negli
>>  > altri. Problemi simili in Java non ne hai
>>
>> Nei sistemi con garbage collector ci possono comunque essere memleak,
>> basta dimenticare dei riferimenti in un hash (ed è una cosa abbastanza
>> comune).
> 
> Non capisco a cosa ti riferisca: fammi un esempio.
> 
> In Java non ho certo di questi problemi. Mi posso "dimenticare" quello
> che voglio, il garbage collector è quello più sofisticato presente per
> qualsiasi linguaggio di programmazione, e deallocherà il mio hash non
> appena esco dallo scope in cui l'ho utilizzato.

A me è capitato questo:
  - ho un hashtable con dentro tanti oggettini
  - l'hashtable vive per tutta l'esecuzione del programma
  - aggiungo progressivamente voci all'hashtable
  - dimentico di togliere le voci non più usate, che però avranno sempre
    il riferimento dell'hashtable a tenerle in memoria

Un memory leak con GC.

>> Il maggior beneficio dal punto di vista della sicurezza è invece la
>> protezione dai buffer overflow, ma ci sono apposite librerie anche per
>> C/C++.
> 
> Da un punto di vista della sicurezza questo è senz'altro un beneficio,
> anche se in C++ ti tocca affidarti a librerie di terze parti o a
> profiler. Ma è sicuramente un beneficio minore rispetto al fatto che
> comunque, qualsiasi cosa tu crei (da una utility command line, a un
> server TCP/IP, a una applicazione web...) creandolo in Java, hai delle
> funzionalità che sono uno standard che è parte delle specifiche Sun ed
> è utilizzato e riutilizzato, quindi stra-testato. Se un motore JSP o
> J2EE ha un problema, lo si "patcha" per tutte le applicazioni del
> mondo che lo usano. Se ti sei scritto il tuo application server in
> C++, sei lasciato a soffrire da solo.

Certo, ma l'errore qui non è usare C++, ma l'avere scritto un 
application server da zero. Il C++ è solo un'aggravante. :)


Facciamo così: tu mi parli male di Java e io parlo male di Python/C/C#.

Almeno 5 difetti per ciascun linguaggio.

-- 
Buongiorno.
Complimenti per l'ottima scelta.