Newsgroup: it.comp.os.dibattiti
Titolo: Raymond e Java

Forte ESR......Ha declassato Java a linguaggio di scripting....
A Sun č venuto un coccolone....
ESR ultimamente trolleggia forte....
Saluti.



Beh Java puo` avere tutti i mali del mondo ma non e` un linguaggio
di scripting. Quindi direi che Raymond spara stupidaggine. Ad ogni modo...
...Java ha beneficiato moltissimo dal mondo open source...
ps. hai un link o te la sei inventata tu?
-- 
Lawrence


Zdnet
http://zdnet.com.com/2100-1104_2-5159134.html?tag=zdfd.newsfeed

 Perl," Raymond said in the letter.
Si parla di java e della sua caratteristica di essere crossplattform.
Raymond afferma che java ha ceduto il campo a linguaggi di scripting che
gli fanno concorrenza, come python e perl, che permettono allo stesso
modo la portabilità dei programmi. Non ha detto che java è un linguaggio
di scripting.
Quando facevo il liceo il mio professore di latino diceva sempre che per
fare una traduzione servono testa, testo e contesto. La prossima volta che
leggi un articolo tienilo presente. :-)

 
http://zdnet.com.com/2100-1104_2-5159134.html?tag=zdfd.newsfeed
Non so cosa mi stupisce di meno tra Raymonds che spara cazzate, Raymonds
che fa il troll, o te che traduci quel che vuoi come vuoi :p
HAND,
-- 
                                                __Nicholas Wieland
Readability counts.
                                                __The Zen of Python

 di scripting.
Infatti. Lo ha, di fatto, declassato a linguaggio di scripting :-)

 Infatti. Lo ha, di fatto, declassato a linguaggio di scripting :-)
Veramente, dal testo riportato, dice l'esatto contrario.
Cioe` dice che sta perdendo terreno a vantaggio dei
linguaggi di scripting.
Il che non fa altro che sottlineare il fatto che Java
non sia un linguaggio di scripting.
bye,
-- 
   Piergiorgio Sartor



Vero. Hai ragione.
Saluti.

 che fa il troll, o te che traduci quel che vuoi come vuoi :p
IMHO Eric Raymond è una delle personalità piu' interessanti (e anche
stravaganti) del movimento FOSS. Effettivamente definire linguaggio di
scripting Java mi pare un po'... fuori luogo? Pero' ultimamente ha fatto
interventi secondo me davvero pungenti (vedi gli articoli su CUPS
www.catb.org/~esr
), oltre ad aver scritto alcuni dei lavori di ampio
respiro sul movimento piu' interessanti e intelligenti che ho letto.
Ovviamente spicca The Cathedral and the bazaar.
Mi piace il modo in cui ragiona, la mentalità con cui affronta i problemi.
ciao
luca

 Vero. Hai ragione.
Mi pareva strano...
ciao
luca

 scripting Java mi pare un po'... fuori luogo?
Infatti non l'ha detto.
-- 
Lorenzo



Male, java e` una puttanata. Solo dalla prossima versione migliorera`
qualcosina, perche` copieranno spudoratamente da .Net.
-- 
Valentino Volonghi aka Dialtone
Linux User #310274, Gentoo Proud User
X Python Newsreader developer
http://sourceforge.net/projects/xpn/

 qualcosina, perche` copieranno spudoratamente da .Net.
Scusa Valentino ma che c'entra. Raymond ha detto tante cose giuste ma a
volte anche delle cazzate. Java per quanto non possa piacere (e a me in
primis non piace) è tutto fuorchè un semplice linguaggio di scripting.
Riguardo alle copiature a .NET è normale (.NET ha copiato parecchio da Java
nella prima versione), anche se con il ritardo annunciato della prossima
versione mi sa che vedremo prima Java 1.5 che .NET 2
-- 
Lawrence
"ain't nothin' but fun."

 prossima versione mi sa che vedremo prima Java 1.5 che .NET 2
Io non ho detto che e` un linguaggio di scripting, ho detto che e` una
puttanata. Inoltre non e` questione del fatto che java possa o meno piacere, e`
questione che ci sono caratteristiche della jvm e del linguaggio che sono,
oggettivamente, sbagliate, come ben sai anche tu, tra l'altro. Tipo il GC che
blocca l'esecuzione del software per ripulire lo heap. O che non genera
eccezioni di overflow, o che dentro alle collection tutto e` un object e quindi
ci fai un po` quel cacchio che ti pare, o che i tipi primitivi non sono oggetti
(grazie al cielo nella 1.5 correggono sta schifezzata con il boxing/unboxing), o
che gli iteratori usati per indicizzare un array non sollevano nessuna eccezione
ma non funzionano, o che clone() ritorna per forza di cose un Object (altrimeni
non compila) che va poi castato... E dove la mettiamo la type safety? Un Object
lo usi come un void e ci fai tutte le cazzate di sto mondo... Basta creare una
classe qualsiasi, clonarla e poi dimenticarsi di castarla e a quel punto ti
saluto type safety.
Grazie a dio arrivano i generics nella prossima versione, perche` io solo a
scrivere 2 costruttori mi rompo le balle visto che sono abituato a scriverne uno
che va bene per qualsiasi caso.
Il fatto che si sia obbligati a piazzare tutto in una classe e che il pradigma a
oggetti quindi sia l'unico esistente (no, usare static per qualsiasi cosa e
pensare di usare un paradigma diverso e` abbastanza perverso) quando non e`
detto che sia la soluzione corretta... Mah.
Parallelamente a java sto studiando anche C++ e sto dando un'occhio a groovy
(che mi avevi consigliato tu Lawrence) e sono tutti e 2 migliori sotto svariati
aspetti (anche se groovy e` scritto per la jvm). Non torno a parlare di python
perche` tanto per me non ha eguali nell'informatica, tant'e` che lo stesso
Raymond e` un pythonista.
BTW, guardando groovy credo che GNOME dovrebbe aiutare lo sviluppo di quel
linguaggio e usarlo, visto che Havoc non vuole usare python/perl/ruby per
questioni che non ho ben capito, e non gli va bene neanche mono o java, ma
vogliono preservare la possibilita` di usare codice unmanaged, credo che groovy
sia un'ottima scelta.


sia un'ottima scelta.
se parli di questo:
http://ometer.com/desktop-language.html
no è che non lo hai capito. E' che non lo dice :)
La verità è che, imo, havoc è uno di quelli che pensa alla parola
scripting come dispregiativo. La parola chiave nel testo è 'large'. 
PP&R vanno bene per piccole cose, ma non per quelle grandi. 

 vanno bene per piccole cose, ma non per quelle grandi.
In effetti e` una emerita cazzata... L'ho pensato anche quando l'ho letta ma
credevo avesse ragioni di fondo piu` corpose, tutto il test e` abbastanza
superficiale in realta`.
Nel post successivo dice che le mail che gli sono arrivate gli sbattono al
secondo posto l'uso di perl/ruby/python ma lui ignora...
bah, lo stimo molto ma e` un po` pirla.


In effetti e` una emerita cazzata...
non dirlo a me, io mi sento dire che il mio linguaggio preferito non è
adatto a applicazioni serie anche da chi sviluppa in python ;)

 sia un'ottima scelta.
Già, groovy sta avendo un bel pò di successo in questi ultimi tempi e a mio
avviso va nella strada giusta: usare la codebase Java, piena compatibilità
con il bytecode Java e con Java stesso, facilmente embeddabile in Java e
soprattutto...manda a casa quel "coso" che è Java :D


 
http://ometer.com/desktop-language.html
<parentesi>
secondo me ha scritto parecchie imprecisioni in quella pagina
(e non solo riferite a python/perl/ruby)
</parentesi>


 non dirlo a me, io mi sento dire che il mio linguaggio preferito
e quale sarebbe?


e quale sarebbe?
ruby :)

 abituato a scriverne uno che va bene per qualsiasi caso.
Non ho capito questa osservazione sui constructors, sinceramente.

 ruby :)
azz :) alcuni pythonisti non amano ruby (io stesso non riesco ad usarlo,
la sintassi è troppo perlish e poi python mi basta e avanza :P)
e poi in questi giorni sto guardando groovy :)


e poi in questi giorni sto guardando groovy :)
groovy è ruby con le parentesi graffe ;)
Sarà perché io perl non lo conosco bene, ma non mi è ben chiaro perché
ti sembra perlish.. 
intendo: capisco che in ruby ci siano le variabili con la @ ma
continuo a vedere perl molto differente.. 
scrivi una paginetta sul wiki se ti va?
direi... qui:
http://ada2.unipv.it/ruby/index.cgi?cmd=view;name=RubyForPythonista

 scrivi una paginetta sul wiki se ti va?
Riguardo a cosa?
ps. ci spostiamo in mail? l(dot)oluyede(at)virgilio(dot)it


 Non ho capito questa osservazione sui constructors, sinceramente.
class Pippo(object):
    def __init__(self, pluto, minnie, john='ciao', paperino=6):
        pass
A parte il fatto che in python ognuno di quelli sopra puo` essere di qualsiasi
tipo e sollevera` un'eccezione durante i test, pero` per tradurre in java una 
cosa di quel genere devo fare cosi`:
class Pippo {
    private {
        int pluto, minnie, paperino;
        String john;
    }
 
    public Pippo(int pluto, int minnie) {
        String john = new String("ciao");
        int paperino = 6;
    }
    public Pippo(int pluto, int minnie, String john) {
        int paperino = 6;
    }
    public Pippo(int pluto, int minnie, String john, int paperino) {
    //...
    }
A quello vanno aggiunti altri costruttori per gestire il caso in cui invece di
due int per pluto e minnie mi serva passargli array/liste ecc ecc, con i
generics se non altri mi limito a scrivere solo quello che ho scritto sopra
sfruttando poi la programmazione generica.


         pass
Ok, ti mancano i default arguments values cari al C++. 
Però non capisco cosa c'entra con i generics.
[1] non dimentichiamo che è perfettamente lecito dal punto di vista del 
linguaggio avere in una HashMap un elemento con key di tipo Iterator 
piuttosto che String o qualsiasi altro tipo, così come avere elementi con 
key/value di tipo diverso. Questo il programmatore lo *deve* sapere, se 
non lo sa vuol dire che non conosce il linguaggio ed è inutile che 
pubblichi pezzi di codice su internet per dimostrare che è java a farlo 
sbagliare...
 

 sbagliare...
Non e` questione di avere una chiave di tipo iterator... Basta che sia un
oggetto immutabile e puo` esserci quello che vuoi come chiave. Quello che conta
e` che un errore del genere non da eccezioni del tipo "KeyNotFound" o
"TypeError" o come cacchio le vuoi chiamare.


 "KeyNotFound" o "TypeError" o come cacchio le vuoi chiamare.
Ribadisco: per il compilatore *non* *è* un errore, quello è solo un 
programma che non fa quello che voleva il programmatore. 
Se poi il problema è avere una collection tipizzata, non è un problema 
nemmeno questo. In 5 minuti incapsuli l'HashMap (se non l'ha già fatto 
qualcun'altro) e ci metti i controlli che ti pare facedogli generare le 
eccezioni che ti pare. 

 eccezioni che ti pare.
E se tu stai cercando una chiave in un hash e non la trovi non sta forse facendo
qualcosa che non vuole il programmatore? Certo, c'e` il caso in cui e` previsto
che possa non esserci una data chiave, ma se non e` cosi`? Tagli la testa al
toro e sollevi un'eccezione indipendentemente, costa poco e nei linguaggi con GC
le eccezioni servono piu` al flusso che alla gestione delle risorse.
E come gia` detto, se in un linguaggio di alto livello devo reimplementarmi le
strutture dati perche` non si comportano come voglio io, allora il linguaggio
non fa per me. Magari a te piace, ma io lo trovo carente.


 non fa una piega...
Il codice e` formalmente corretto, il problema e` che l'autore non
incrementa l'iteratore. Avresti lo stesso problema con il C++ ad
esempio. Quello che accade in pratica e` questo:
i = 10
while i > 0:
        print "Pirla"
print "Finito"
python lo esegue senza problemi, questo cosa implica? Nulla, solo che il
programmatore dovrebbe smettere di programmare ;) 
Non c'e` molto da sapere sugli iteratori java (giusto 2 metodi) e mi
pare evidente che l'autore del codice da te quotato non si e` neppure
preso la briga di leggersi la documentazione (neppure "Java for
dummies", eh).
Luca
-- 
Home: 
http://kronoz.cjb.net
Collect some stars to shine for you
And start today 'cause there's only a few
A sign of times my friend

 io lo trovo carente. 
Non mi pongo il problema se mi piace o non mi piace. Penso che i motivi 
per cui tu lo trovi carente siano discutibili, specialmente in questi 
termini in cui le strutture dati "non si comportano come voglio io". Il 
linguaggio ha delle specifiche e sono documentate, quindi è normale che 
il linguaggio si comporti in un certo modo ed è normale che il 
programmatore sia tenuto a saperlo. 
Le questioni che hai sollevato mi sembrano opinabili e anche piuttosto 
futili, difficili da classificare come "carenze".


no, semplicemente se scrivi codice fai errori.
Oppure puoi sostenere che nessuno fa errori che se sbagli una cosa
cos' sei un porgrammatore stupido etc etc..
 Ma è la stessa cosa che ti dirò io se mi dici che il type check
statico e manifesto serve a qualcosa ;)
 Se leggessi la pagina noteresti questo:
"the cast operator does, it's a backdoor that throws out static typing
and lets the dragons in.[..] That's why we have templates in C++ and
Generic Java". 
E, sorpresa, Generic Java  è java 1.5 :)

:-) 
Dave Thomas è niubbo? Considera che ha appena vinto un jolt award con
un libro sullo unit testing in java.. 
Consiglio una breve ricerchina su google ;)
Non entro + nella discussione, ma state perdendo di vista il punto
che:
fino a java 1.5, java permette di fare errori di tipizzazione. 
E si, sei stupido se li fai. 
E si, sei stupido se li fai anche in linguaggi con tipizzazione non
statica e manifesta. 

 un libro sullo unit testing in java.. 
Ok, decorazioni a parte, non toglie che se voglio (di)mostrare che java 
è "error prone" sulle tipizzazioni devo anche fare un esempio decente: 
un esempio in cui si evinca che ci può cadere anche un programmatore 
normale per una distrazione o per altro, non un esempio con altri errori 
"sciocchi" che hanno come conseguenza il passaggio di fuffa ad un metodo.
Esempi ce ne sono.

 Il punto è che l'errore non viene catturato da java.
Il punto è entrambi ;)
Java non si è accorto che il programmatore ha passato fuffa al metodo 
get. Il programmatore ha toppato a monte l'uso dell'iteratore *non* 
*solo* passando fuffa al metodo get.
Diciamo che è un esempio un po' sbagliato.

Diciamo che è un esempio un po' sbagliato.
ok, non è l'esempio perfetto. 
Semplicemente, c'è scritto "un bug che mi è capitato oggi.."
 
Capisco che tu pensi "beh, ma java mica si può accorgere di tutto, è
il programmatore che deve evitare di essere cretino", solo che quello
che penso io di un linguaggio è "o mi salvi il culo in tutto e io mi
sforzo di scrivere tipi ovunque, o eviti di rompere in fase di
compilazione, tanto mi scrivo i miei test di unità per beccare gli
errori". 
Ma perché non prendono piede i linguaggi con type inference come ocaml
e haskell.. 

 errori". 
Per come la penso io: non sono un javaboy e francamente non sono nemmeno 
uno che si prende le fittonate per quello o quell'altro linguaggio. A 
java (come ad altri linguaggi simili) riconosco il merito di 
implementare il paradigma oo in modo a mio avviso "abbastanza" corretto; 
c'è a dire il vero quell'Object "padre di tutti i tipi" che se lo 
conosci lo eviti, essendo il massimo dell'astrazione spesso e volentieri 
è un abuso di astrazione.
Resta il nodo delle collections. In quei casi (fatto salvo i futuri 
generics) il famigerato Object lo conosci e non lo eviti. E su questo 
sono pienamente d'accordo, le collections non tipizzate sono una rottura 
di coglioni notevole perchè ti costringono a lavorare su un livello di 
astrazione non desiderato. Senza andare a cercare tanto lontano, ma se 
io voglio un contenitore di oggetti congruenti fra loro (credo che sia 
l'esigenza del 99.9% delle implementazioni) non lo posso fare salvo che 
non mi metta a "decorarne" una.
Ma a mio parere questo non comporta che l'implementazione del paradigma 
di java sia deprecabile, solo che i famosi "generics" dovevano arrivare 
parecchio prima.

 E, sorpresa, Generic Java  è java 1.5 :)
Che tra l'altro, su consiglio di Lawrence, ho guardato come ne parlano e non
sono generics per un piffero... Ecco a voi come funzionano:
class Pippo {
    public void Pippo() {
    ...
    }
    public void parla(String dicerie) {
        System.out.println(dicerie);
    }
}
class Pluto {
    public void Pluto() {
    ...
    }
    public void parla(String dicerie) {
        System.out.println(dicerie);
    }
}
interface CanSpeak { parla(); }
class Utilizzatore {
    public void Utilizzatore() {
    ...
    }
    public <T extends CanSpeak> void esprimi(T oggetto) {
        oggetto.parla(new String("ciao"));
    }
}
 
Ma che generics sono se per avere metodi diversi da quelli di Object devo creare
una interfaccia e invece di usare implements, come per qualsiasi cosa quando ci
sono in ballo interfacce, devo usare extends?!?! Che tipo generico e` se devo
scrivere una interfaccia per gestire ste cose?!?!?!?!
Potevano quantomeno metterci un mesetto in piu` e venire fuor con qualcosa di
meglio dai...


 parecchio prima.
Giusto. Ma come sono arrivate ora servono solo e soltanto per le collections e
allora uno si chiede, ma bisognava davvero aspettare 5 versioni per avere una
cosa cosi` elementare?


 cosa cosi` elementare?
Non correre... in Java sono state aggiunte da poco le regexp ;-)


 futili, difficili da classificare come "carenze".
Saranno difficili per te, perche` non hai mai programmato in un linguaggio piu`
coerente e piu` potente di quello che e` java magari, ma per me, che sono
abituato ad altri e migliori lidi, dover fare certe cose in java va contro la
concezione di buona programmazione.


Non correre... in Java sono state aggiunte da poco le regexp ;-)
beh, la classe Pattern c'è da parecchio.. forse intendevi le regex
perl-compatibili?

meglio dai...
credo tu abbia frainteso.. 
dal generics tutorial[2]:
public class Shape {
..
}
public class Circle extends Shape{
..
}
public void drawAll(List<? extends Shape> lista){}
E' ovvio che ci vada un 'extends' :)
[1]
http://lambda.weblogs.com/discuss/msgReader$11510
[2]
http://java.sun.com/j2se/1.5/pdf/generics-tutorial.pdf

 certe cose in java va contro la concezione di buona programmazione.
Naaa... non scadere in queste argomentazioni. Se ho mai programmato in 
altri linguaggi meglio o peggio di java, credimi, non è roba che ti possa 
interessare ne che interessano la discussione. Ahimè non sono nemmeno 
abituato a nessun lido, anche se vorrei passare le mie giornate su la mia 
caletta preferita in sardegna... se replicando alle contestazioni (non 
tutte, avrai notato) vado ad intaccare le tue certezze forse è bene che lo 
chiarisca: a me di java non me ne frega nulla, l'ho seguito e studiato per 
alcune tecnologie enterprise su cui ho lavorato, che ritengo valide insieme 
ad altre tecnologie che ritengo altrettanto valide. 
Python non l'ho nemmeno nominato ma non lo prendere come un oltraggio al 
tuo pupillo; non ci ho mai avuto seriamente a che fare, non l'ho studiato 
adeguatamente da parlarne, se è così potente come dici sono certo che 
quando mi avvicinerò alle tecnologie in cui eccelle sarò ben lieto di 
fermarmi in codesti migliori (?) lidi.
 

 perl-compatibili?
Esatto


 codesti migliori (?) lidi.
No no, alt. Quelle che ho scritto nel thread sono le ultime cose che avevo
scoperto e che non mi piacevano.
Java non mi piace perche` e` poco produttivo.
Il fatto che non hai nominato python non mi fa alcun effetto... Puo` piacerti
come non piacerti, non ci vedo nulla di male, c'e` anche ruby :P.
Che Python sia migliore di java e` una discussione che non merita neanche di
iniziare, ha cosi` tante cose migliori e cosi` poche peggiori (ne ha?) che non
vale la pena di iniziare un thread che svilirebbe troppo java.
Come gia` detto, l'UNICO vantaggio di java su python sono le librerie gia`
esistenti.
Un bravo programmatore python userebbe twisted e zope per applicazioni
enterprise allo stesso livello delle applicazioni enterprise fatte in j2ee:
http://www.boddie.org.uk/python/web_modules_enterprise.html
(non so quanto possa essere aggiornato, ma se non lo e`, non lo e` per
entrambi).


 svilirebbe troppo java. 
Non ne vale la pena perchè non mi sembri abbastanza lucido per farlo <g>

 Non ne vale la pena perchè non mi sembri abbastanza lucido per farlo <g>
Dici cosi` perche` non sai chi usa python :)
http://www.pythonology.org/success
Ma in generale direi pure tutto il sito riporta gente che usa python :).


 Dici cosi` perche` non sai chi usa python :)
Oddio, adesso che lo so dovrei dire qualcos'altro? <g>