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

Simone Federici s.federici a gmail.com
Ven 1 Apr 2011 12:25:10 CEST


2011/4/1 Alan Franzoni <mailing a franzoni.eu>

> 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.
>

e tra la 6 e la 7 ancor meno :-)


> > 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.
>

Lo standard serve ai vendor per vendere i loro prodotti.... java è stracolmo
di standard che non fanno quello che serve alle persone quindi fai il 90%
standard e il 10% legato al prodotto....

e chi ci guardagna è solo chi arriva con la soluzione in mano, vedi toplink
anziche hiubernate, vedi kodo ecc.... sembra che il motto sia sviluppate
standard cosi noi vendiamo.


> >> 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.
>

c'è un progetto setuptools2 che scrive in modo dichiarativo su xml le
pipendenze...
non credo che ci guadagneremo nulla, meglio scrivere in python.

setuptools e pypi non hanno niente da invidiare a maven



>
> > 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.
>
> ma che centra con il linguaggio.... i talebani li trovi ovunque.
tu ne hai visti più in python e io ne ho visti più su java... ma questo non
ci deve portare a dire javisti/pythonisti non scivono solid... dipende dal
programmatore non dal linguaggio



> > 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 :-)
>

parliamo di produttività, è l'unica cosa che conta....
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20110401/994733c0/attachment.html>


Maggiori informazioni sulla lista Python