[Python] sviluppare applicazioni android tramite python
enrico franchi
enrico.franchi a gmail.com
Gio 29 Dic 2011 18:28:28 CET
2011/12/29 Carlo Miron <miron a python.it>
> Personalmente non ne sento il bisogno, ma non e' completamente chiaro
> > perche' non ci sia.
>
> Perche` ci sono i dict?
>
Non sono convinto che ci sia una correlazione. Mi spiego... switch e dict
hanno sicuramente uno use-case comune.
Pero' strutturalmente stiamo comparando un costrutto di controllo di flusso
con una struttura dati.
*Sicuramente* Python ha i dict e il pattern standard per sostituire uno
switch e' un dict[0].
Pero' di per se, siccome un dict potrebbe, con le stesse tecniche,
sostituire anche un if. Eppure nel caso di if si e' (giustamente) deciso
che era meglio lasciarlo li. Ovviamente sarebbe stato poco pratico non
avere if.
La mia personale idea e' che lo switch non sia stato messo e basta e *poi*
e' stato "scoperto" il giochino con i dict. Posso ovviamente sbagliare.
-----
[0] in realtà in OOP e' un po' che ci si scaglia contro abuso di if e
switch -- specie switch su variabile di stato -- in favore di altri
costrutti piu' OOP. Di fatto un dict semplifica alcuni use-case che in OOP
generica si fanno con una classe/strategy e rende bruttini altri -- che si
possono continuare a fare con una classe/strategy --
True. Ma hai usecase in cui uno statement switch sarebbe la cosa giusta™?
>
Non davvero. Forse si riesce a trovare il caso specifico, ma non e' che sia
molto rilevante.
> Ma non e' che direi che Python sarebbe "peggiore" se avesse uno switch.
>
> Ok. Ma probabilmente non sarebbe "migliore". E questo IMHO e`
> sufficiente per non.
>
Anche per me.
> > Pensa, io trovo molto sensata la mancanza di ereditarietà multipla.
> Primo,
> > per averla ad minchiam come in C++ e' meglio non averla.
>
> Concordo. *Ma* nel caso di Python trovo sensato il permettere
> l'ereditarieta` multipla piuttosto di specialcasizzare classi ed
> interfacce. Ma magari sbaglio, boh.
>
Se sbagli, siamo in due.
> > Ma no... non e' che "ha qualcosa che non va". E' semplicemente concepito
> > diversamente. Smalltalk, giocaci senza IDE.
>
> Eh, grazie al cazzo, riko. Allora tira fuori anche l'altro caso limite,
> FORTH.
> No, spiace, nessuno dei due giustifica l'(ab)uso di IDE da parte di Java e
> C#.
> Entrambi usano la metafora del file, e pertanto dovrebbero essere
> decentemente usabili con un editor. No.
>
Eh, che devo dire. Poi anche qua vorrei spezzare una lancia.
Java senza IDE e', a mio avviso, una rottura per *tre* motivi.
1. la storia dei package. e immagino che senza gli IDE semplicemente si
sarebbe diffuso meno l'uso di usare i package (cosa che io trovo piuttosto
buona). E qui il problema e' quando sposto un file in due parti diverse.
Pero', a diversi livelli lo stesso problema e' presente anche in Python e
in tutti i linguaggi che non separano completamente il nome di un modulo
dal nome del file dove si trova. E poi e poi.
2. Quelli che hanno scritto la libreria standard hanno parlato poco fra
loro e ci sono un sacco di cose non ortogonali. Brutto, eh. Pero' questa e'
una cosa che a vari livelli capita anche in altri linguaggi: magari la
libreria standard e' fatta meglio, pero' le librerie esterne comunque hanno
nomenclatura da ricordare.
3. import esterni: ma qui, devo dire, e' un problema che volendo abbiamo in
tutti i linguaggi. E' che e' oggettivamente piu' comodo scrivere
collections.defaultdict e avere l'IDE che ti chiede se vuoi importare il
modulo collections che non averlo e dovere 'ioimport collections[ESC]''. E
qua con vim va anche bene... prendi un editor appena da meno e vedi che
smazza.
Il problema e' che gli IDE Java fanno un sacco di roba che sarebbe bello
facessero anche quelli per Python. E sono cose che temo strutturalmente non
possono fare ed e' qualcosa che pago volentieri per gli altri vantaggi di
Python. Pero' se fosse possibile, sarebbe meglio e basta. IMHO.
> Non ha nulla che no va, *soprattutto* nella sintassi. Che puo` non
> piacere, percaritadiddio, ma e` abbastanza inattaccabile.
>
Non la sto attaccando. Ho detto solo che la sintassi non mi piace
particolarmente. :)
> Appunto. Quindi, checcentra con Java e .Net?
>
Principalmente che una parte dell'elite smalltalkiana si e' spostata su
Java e poi hanno fatto Eclipse.
Io credo che queste persone abbiano avuto un forte influsso su Java.
> > Certo, il fatto che un linguaggio richieda tools molto sofisticati può
> > essere un indice di un qualche problema. Per esempio del semplice fatto
> che
> > e' verboso. E' una cosa che in genere mi scrota, ma a volte amen.
>
> Definisci "amen", please. :P
>
C'e' di peggio. Voglio dire Perl e' meno verboso di Python, eppure...
Quindi la semplice verbosità non e', dal mio punto di vista, un problema.
Il problema e' che la gente ha scritto Java verboso *concettualmente*, non
solo sintatticamente. Ma non e' un problema del linguaggio, e' di quelli
che lo usano. D'altra parte Java non potrebbe avere reflection diversa da
quella che ha volendo mantenere il suo "security model" e le famigerate
checked exceptions.
> Come editor dopo tanti esperimenti mi sto adagiando su vim.
>
> /me mette un braccio intorno alle forti spalle di riko, si volta verso
> teknico, e sorride.
>
/me sorride pure...
> > Fatto sta che ormai Java lo conosco bene, so come muovermici intorno e
> mi e'
> > piuttosto comodo.
>
> Brr. Esci da questo corpo.
>
LOL... :)
In realta' le cose che piu' mi mancano (nel linguaggio) sono first order
functions e lambda.
Marginalmente i generatori.
> Non so su C#... ma su Java non e' particolarmente scomodo.
>
> Nel senso che non sei costretto ad inginocchiarti sui ceci, giusto?
>
Probabilmente mi sono perso qualcosa... da qualche tempo anche Java ha il
for su iterabile.
Ok, mancando delle tuple sulle Map e' subottimale, ma non eccessivamente
drammatico.
Ridefinisci "amen", please. :PP
>
Dai, non e' la cosa peggiore. In Python abbiamo vissuto per un po' senza la
sintassi dei sets, per dire.
>
> > Oggettivamente a seconda del codice che scrivi puö facilmente capitarti
> > molto poco di lavorare a quel livello di astrazione.
> >
> > A me capita spesso.
>
EEEh?
> Aspetta pero'. Questi sono una serie di aspetti complicatissimi. Uno,
> quello
> > che fa esr e' poco esplicativo. Probabilmente con la testa che ha prende
> su
> > K in 4 giorno invece che 2.
>
> Eh?
>
Il linguaggio K.
> Il problema e' chi sei prima di impararlo. Mi spiego: se sei un cattivo
> > programmatore prima di imparare Python, impari Python in 3 giorni e
> continui
> > ad essere un cattivo programmatore. Adesso scriverai cattivi programmi in
> > Python invece che in VB! :)
>
> Beh, suvvia, e` un minimo migliorameno, comunque :P
>
Che puo' peggiorare la mia qualità della vita, pero! :)
>
> > Pero' se hai un team ben agguerrito su Java, che sa il fatto suo in Java
> non
> > sono convinto che passando a Python diventeranno improvvisamente molto
> piu'
> > produttivi. per tutta quella serie di menate ambientali che uno impara
> piano
> > piano con il tempo.
>
> Io invece sono ragionevolmente convinto che *non* sia vero, purtroppo.
> Amen (!)
>
Dici?
> Scusa, non sono d'accordo. Contestualizziamo. C# e' un linguaggio ad
> > oggetti. Mi risulta anche uno piuttosto pulito.
>
> Certo, se non ti piace la sintassi di Smalltalk... :P
>
Non e' che non mi piace, non mi fa impazzire. Preferisco la sintassi di
Python, o quella di Lisp.
Poi in Smalltalk non ho scritto 2 righe di codice 2, quindi e' difficile
che il mio parere sia forte in proposito.
--
.
..: -enrico-
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20111229/1172e175/attachment.html>
Maggiori informazioni sulla lista
Python