On Sat, 8 Jul 2006 02:00:54 +0200, Paolo Donà wrote:
Durante la scorsa Java Conference ho avuto l’opportunità di fare delle
domande a Gosling (l’inventore di Java) a riguardo delle lacune che il suo
pargolo ha nei confronti dei linguaggi dinamici e funzionali quali Ruby,
lisp, e via dicendo.
Quella a Milano all’università? Dovrebbe essere parecchio interessante.
IMHO Gosling è uno da ascoltare comunque, anche se non si è d’accordo.
Purtroppo mi sembra si sia un po’ commercializzato (nel senso
“tecnico”, nel senso che è un po’ meno hacker e un po’ più “marketing”)
Cosa intendo? Questo è un post di Chad F. su quello che Gosling
dice di Ruby:
http://www.chadfowler.com/index.cgi/Computing/Programming/Ruby/GoslingThinksRubyJustGeneratesWebPages.rdoc,v
In particolare
“PHP and Ruby are perfectly fine systems,” he continued, “but they are
scripting languages and get their power through specialization: they
just generate web pages. But none of them attempt any serious breadth
in the application domain and they both have really serious scaling and
performance problems.”
Finchè queste cose le dice un Java advocate qualunque, mi sta anche
bene. Ma da Gosling mi aspetto un minimo
più di obiettività.
- L’obiettivo del linguaggio Java era quello di creare un linguaggio molto
simile al C++ dove però fosse più difficile incasinarsi la vita con
puntatori, memory leak etc etc, non fare un linguaggio totalmente nuovo o
totalmente OO come Ruby. E’ stato messo come must il fatto che tutti i
programmatori C++ potessero passare agevolmente a Java. Data la mole di
persone che programma in Java oggi, direi che l’obiettivo è stato raggiunto
con enorme successo.
E in questo ci sono riusciti. Peccato per la programmazione generica
(che è una delle cose che mi piace di più in C++) che in Java invece
trovo sostanzialmente limitata. D’altra parte mica pretendo, all’epoca
anche i templates di C++ non si sapeva bene come usarli, le
implementazioni erano incomplete, le specifiche non parliamone.
Tuttavia oggi… ma ovviamente la storia non si fa con i se. Inoltre
non ho una comprensione sufficiente della JVM per potere affermare “si,
templates migliori si sarebbero potuto fare”. Dopo tutto gli attuali
generics in pratica non sono visti dalla JVM.
Tornando a noi, ribadisco… avendo visto ObjectiveC (e ribadisco, non
è un mistero che ci si sono ispirati spesso e volentieri), mi chiedo…
siamo sicuri che fosse il caso di pulire e basta il C++ invece che di
infilarci dentro un po’ del meglio di Objective C?
IMHO avrebbero potuto essere più dinamici, ecco tutto.
- Non è che per quelli della Sun Java è perfetto così, semplicemente non
possono cambiarlo radicalmente per via dell’enorme user base. Ruby è
addirittura più vecchio, ma avendo molti meno utenti e applicazioni in
produzione risulta più semplice evolverlo nel tempo. E’ quello che ha fatto
e che sta ancora facendo (Ruby 2 all’orizzonte?)
Infatti. Questo è un enorme problema. Anche perchè appunto in un
linguaggio così statico non è possibile fare sostanziali aggiunte senza
cambiare il linguaggio stesso, magari andando a rompere la
compatibilità.Inoltre credo che siano molto diverse le
comunità.
- E’ facile criticare. Le specifiche di Java sono dettate dal Java
Community Process. Se avete delle idee su come migliorare Java perchè non
fate un piano serio e avanzate una Java Specification Request? Se al
pubblico piace poi le cose vengono fatte (come è accaduto per generics,
annotations e sta avvenendo per groovy)
Qualche idea la ho. Ma comporterebbe tanti di quei cambiamenti che non
sarebbe certo accettata. E poi in fondo trasformerebbe Java in qualcosa
che non sarebbe più Java. Diciamo che io farei di tutto per
dinamizzarlo, ma questo non è necessariamente facile.
Ah… e una cosa che mi piacerebbe davvero tanto (ma qui non ho idea di
come implementarlo… anzi, credo che alla fine non sia neppure
possibile farlo in modo automatico) sarebbe un uso sistematico del
NullObject Pattern.
Ma questo mi piacerebbe pure in Ruby, eh…
E confesso che spesso e volentieri l’obbligo di dichiarare le eccezioni
mi da un pochetto sui nervi 
Problema mio, chiaramente. Per quanto programmi abitualmente anche in
Java, non mi considero davvero un programmatore Java.
Poi queste opinioni sono. Pochi giorni fa un mio collega mi raccontava
di come invece a lui l’obbligo di dichiarare le eccezioni fosse una
delle cose che più gli piacevano di Java, e anzi gli sarebbe piaciuto
vederle anche in C++ e in Ruby/Python (quest’ultima cosa
assolutamente insensata, IMHO, se non a livello di annotazione, ma
allora basta rubydoc).
Intendiamoci, io adoro Ruby, ma non vedo perchè bisogna buttarsi in
battaglie di religione. Sono linguaggi nati in ambienti diversi, con scopi
diversi e hanno campi di applicazione ottimali diversi. Punto. La disciplina
che ti fai con il design by contract di Java oltretutto ti salva un pò da
tutte le cazzate che puoi fare con Ruby se non sei un guru… (se uno ci va
giù di moduli inclusi dinamicamente, metaclassi e via discorrendo non è che
il codice diventi poi tanto leggibile)
Io non è che voglio fare una guerra di religione. Dal mio punto di
vista, Java avrebbe potuto essere molto migliore inserendo capacità
dinamiche opzionali (ribadisco, penso ad ObjectiveC, compilato eppure
quasi interamente dinamico, eventualmente spogliato dalle vestigia C).
Poi fare un “ObjectiveJava” oggi sarebbe poco utile. Ci sono già Ruby e
Python, voglio dire. Sappiamo tutti che la storia non si fa con i se
(beh… questo non è vero in effetti i se giocano un ruolo importante
nel metodo storiografico di Weber, ma questo centra poco).
Riguardo alla metaprogrammazione in Ruby è come le spezie. A piccole
dosi riesce a trasformare un buon piatto in un’eccellente portata. Ma
se abusata rende il tutto un casino di sapori.
A parte che Design by Contract io non lo vedo necessariamente legato a
Java. Anzi, il LSP cerco di applicarlo sempre (quando ha senso).
Personalmente io quel modo di programmare lo avevo già dal C++, prima
di avvicinarmi a Java ( a parte brevi e deludenti flirt in precedenza).
Una cosa che invece mi manca moltissimo in Java è la possibilità di
usare un paradigma RAII. In generale avere variabili automatiche
potrebbe essere un vantaggio strategico. Anche se riporterebbe in Java
alcuni problemi del C++.
Che intenti per “occasione sprecata”? In che modo secondo te l’occasione
poteva essere sfruttata meglio mantenendo fede ai constraints che hanno
avuto?
Mantenendo fede ai constraints… ribadisco, un po’ di dinamismo credo
che avrebbe potuto inserirlo.
PS: Questa è una delle mailing list con il livello qualitativo più alto che
mi sia capitato di frequentare, mi dispiacerebbe scadere di stile facendo
gli estremisti talebani…
Tutt’altro. Ma chiediamoci perchè ci piace così tanto Ruby e se non ci
piacerebbe potere lavorare di più con questo linguaggio anche in ambito
aziendale. E chiediamoci come fare perchè questo accada.
[ ma in questo Java è peggio, IMHO ].