[Python] 2 neo pythonisti che affrontano un orda barbara di javisti - con quasi-rissa finale

[Alan Franzoni]

2011/3/31 Carlos Catucci <carlos.catucci a gmail.com>:
>>> Tranquillo: non esistono :-)
> Ammetto di essermi fermato a java .15 e quindi non o come sia evoluto
> il linguaggio.

Cambia pochissimo tra 5 e 6 a livello di linguaggio; sono solo quasi
miglioramenti infrastrutturali.
> Che i citati siano un po' da raffinare (passami l'eufemismo) si, ma
> stiamo parlando di tool esterni. Come se dicessi che quell'auto e'
> eglio di quell'altra perche' il concessionario ha un salone piu'
> curato.

Sto dicendo che non conta solo il linguaggio, contano tutti i tool che
ci stanno intorno.

L'esperienza di Android e IOS insegna: è l'ecosistema che fa la
differenza. Se ci metto poco a programmare, ma poi è un parto per ogni
dipendenza esterna, il risultato è che tenderò a reinventare ogni
volta la ruota piuttosto che riutilizzare ciò che è già disponibile.

> Se m metto a cercare sul repository Ubuntu di API, warapper, libraries
> etc per python non arrivo a fine prima idi sera (va bene che non e'
> prestissimo ;) ) e il concetto di battery included non e' di Java.

Per API intendo un set di interfacce ben preciso e condiviso, che mi
permetta di programmare una certa funzionalità e scegliere a
posteriori una specifica implementazione - come appunto la DB-API o
WSGI. Il mondo Java ne è letteralmente stracolmo; ovviamente la
definizione e l'evoluzione delle interfacce porta via un bel po' di
tempo, ma consente di programmare per una specifica e non per
un'implementazione.

>> Specifica standard per il runtime: vi è mai capitato che su una certa
> ne esistono diversi ma non mi sembra che java se gli manca un package
> se lo vada a cercare da se

Ne esistono diversi: quali?

Poi Java non è che "se li vada a cercare da sè", ma ha un sistema di
build e dependency management quale Maven che consente di specificare
in maniera *dichiarativa* i requisiti di un'applicazione.

> Un ottimo sviluppatore a oggetti lavora bene con qualsiasi linguaggio
> ad oggetti. Ma non ha nulla a che vedere con il fatto che un
> linguaggio sia migliore di un'altro.

Questa tendenza però rischia di diventare dannosa per la community.
Sentirmi snobbare una soluzione già true & proven su un'altra
tecnologia solo perché "sarebbe l'approccio di Java" mi fa schifo.
Sentirmi rigettare alcuni principi di sviluppo ( SOLID ) perché 'In
Python non servono' mi sembra una vaccata. Però succede, e ti confesso
che mi succede molto più spesso sui progetti Python che non su quelli
Java.

> Esprimere un punto di vista personale su due "oggettI" non mi sembra
> spocchia. Au contraire trovo tantissimi Javisti che quando dici  cche
> usi Python ti guardano come a dire: "Si va bene, torna pure a giocare
> con i cubetti di legno e lasciaci lavorare".

E anche quegli sviluppatori Java saranno probabilmente spocchiosi e
non faranno scelte adeguate :-)


-- 
http://www.franzoni.eu - public@[mysurname].eu
Latest blog post: Using twisted trial as a test runner with
zc.buildout http://bit.ly/fAYiQl