[Python] sviluppare applicazioni android tramite python

[enrico franchi]

2011/12/29 Carlos Catucci <carlos.catucci a gmail.com>:

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

Guarda, io discuto su quel perche'. Sono d'accordo che visto l'insieme
di features di Python switch non aggiunge particolarmente nulla.
Aggiungo poi che uno switch in Python non necessariamente dovrebbe
assomigliare allo switch in C (anzi).

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

Le lambda, per come sono in Python, sono effettivamente quasi inutili.
Ci sono degli use-case per cui complessivamente mi dispiacerebbe se
sparissero, pero' effettivamente si usano poco. C'e' chi dice sia un
bene.

In molti casi avresti uno switch che fa dispatch su un valore e in
questo caso il dizionario e' perfetto. Pero' ci sono anche i casi in
cui bisogna essenzialmente compiere delle azioni. E a volte vale la
pena di tirare a mano strategy. A volte pero' e' un po' un overkill.

In questi casi, io dico solo che puoi:

1. associare alle chiavi delle lambda

{'a': lambda: ...,
 'b': lambda: ...,
 ...}[k]()

2. associare alle chiavi delle funzioni fatte con def

def cl1(...): ...
def cl2(...): ...

{'a': cl1,
 'b': cl2,
 ...}[k]()

3. usare una classe (o al limite un modulo)

class Dispatch(object):
    def a(...): ...

    def b(...): ...
    ...

getattr(Dispatch(), k)()

oppure con staticmethod e non usando un'istanza della stessa.

Ecco... diciamo che la prima ha utilita' limitata (nel senso che in
lambda ci va quasi nulla).
La seconda e' abbastanza verbosa.

La terza e' concettualmente molto piu' complicata. Diciamo che in
questi casi mi viene proprio voglia di ripensare il codice e di
cambiarne la struttura e passare da:

def function(...):
    class Dispatch(object):
        def a(...): ...

        def b(...): ...
        ...

    getattr(Dispatch(), k)()

al cominciare a vedere se si riesce a tirare fuori la classe e ad
eliminare proprio function. Poi bisogna vedere caso per caso, ecco.

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

Guarda, mai usato VB. Io personalmente non ho visto grossi casini su
switch. E' uno statement piuttosto semplice. Cioe' l'unico casino e'
se hai semantica fall-through (come in C) e non lo sai: ma sono
proprio errori da iper-principante del linguaggio.

La cosa piu' "brutta" e' che alla gente viene in mente troppo spesso
di scrivere codice il cui comportamento fa dispatch esplicito su una
variabile invece di strutturare meglio il codice.

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

Non sono convinto che si scriva metà del codice, non sono convinto che
sia più efficiente.
Aggiungo, non mi piace l'ereditarietà di implementazione. Trovo che
sia utile relativamente in pochi casi e che richieda un'attenzione
molto elevata. Complessivamente i fallimenti usando altre tecniche
sono piu' spettacolari e si acchiappano prima con una manciata di
unit-tests.

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

Guarda, io non conosco abbastanza bene il dominio applicativo per
entrare nel problema di design.
Una fattura e' una bolla?

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

Complessivamente anche io anche il C++ e si, lo appresi su
Stroustroup, per poi completare con i vari Josuttis, Meyers e Sutter.
Java per me e' una cosa recente: me lo guardai ad intervalli regolari,
ma fino alla 1.5 lo ho trovato semplicemente inutilizzabile e scartato
immediatamente.

In C++ personalmente le rare volte che avevo bisogno di ereditarieta'
di implementazione usavo un trucco che permette di avere i Mixin. Per
il resto il mio C++ e' sempre stato molto piu' basato sul polimorfismo
statico (templates) che su quello dinamico. Siccome le due cose
funzionano non troppo bene insieme, credo che C++ sia stato una grossa
influenza nel *non* usare ereditarieta' spesso.


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

Dreamweaver lo ho sempre evitato. Costoso, sopravvalutato.
Ma ci sono anche IDE fatti bene, eh. ;)

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

Boh. Mi sembra insostenibile... non ho un concetto di "interfaccia
adatta alla programmazione". Per me se ho un terminale decentemente
behaving (e iTerm2 e' eccezionale, pure Terminal non e' male) ho più o
meno tutto quello che mi serve (si ok, vim, make, python, cc, etc etc
etc).

Ultimamente ho perfino trovato un uso per le finestre "fullscreen di
Lion". Massimizzo macvim. Massimizzo iTerm e passo da uno all'altro.
Da qualche parte ho anche chrome per la doc. Ho tutto quello che mi
serve.

Io come piattaforma di sviluppo *scelgo* OS X. Conosco tanti
sviluppatori che sono soddisfattissimi su OS X.

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

In realta' anche vim lo e'... :)

Sublime lo ho provato per un po', ma non sono riuscito a giustificarmi
l'acquisto. Mi ricorda TextMate . Adesso hanno anche rimesso mano a TM
stesso, si vedra'.





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

Uh?

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

Sono d'accordo che Python sia facile da imparare. Non mi ricordo piu'
pero' quale era il punto?

Se era il tempo di apprendimento 3 giorni sono una buona stima per il
"core" del linguaggio.
Ne manca ancora... E poi bisogna vedere quanto ci va per prenderne la
mentalita'.
Continuare a scrivere Java in Python non garantisce molto successo.



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

Un punto di vista interessante.

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

Questo e' male.





-- 
.
..: -enrico-