[RELug] [OT]: Java

Luca Bigliardi shammash@artha.org
Sab 25 Mar 2006 19:32:31 CET


On Sat, Mar 25, 2006 at 05:20 PM, Vecchi Giovanni wrote:

> In effetti è stata una delle prime domande che ho posto, dato che 
> "Everything is an object" ho pensato che anche i tipi primitivi devono 
> essere degli oggetti, ma la risposta è stata che sono una cosa particolare 
> (ma va?) e quindi saltata a piedi pari (credo anche giustamente perchè non 
> era obiettivo del corso quello di spulciare il linguaggio ma darci gli 
> strumenti per essere operativi quasi da subito). Ora, non so se a livello 
> teorico/didattico/accademico possa essere una valida risposta, ma alla tua 
> domanda come mai ci sono sia i tipi primitivi che le relative classi, 
> potrei tentare ad abbozzare qualcosa: allora, credo che esistano entrambe 
> solo per un discorso di comodità per il programmatore, cioè se ti serve un 
> piccolo contenitore dove metterci dentro dei numeri e basta, perchè 
> dovresti fare un'oggetto e tutto quello che si porta dietro la creazione di 
> un oggetto? ti basta un piccolo int... se poi ti accorgi che invece a 
> quella piccola scatolina devi chiedere di più, fai un casting ad Integer e 
> hai possibilità che prima non avevi.
> Cosa intendi dire con "beh, l'han fatto perche' cosi' puoi ottimizzare" ?

Esattamente quello che hai detto.
In primis mi sembra un controsenso solo il dire "ottimizzare in java": se
hai cosi' bisogno di andare forte da dover ottimizzare sugli interi (si
presuppone, dopo aver ottimizzato tutti gli algoritmi) allora forse ti
serve scrivere quel modulo della tua applicazione in un linguaggio
differente da Java.
In seconda battuta il compilatore deve essere abbastanza intelligente da
capire quando gli serve un oggetto ed invece quando puo' usare un
semplice intero. In un linguaggio di programmazione ad alto livello e'
molto importante.

> Sinceramente non mi è mai venuta l'idea di ereditare da più classi... cioè, 
> non ne vedo la comodità.
> Forse per quello che dovrò fare io non è neanche necessaria, ma potresti 
> farmi esempi più "concreti" che giustificano un'ereditarietà multipla?

In piccole applicazioni non capita, ma quando devi prendere in mano
codice scritto da altri oppure devi apportare modifiche pesanti ad un
programma gia' scritto la cosa e' molto probabile.

> E fare con delle enumeration? Cos'è "yield" ?

Io la vedo un po' come un "return" evoluto: tornare un valore al metodo
chiamante, poi quando questo ha finito il codice riparte da yield.
Esempi per C# / ruby / python ne trovi a montagne.

> chi c'è anche?

Boh, dipende da quello che devi fare.. Rails? Turbogears? Zope?

> ed era colpa del linguaggio o del programma? perchè anche io posso fare un 
> programma in C++ e farlo andare da merda... mi sembra un po' azzardata 
> questa affermazione...

Tutti ai corsi vendono (si, vendono, non insegnano) java come una panacea:
"usa java e i tuoi programmi saranno perfetti, li scriverai in due secondi
gireranno nei secoli dei secoli e quando dovrai aggiornarli ci impiegherai
altri due secondi e poi continueranno a girare ancora nei secoli dei secoli".
Bene, la realta' dimostra proprio il contrario.
Nota: non sto parlando di 2-3 applicativi, parlo di circa una decina e molti
sviluppati da $grossaditta1 per $grossaditta2 (quindi non da
principianti).

> in che senso umano?

Beh, oltre al fatto che e' un linguaggio di merda che gira su una
virtual machine orripilante bisogna considerare anche che quest'ultima
non e' assolutamente open.
Li poi vedi tu se fare questa considerazione prima o dopo la valutazione
tecnica del prodotto.

Concluderei citando $partecipante_a_ml_erlug (non mi ricordo chi fu..)
"Java: il Cobol del terzo millennio"

luca

-- 
What's the best thing you could be working on, and why aren't you?
		Paul Graham, Good and Bad Procrastination

http://shammash.homelinux.org/ - http://www.artha.org/ - http://www.yue.it/



Maggiori informazioni sulla lista RELug