[Python] sviluppare applicazioni android tramite python

[Carlos Catucci]

>
> Diciamo che è stato ben pensato. Purtroppo tante cose carine non possono
> entrarci e va bene cosi'.
>

Mancano cose caine, vero, ma meno forse che ad altri, diciamo colleghi,
blasonati

>
>


> E'... ma quale e' la logica di *non* avere uno switch statement?
> Sinceramente non lo so.
> Personalmente non ne sento il bisogno, ma non e' completamente chiaro
> perche' non ci sia.
>

Perche' non serve, perche' impiega molti piu' cicli per essere risolto,
perche' puo' generare errori logici, la lista sarebbe lunga.
E' che la filosofia di base che io vedo in Python e' semplicita, puilizia
ed eleganza.


> Ci sono casi in cui sento profondamente che un dizionario e' la cosa
> giusta da usare. Casi in cui e' un pochetto meglio una classe (a me per
> dire un dizionario infarcito di lambda non piace mica tanto).
>

Concordo, io non amo le lambda, mi fa piacere che esistano, se servono le
uso, ma sono come le RegExp, non mi fanno impazzire. Pero' ci sono
tantissimi casi in cui un semplice dizionario (al limite con liste e
dizionari in pancia) fa il lavoro di una classe senza dover scrivere una
classe ad hoc. Poi torna il discorso del paradosso dell'ingegnere: se
questa cosa e' abbastanza general purpose da poter essere riusabile, ben
venga la classe nel suo package coi' da riusarla, fosse pure un dict di
poche entry.  E viceversa a volte.


> Ma non e' che direi che Python sarebbe "peggiore" se avesse uno switch.
>

Non sarebbe coerente. Ripeto da come ho interpretato io la logica di
Python, lo switch e' dannosso, poco leggibile, suscettibile di creare
casini (non per colpa dello statement ma di chi lo usa a volte a
sproposito, me ad esempio quando lavoravo in VB).


>
> Parliamodi Java, per fare un esempio. No, ereditarieta' multipla no,
>>
>
>  Pensa, io trovo molto sensata la mancanza di ereditarietà multipla.
> Primo, per averla ad minchiam come in C++ e' meglio non averla.
>

Ma se la hai fatta bene e' di una comodita' unica. Certo e' un problema di
approccio e di design. Lo stesso problema due diversi progettisti lo
progetteranno in manierea differente, magari di poco ma non saranno mai
identici i due programmi (e non parlo di nomi di variabili o di usare for
al posto di while). Per lo stesos motivo puoi progettare SENZA usarlaa ed
averla, oppure usarla per scrivere la meta' del codice e piu' efficiente,
se hai le idde chiare.

Faccio esempio idiota che faccio spesso per spiegare il concetto quando (mi
capita) vesto i panni del docente (principlamente corsi organizzati da
qualche Lug o Pug).

Come e' fatta una bolla? Testata (anagrafiche) e corpo (catalogo).
Come e' fatta una fattura? Testata (anagrafiche) e corpo (catalogo +
listino).

Se posso usare l'ereditarieta' multipla fattura eredita da Bolla e da
Listino.

Ripeto, posso farlo anche in altro modo, ma cosi' e' piu' naturale e
semplice.

Secondo credo che in ~8-9 anni di Python l'ho usata per la prima volta 2
> mesi fa. Principalmente perchè per pigrizia mentale ho copiato il design
> precedente di una vecchia incarnazione e non mi sono deciso a fare con
> strategy quello che facevo con template method.
>

Non ho mai affermato che senza non vivi ne che la usi tutti i giorni.
Dipende molto da dove arrivi. Io la programmazione a oggetti la ho appresa
su C++ (sono stato tra i pionieri in questo paese per quel linguaggio,
pensa che ho probvato d apprenderlo sullo Stroustrup, e seno recidivo, ho
cercato di apprendere anche C sul Kernigham & Ritchie (ciao Denis, sei
sempre il meglio)).


> Poi io sono decisamente sul lato "deleghiamo".
>

Io pure, in tutti i sensi. ;)


> Non e' detto che siano influenzati dalle /idee/ di chi li esegue.
> Scientificamente parlando e' un po' come affermare la malafede.
> No, credo che siano facilmente influenzabili da semplici condizioni al
> contorno difficili da valutare. Qualunque sia il risultato.
> Per quello mi interessava vedere gli studi.
>

Io penso che sia umano influenzare i risultati. Non e' una colpa o una
mancanza.


> Ma no... non e' che "ha qualcosa che non va". E' semplicemente concepito
> diversamente. Smalltalk, giocaci senza IDE. E sinceramente, al di la che
> non mi piace la sintassi, non mi sembra abbia molto che non va. E' un caso
> estremo: e' un linguaggio che essenzialmente non e' file-based e di
> conseguenza un semplice editor non ce la potrebbe proprio fare.
>

Io direi che non ce la puoi fare eper tanti motivi. Proviamo a diseganre
una Form. WxPython sembra Disneyland a confronto. :)


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

La verbosita' va bene se hai l'IDE che lavora per te. Altrimenti altro che
scrotare solo. Resta il fatto che a me viene da pensare a chi usa
Dreamweaver. Se poi prvi a toccare auzlcosa fuori rischi che non vada piu'
neppure dentro DW. Naaaah. Se non posso lavorarci BENE anche con Vim,
allora se posso evito.


> Ho mollato wing per PyCharm. Dovrebbero essere grosso modo equivalenti.
> Diciamo che usando gia' IntelliJ la cosa per me ha molto senso. E in
> aggiunta, come dire... GTK su mac os non e' esattamente un fiore. Più
> PyCharm ragiona con pypy... su cui piano piano mi voglio spostare.
>

Io su MacOsX (sto scrivendo da un MacBookPro 13") non ci programmo.
Impossibile. Ha una interfaccia troppo pensata per l'utente che fa cose
comuni (navigare, vedre filmati etc.). Inadatta alla programmazione. Uso le
VM con su Linux e sviluppo li.


> Come editor dopo tanti esperimenti mi sto adagiando su vim.
>

Io adoro Vim, da sempre. Pero' il citato Sublime text 2 ha i suoi perche'
credimi (ah e' scriptabile in Python)


> Ammetto candidamente di non conoscere C#. So che ha un sacco di cose che
> Java non ha e che sarebbe bene che avesse. Forse alcune delle più critiche
> le aggiungeranno con la 8, dopo tipo 20 anni di esistenza. Ma vabbe'.
>

C'e' da dire una cosa: C# a parte i penosi tentativi di Mono, vive solo nel
dorato ambiente di .NET, dove tutto e' fato a suo uso e consumo. Java
invece deve arrangiarsi a girare dove capita. Pero' una compilazione Jit
come Pthon potevano mettercela e che cazzo.

Fatto sta che ormai Java lo conosco bene, so come muovermici intorno e mi
> e' piuttosto comodo.
>

Io lo ho ripreso amano perche' sto guardando Android. Devo dire che Google
ha fatto un ottimo lavoro. Anche se mi spiace non abbiano usato Python,
devo dire che con Java si programma nbene per quell'OS. Ma sono cose
specifiche appunto. IUn po' come C# in .NET. Gioca in casa. Non puoi
portarlo (e la portabilita' era uno dei punti di forza di Java al suo
esordio).


> Non so su C#... ma su Java non e' particolarmente scomodo. E' scomodo
> principalmente in C++ (veramente una cifra) o in C.
> La rottura di palle (in Java) e' che manca una sintassi fancy per
> costruirli, ma amen.
>

Invecchio e divento pigro. Ho sempre pensato d'altronde che un buon
developer debba esserlo. :)


> Oggettivamente a seconda del codice che scrivi puö facilmente capitarti
> molto poco di lavorare a quel livello di astrazione.
> A me capita spesso.
>

A me pure, sara' il mio stile ma, fino all'avvendo di json, che aiuta
tanto, era pratica comune usare liste e dizionari (o i loro quasi
equivalenti per altri linguaggi).


> Si e no. Nel senso che ci sono librerie che sono complesse "il giusto".
> Sul progetto piccolo non le paghi, su quello grosso non le senti realmente.
>

Punti di vista. A me doverle usare per gestire progetti di una certa
complesista' mi pare innaturale, ma ripeto, sono gusti personali.

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. Per il resto mi sentirei anche di
> confermare la cosa. Python lo si impara facilmente in poco tempo.
>

Eric Rayomond e' un caso. Gli altri perio' non sono persone note ma
developers cme noi, gente comune, con qualche anno di esperienza si, ma non
dei GVR o Torvalds o Wall. Certo se ti dico i nomi di questi non ti dicono
nulla, se rti cito Eric sai di chi parlo. Tutto qui.


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

Meno cattivi perche' Python un po' porta a migliorare. Ovvio che io lo
userei come linguaggio "didattico". Se parti e impari con Python poi hai
dei vantaggi con altri linguaggi. Io mi trovo a fare del C++ate in Python a
volte. Poi riguardo il codice e cerco di renderlo piu' pythonico.



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

Esattamente quello che dicevo io pure. Se hai un team di 5 persone dove 1
conosce Python e Java, e 4 solo java, non ha senso scrivere in Python. A
meno che il progetto non pèermetta di far apprendere Python ai 4 Javisti
prima dell'inizio delle ostilita' dichiarate :)


>  Au contraire, li succedono anche piu' spesso. E non dico sia colpa del
> linguaggio. Solo che come PHP, un certo tipo di semantica, di strutture
> etc. portano a lavorare in maniera tale da favorire il casino. Non e' colpa
> del linguaggio in se, ma delle strutture mentali di chi lo usa.
>
> Scusa, non sono d'accordo. Contestualizziamo. C# e' un linguaggio ad
> oggetti. Mi risulta anche uno piuttosto pulito.
>

Certo. Ma tutto l'abaradan che lo circonda (ASP.NET, Silverlight e
compaginia cantante) oltre che ad un framework msotruoso (veramente
impressionate il numero di "cose" che ha gia' pronte), unito al fatto che
spesso a capitanare progetti enterprise in .NET
 ci sono persone che di programmazione non sanno molto, porta a devianze di
questo tipo. La olpa non e' del linguaggio (come invece in PHP) ma ddella
complessita' circostante. Inoltre le interfacce sono spesso complesse,
usare una cosa che non conosci puo' essere avolte frustrante.

Io ricordo che per riuscire a lavorare con le Queue, dopo 15 giorni di
"anomalie inspiegabili" ne uscii fuori solo perche' avevavmo una consule m$
ogni tanto da noi, bravissima, le mancava 1 certificazione per diventare
Evangelist, che mi spiego' alcuni trucchi (scritti in caratteri corpo 1 con
color #FFFFFF su background-color #FFFFFF in fondo a qualche paper sul sito
MSDN :)


Se sai fare buona programmazione e design ad oggetti non sono esattamente
> convinto che il programma che scrivi in C# sia "intrinsecamente" poco
> mantenibile. Ci possono essere alcune feature mancanti che renderebbero lo
> sviluppo piu' rapido (anche lo sviluppo di "aggiunte"), ma non vedo perche'
> dovrebbe incasinarsi il design.
>

Beh essendo figlio di Java in un certo senso si porta dietro delle
"complicazioni" 8qualcuno ha citato i Path se ricordo bene, solo come
esempio) che altri linguaggi non hanno e che possono aiutare a fare
cavolate. Certo la predisposzione genetica da parte del team aiuta. Inoltre
legegre il codice per fare analisi qualitativa e' oltremodo piu' complesso
che non in python (anche la mera lumghezza media di un listato gioca a suo
sfavore).


> Se invece stiamo parlando del "Python effect" allora non aggiungo altro e
> fine della storia. Ma non e' esattamente colpa di C#, e' semplicemente
> colpa del fatto che di qua ci potrebbe essere un pochino di selezione a
> monte.
>

Ah beh quesllo si. Io preo' trovo che lavorando con Python e insgnandolo ad
altri che lavorano con me, il Python effect (inteso come miglioramenti
nella leggibilita', mantnibilita', meno bugs nascosti etc.) si nota.
E sono persone che vengono da vari linguaggi (Java, C#, C++, PHP)

Poi magari sono solo percezioni personali.


Carlos
-- 
If you have no voice, SCREAM! If you have no legs, RUN! If you have no
hope, INVENT!
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20111229/4faf6e4e/attachment-0001.html>