2011/3/31 Carlos Catucci <carlos.catu...@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 _______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
