Newsgroup: it.comp.java
Titolo: Python vs Java -> Perché i pythonisti ce l'hanno tanto con Java?

Ciao Javisti,
vi pongo una domanda non tecnica ma "etica".
Ho notato che i miei colleghi pythonisti ce l'hanno proprio a morte
con Java e snobbano i programmatori Java dicendo che molto spesso
sono niubbi o scrivono pessimo codice.
Premesso che non voglio fare polemica e che porgerò la stessa medesima
domanda a loro.
Mi chiedevo solo il perché di questo astio e se esistono
anche considerazioni analoghe a rovescio, ovvero se i Javisti ce
l'hanno
con python e la sua comunità.

 l'hanno con python e la sua comunit�.
Cosi' vediamo se riusciamo a completare il flame, per esempio avendo un
po' di Pythonisti che vengono di qua a difendere Python, oppure se
semplicemente qualche Javista scrive perche' non gli piace Python
(auspicabilmente conoscendolo) e la cosa finisce li. Boh.
-- 
-riko

 (auspicabilmente conoscendolo) e la cosa finisce li. Boh.
Ciao! Sono prevalentemente Javista e Perlista, ma mi sono trovato mesi fa a 
dover imparare un po' di Python. Non mi sento di dovergli muovere delle 
critiche (eccetto il fatto che l'indentazione stabilisce i blocchi e non le 
graffe, ma � solo stile) e devo dire che � un linguaggio veramente 
versatile. Scrivere client per servizi web soap � veramente facile.
Sinceramente, sapere che qualcuno mi odi senza conoscermi mi ha fatto 
rimanere di sasso :D

 con python e la sua comunit�.
Perche' i Pythonist sono dei frick chic puristi della programmazione
elegante, non capiscono nulla di architetture, usano l'Apple e non
gudagnano
Nicola
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 gudagnano
A quelli che conosco io puzza anche un po' l'alito.

Manuel T ha scritto:

Veramente il problema dell'ambiguit� indentazione/blocco di Python non � 
affatto una "questione di stile". Prova a far mettere le mani su un bel 
po' di codice python a due o tre studenti non proprio brillanti che 
usano editor diversi e poi vedi se riesci a far funzionare ancora 
qualcosa...
Detto questo, a me Python piace molto, Java mi piace un po' meno, ma dal 
punto di vista pratico uso Python come giocattolo e per rimpiazzare gli 
shell script, Java per qualsiasi cosa seria.
Ciao.

 
LOL

 A quelli che conosco io puzza anche un po' l'alito.
A me sicuro, visto che vengo da un pranzo a base di fagioli piccanti. E
credo che l'alito sia il minimo dei miei problemi al momento.
-- 
-riko

 rimanere di sasso :D
Pensa come ci sono rimasto io a scoprire che non sapevo nemmeno di
odiare qualcuno.
-- 
-riko

 qualcosa...
Fatto e non ho visto problemi. Suppongo che basti dare le due dritte
giuste assieme alla dispensa per studiare il linguaggio e il problema
non si pone. ;)
Poi *sinceramente* mi avrebbe fatto piu' piacere che il linguaggio fosse
meno flessibile, non consentisse di mischiare tab e spazi (come lanciare
con -tt di default, o almeno -t). Il problema di fatto e' tutto li. Ma
questo sarebbe piu' un discorso da iclp che da icj. 
Poi voglio dire, fare mettere le mani a persone poco brillanti su grosse
moli di codice non e' *mai* banale. Indentazione che se ne va
*comunque*, stili e usi insoliti non conformi alle convenzioni del
progetto. Etc etc etc. 
Tra l'altro io introdurrei piuttosto alla svelta all'uso dei lint.
Strumenti che trovo molto utili *sempre*, per qualunque linguaggio. A me
personalmente capita che in progetti cui non do troppa importanza posso
finire per scrivere codice stilisticamente brutto. Avere il lint che me
lo fa notare fa scattere il sentimento di vergogna che mi porta ad
aggiustare le cose.
Ad essere bastardi lo si puo' sempre buttare nel post-flight del commit.
<g>
-- 
-riko

 sono niubbi o scrivono pessimo codice.
Anche molti pythonisti sono niubbi :-), beh effettivamente questo � vero 
ma solo perch� Java � pi� richiesto e quindi ci sono molti programmatori 
fuffa.... (tempo fa lavorai con un programmatore romano che aveva la 
ceritifcazione "Java Developer" e per gestire un parser xml ebbe la 
grandiosa idea di usare la classe java.util.Stack impreziosendo il suo 
codice con un paio di goto: - giuro non sto scherzando :-) -
GM.

 > con python e la sua comunità.



E dai... ora non esageriamo...

 GM.
Io sono un esempio di niubbo su entrambi...
Comunque si alla fine, a parte qualche post, la conversazione è
tecnica e civile.
Questo volevo, un motivo di confronto,
capire perché c'è chi preferisce uno o l'altro
con qualche parola di fuoco ogni tanto.

 -riko
Dai non esagerare, non mi pare di essere stato offensivo,
né di aver fatto un gioco sciocco da bambini.
Ho solo chiesto se il perché di un comportamento che talvolta
trascende in toni da ultras.
Volevo proprio cpaire un po' di motivi del perché si arriva ai toni da
ultrà e perché
c'è chi è pronto a scegliere un linguaggio piuttosto che un altro.
Tutto sommato la discussione si sta svolgendo in toni civili,
senza scadere nel flame e tutti mi danno delle motivazioni più
o meno tecniche o propongono soluzioni a problemi o presunti tali.
Quindi niente flame, anche se ammetto di aver fatto un post 'delicato'

 E dai... ora non esageriamo...
Era una battuta...

 Ciao Javisti,
ciao pirla.


Di la hanno abboccato, temo.

 l'hanno con python e la sua comunit�.
si perch� ho visto un tutorial per principianti dove
indica come aprire la shell di python e poi dice:
"""Vedremo che si aprira' una nuova ed affascinante finestra: """
affascinante... capisci?

 """Vedremo che si aprira' una nuova ed affascinante finestra: """
L'ha scritto Salvatore "What a shame" Aranzulla?

 L'ha scritto Salvatore "What a shame" Aranzulla?
non saprei, comunque questo � il link:
http://hkn.eecs.berkeley.edu/~dyoo/python/idle_intro/OneDayOfIdleToying_Italian.html
 

Provo ad introdurre un elemento di equilibrio, premettendo che non
sapevo che alcune persone utilizzatrici di un certo linguaggio
potessero, ricambiate, essere "odiate" da alcune altre persone
utilizzatrici di un altro linguaggio. La cosa comunque non mi stupisce
perché il campanilismo sembra essere uno dei mali insiti nella natura
umana.
Conosco il linguaggio Java meglio di altri linguaggi perché è il mio
strumento di lavoro principale (questo non significa che io lo conosca
bene). Ho frequentato l'università quando Java muoveva i primi passi,
per cui niente percorso didattico (all'epoca si insegneva Pascal, C, C+
+, Lisp, Prolog, Smalltalk...), ma solo percorso auto-didattico, al
lavoro (buttato nella mischia senza teoria).
Ho sempre avuto una passione per i linguaggi di programmazione e ho
ancora oggi l'ambizione di conoscerne quanti più possibile: ogni
linguaggio può avere la capacità di esprimere una soluzione in una
maniera elegante, che altri linguaggi possono non avere.
E colleziono compilatori e interpreti, con la speranza di avere del
tempo per studiarli tutti.
Ma lo studio per me avviene prima sui libri e poi sulle tastiere, e
quando ho dovuto iniziare a studiare il linguaggio Java, ho cercato, e
mi sono imbattuto nel libro di Bruce Ekel: Thinking in Java.
Fino alla terza edizione era disponibile gratuitamente sul suo sito
(
http://mindview.net/Books/TIJ/DownloadSites
), la quarta invece è a
pagamento,e sul sito ne è disponibile solo una parte.
Per conto mio ho acquistato l'edizione italiana della 4° edizione,
editata da Pearson Education Italia, suddivisa in tre volumi (tra
l'altro la consiglio caldamente a chi vuole avere un riferimento
autorevole nel linguaggio Java).
Chi ha letto i suoi libri potrebbe aver condiviso il mio entusiasmo
nella chiarezza della sua esposizione e nella sua profondo conoscenza
del linguaggio. Dico "potrebbe" perché magari c'è anche qualcuno che
non li apprezza. Personalmente in giro ho trovato solo recensioni
estremamente positive, che mi hanno rinforzato nella convinzione che
il mio investimento è stato ben impegnato.
E Bruce Eckel, come tanti altri "grandi" non è un integralista. Sul
suo sito è disponibile anche il suo "Thinking in C++". E, udite udite,
la bozza del suo "Thinking in Python", linguaggio tra i suoi
preferiti, come potete verificare nella lettura di "Thinking in
Java" (si, Java, non ho sbagliato).
Concludo parafrasando un detto: fate programmi non fate la guerra. E
aggiungo: collaboriamo, piuttosto che scannarci come fanno certi
tifosi di squadre avversarie che gli basta vedere un colore di
maglietta diverso per trasformarsi in bestie. La collaborazione, per
quella attività intellettuale che è la programmazione, è condivisione
della conoscenza e quindi arricchimento reciproco.
Ciao a tutti
Daniele

 Di la hanno abboccato, temo.
Affatto. Anzi. Continua a sostenere dell'odio, gli si cerca di far
capire di no. Amen. Se passa un javista da queste parte lo abbraccio e
metto la foto su flickr.
Ah, se ne avessi lasciato qualcuno vivo avrei potuto controbattere la
tesi secondo cui li odierei... <g>
-- 
-riko

 utilizzatrici di un altro linguaggio.
E' tutt'ora la tesi di Franco. Per adesso pare non suffragata da chi
scrive qua, ne da chi scrive la.
-- 
-riko


Parole sante

 Di la hanno abboccato, temo.
mi pare abbiano abboccato meglio di qua. come � ovvio, visto che la 
provocazione era chiaramente diretta qua.

 Quindi niente flame, anche se ammetto di aver fatto un post 'delicato'
-- 
-riko

 wrote:

-- 
-riko

 > questo articolo e` stato inviato via web dal servizio gratuitohttp://
www.newsland.it/newssegnala
 gli abusi ad 
ab...@newsland.it
-- 
-riko

 Parole sante
Perche' non apri una discussione sulle modalita' di quoting? :)
-- 
-riko

 shell script, Java per qualsiasi cosa seria.
premetto che lavoro con j2ee da anni, che � lo strumento che meglio 
conosco per fare le "cose serie" e quindi � quello che normalmente 
propongo. per� se mi chiedi in confidenza cosa ne penso ti rispondo che 
*tante* volte mi chiedo "chi me lo fa fare?".
la robustezza di un programma j2ee dipende quasi zero dalla qualit� con 
cui � scritto il codice, ma sempre pi� da una serie di fattori pi� o 
meno aleatori. se ci pensi bene, al di l� dei soliti luoghi comuni, 
affidare una "cosa seria" ad un application server java � come assumere 
un pedofilo come baby sitter: praticamente l'unica configurazione 
funzionante � quella dedicata alla singola applicazione e clusterizzata 
in modo da poter essere riavviata a piacimento perch� in mancanza di 
questo non potrai *mai* dare nemmeno la pi� piccola garanzia di 
affidabilit�.
quindi sempre pi� mi cresce il dubbio: ma java � davvero cos� adatto per 
le "cose serie"?

 le "cose serie"?
Non comprendo bene perch� gli AS Java e solo loro debbano essere cos� 
inaffidabili...
Pensi che i corrispettivi in python siano esenti da bug e sempre 
funzionanti? Che se devi distribuire un'applicazione su pi� macchine con 
replicazione della sessione, fili tutto semplice e liscio come l'olio?
Non lo so, ma non credo.

cicap ha scritto:

Concordo, se c'� un AS o un framework di qualche tipo ed � inaffidabile, 
non dipende dal linguaggio in cui � scritto (poi, potrei anche pensare 
che diffusissimi prodotti sviluppati in Java da grandi progetti 
opensource o da grandi aziende siano probabilmente pi� affidabili dei 
corrispettivi Python molto meno noti).
Ma, a parte questo, per "cose serie" non intendevo singole applicazioni 
standalone fatte e finite, bens� progetti che iniziano adesso su 
premesse confuse, integrano roba preesistete in azienda, dovranno 
funzionare affidabilmente per i prossimi dieci o vent'anni, su 
piattaforme che adesso non conosciamo neppure, sopportando decine di 
modifiche fatte da emeriti consulenti sconosciuti o dal 
co.co.co
. di 
turno. Cio� quello che capita di norma al di fuori dei libri di software 
engineering...
Non mi pare che al momento Python sia in grado di reggere tutto questo.

 
-- 
-riko

 Non mi pare che al momento Python sia in grado di reggere tutto questo.
Scusa, proseguendo in questa maniera andiamo pesantemente OT.
Rimane pero' il problema di *dimostrare* la tua affermazione. Da quanto
leggo, mi sembra che tu di Python sappia circa nulla e di conseguenza
stai facendo affermazioni di inadeguatezza su una piattaforma che non
conosci.
Certo, ci metti un "mi pare". Resta il fatto che io non entro nei gruppi
di medicina "mi pare" dicendo quello che mi passa per la testa. Se
faccio un'affermazione, faccio in modo che sia quanto piu' possibile
circostanziata e dimostrabile. Se riporto una mia opinione, cerco di
fare in modo che sia motivata, e tipicamente che riguardi qualcosa che
conosco.
*Se* vogliamo discutere dell'adeguatezza di Python ad uno scopo
specifico, ti suggerisco di spostarci sul gruppo di Python, dove avrai a
disposizione non solo il mio parere, ma quello di molti altri Pythonisti
con esperienza anche superiore alla mia. 
Imposto ovviamente il follow/up (ma non il cross-post, per cui se hai
intenzione di proseguire di la, cross-posta di la e da li in poi
scrivero' solo di la riguardo questo sotto-thread).
-- 
-riko

 inaffidabili...
faccio un esempio pratico: quando fai un deploy a caldo, su un as di cui 
non sai quanto sia l'uptime ne quanti altri deploy a caldo ha subito, 
scommetteresti cinque euro che � andato tutto bene senza leggere i log?
e quando la tua applicazione smette di erogare il servizio, quante volte 
� dovuto ad un tuo errore di programma e quante invece alla necessit� di 
un riavvio dell'as per [esaurimento spazio memoria permgen | esaurimento 
thread pool taldeitali | altri motivi che tornano magicamente a posto 
dopo il riavvio]?
per carit�, sono anche architetture che mi affascinano, per� � oggettivo 
che all'atto pratico complessit� dello stack java == fragilit�.

 scommetteresti cinque euro che � andato tutto bene senza leggere i log?
No certo.
Non sarebbe una procedura da produzione per�. Serve per lo sviluppo.

 conosci.
Hai ragione, stiamo andando OT; per� consideriamo solo questo: devi
costruire un'applicazione per accedere ad un DB Oracle non nuovissimo
che sai verr� aggiornato prima o poi.
Cosa ti serve per Java e dove lo trovi? Scarichi direttamente dal sito
Oracle il driver JDBC ultima release, che funziona con tutte le versioni
pi� recenti di Java, e puoi sviluppare l'applicatione sul tuo PC,
trasportandola poi su un altro ambiente senza colpo ferire.
Al pi�, se hai prodotti molto datati, tipo Oracle DB 8.x o Java 1.3,
devi prendere una versione del driver un po' pi� vecchia, tutto qui. Ma
� molto probabile che l'applicazione continuer� a funzionare anche
aggiornando in seguito il driver.
Stessa situazione, cosa server con Python? Intanto, non � chiarissimo
dove trovare il necessario: su OTN (Oracle) c'� scritto di usare
cx_Oracle, ma ovviamente Oracle non ti supporta e dopo che hai speso
svariati keuro per il canone di assistenza non � proprio il massimo.
Poi, in ogni caso, cx_Oracle richiede l'installazione del client Oracle,
che anche nella versione Instant � un affare abbastanza intrusivo e
comunque � dipendente dal sistema operativo.
Poi devi trovare tra i vari file di cx_Oracle la combinazione giusta tra
versione di Python, versione dei driver Oracle e versione del sistema
operativo corrispondente alla tua situazione. Se ti va male, es. usi
Solaris, ti tocca anche provare a ricompilarlo.
Quasi sicuramente, al primo upgrade massiccio del sistema in servizio
devi ricominciare da capo.
Non � nulla di impossibile, ma ritornando al punto: ti sembra
praticabile da tutti? Ti sembra una soluzione sostenibile a medio/lungo
termine in una realt� aziendale?

 termine in una realt� aziendale?
Allora, come dicevo, io *non* ho usato Python + Oracle in produzione.
Ergo non posso parlare in dettaglio.
Per tornare alle tue domande:
1) non mi sembra praticabile da tutti. come non mi sembra praticabile da
tutti gestire un progetto ventennale enterprise su qualunque
piattaforma. Dovremmo metterci d'accordo se stiamo lavorando con
professionisti, buona approssimazione di essi o caprettari.
Se siamo nella terza, direi che qualunque cosa funzioni, in qualunque
piattaforma, siamo nel campo dei miracoli.
2) Sostenibile a lungo termine? Si. Sto semplicemente usando una
libreria open source nel mio progetto. Ne usiamo tante, non ho motivo di
credere che questa sia diversa (a meno che tu non abbia fatti che lo
dimostrano, nel qual caso di credo). 
E in tutto questo il problema si pone *usando* oracle. Senza sforzo
avresti potuto proporre casi ancora piu' sfigati per usare Python (per
esempio lavorare in un ambiente che non fa le minime assunzioni di
interoperabilita' fra Java e il resto del mondo). In questo caso ti
avrei risposto decisamente "Jython". E la cosa sarebbe finita.
Oltretutto il punto non e' "e' Python adatto al 100% dei progetti?"
(rivoltabile con "e' $X adatto al 100% dei progetti?"). Il punto e': e'
Python una soluzione robusta e professionale ai problemi enterprise?
Su questo posso dirti senza riserve: *si*. Altre persone qui te lo
confermeranno. Questo non toglie *nulla* a Java. Il punto erano
semplicemente le tue assunzioni su Python basate su nulla
(apparentemente, non mi hai contraddetto quando ho detto che IMHO tu non
conoscevi il mondo Python, suppongo che sia vero).
-- 
-riko

 Non sarebbe una procedura da produzione per�. Serve per lo sviluppo.
Non e' una procedura "da produzione" perche' e' fragile in Java oppure
perche' non credi che lo sia e basta?
Per esempio nel mondo di erlang addirittura l'hot swap del codice e'
pratica comune e consolidata. Qualcosa che ti fanno vedere pure in un
libro introduttivo come si fa.
E normalmente nessuno si aspetta che vada male (certo, come tutte le
cose, ha passato i test unitari ed e' stata fatta anche su un server di
test, ma queste sono normali procedure per un qualunque aggiornamento).
-- 
-riko

Il 10/10/09 15.05, cicap ha scritto:

perch� dici che non sarebbe una procedura di produzione?
in produzione non fai deploy a caldo?

 engineering...
ah, questo tu intendi per "cose serie"?
allora stiamo equivocando, io intendo altra cosa. per me si tratta di 
applicazioni che hanno un certo livello di criticit�, come minimo dei 
requisiti di ha. i clienti mi chiedono questo quando parlano di "cose 
serie".

rootkit ha scritto:



Scusa ma non capiso bene. Parterndo dal fatto che la provedura di deploy
delle applicazioni java su molti AS non e' sicura a caldo, argomenti un
confronto fra le 2 piattaforme ?
Eventualmente vediamo come in Java e in Python vengono eseguite le
Applicazioni server e vediamo vantaggi e svantaggi. Che io sappia La Sun e
Java hanno sfondato nel mondo delle applicazioni Server, ad esempio contro
MIcrosoft, proprio perche' offre una Soluzione nel suo complesso piu'
articolata , scalabile, con varie alternative e vari prodotti alternativi.
Io non conosco l'Architettura Server side di Python, pero' mi sento sereno
con quella di Java che al momento e' indiscutibilmente il punto di
riferimento nel mondo sertverr. Il deploy a caldo nonmi pare possa essere
preso come metro di giudizio perche' e' come valutare una automobile dalla
cuitoura dei sedili


 confronto fra le 2 piattaforme ?
premesso che (come ho gi� detto) non intendo fare il confronto fra le 
due piattaforme, ma la tua affermazione mi pare gi� una argomentazione 
sostanziosa. il fatto che per aggiornare un programma in modo sicuro 
bisogna riavviare tutto l'ambaradan non mi pare una questione che passa 
in secondo piano, specie se si parla di applicazioni critiche e se si 
considera che le cause sono problemi congeniti (e sostanzialmente 
irrisolti, almeno fintanto non prender� campo in questo settore l'osgi) 
del classloader. per la serie: se non � sicuro caricare e scaricare 
moduli a runtime per un ambiente che vuole essere modulare (pensa a 
jboss, microkernel e "tutto � un deploy") allora di cosa mi posso fidare?

 libro introduttivo come si fa.
Non credo che in generale l'hot swap del codice sia un problema neppure 
nel mondo Java. Ad esempio non ho mai riscontrato problemi con la 
ricompilazione al volo delle JSP.
Il problema � l'hot swap di tutta l'applicazione, che � un caso particolare.

rootkit ha scritto:

Non dico nulla di nuovo per te: se puoi evitarlo lo eviti. Altrimenti lo 
usi sapendo che dopo un certo numero di deploy rischi di dover riavviare 
il tuo AS.
Secondo me in questo discorso conta molto il numero di deploy che il tuo 
server � disposto ad accettare.
Esperienza mia su Tomcat 5: applicazioni JSF supportavano tre deploy, 
dopo si rompeva tutto: in effetti cos� � frustrante. Con altri AS non 
c'era questo limite, per cui se riesci a fare 10-15 deploy senza 
riscontrare problemi, nel frattempo trovi anche il tempo per un riavvio.
A meno che tu non intenda modificare 20 volte alla settimana 
l'applicazione in produzione.
Ma in conclusione non posso non confermare quanto dici (anche solo 
perch� � fastidioso in sviluppo): si � un problema e speriamo venga 
risolto con Java 7 (i nuovi moduli) e/o OSGI.

 ha scritto nel messaggio 
news:hapma7$2sj$1...@tdi.cu.mi.it...


 molto controllato, non ha caso � stato copiato a piene mani da .net
(Quota bene, per favore)
Guarda che semmai � .net che � una copia di Java.