Skip to content

Alex Martelli a Firenze per la Pycon2

19 maggio 2008

Pycon2 banner
Pycon2, Pycon2. Il primo talk a cui ho partecipato è stato quello di Alex Martelli, über tech lead in Google.
Il titolo era “python per programmatori“. Python lo conosco (non da über python programmer) però ero curioso di sentire questo famoso Alex.

Python, Java e C[++]

Il taglio del talk era molto interessante, io venivo (tempo fa eh) dal mondo Java™ e ha fatto molti confronti sia con Java™ stesso che con C++ (che conosco ma odio profondamente).

Altra cosa interessante: Alex afferma che la filosofia di Python sia molto simile alla filosofia del C, perché? come perché! ecco qua i princìpi del C (li ho copiati rapidamente, se qualcuno ha la fonte di questi princìpi mi farebbe un favore a linkarli in un commento):

  1. fidati del programmatore;
  2. non impedire al programmatore di fare quello che va fatto;
  3. tieni il linguaggio piccolo e semplice;
  4. prevedi un modo solo per fare un’operazione;
  5. sii rapido anche se non portabile (ovviamente questo non è 100% pythonico).

Python ha solo azioni!

Un’altra osservazione di Alex che mi ha fatto pensare: “Python non ha dichiarazioni, ha solo azioni” (io aggiungo che forse i decorator sono al limite tra le due cose, da un punto di vista semantico sono dichiarativi mentre, a livello di implementazione, sono funzioni come tutte le altre).
Devo ammettere di non averci mai pensato. Parliamo di Java™, dichiarazioni ce ne sono, ad esempio di variabili, è un bene o un male? ora non ho una opinione in merito, mi piacerebbe che qualcuno mi desse o la sua opinione o uno spunto per ragionarci sopra.

Sempre nella presentazione diceva che non ci sono né parentesi per definire i blocchi, né parentesi obbligatorie (ovvio, oltre a quelle necessarie per modificare la precedenza degli operatori) nelle condizioni degli if, while etc. Tutto questo segue il pensiero di Edward Tufte che si può riassumere in “niente pixel sprecati” (Every pixel is precious, da una rapida ricerca in google). Tornando al discorso delle dichiarazioni, secondo voi sono pixel sprecati come le parentesi graffe per definire i blocchi?
E questi erano i punti salienti della presentazione. O almeno quelli che mi hanno colpito di più.

Duck Typing e Design Pattern

Poi ho avuto modo di fargli un paio di domande, cerco di riportare le risposte in modo preciso, anche se è impossibile vista la mia scarsa capacità di memorizzazione. Anzi per rendere tutto più simpatico parafraso un po’ sia le mie domande che le sue risposte.

Q: “Ciao Alex, duck typing di qua, dynamic typing di là, tutto molto bello, ma tanti (e anche tante aziende) pensano che avere un linguaggio static typed sia un vantaggio per la sicurezza del codice. Un controllo a compile time evita che ci siano sorprese a runtime. Cosa ne pensi a riguardo?”

A: “Be’ c’è un esempio che faccio sempre in questi casi, immagina di avere una riga del codice che somma due interi, i tipi sono giusti quindi il compilatore non batte ciglio. Il problema è che quello che dovevi fare in realtà non era sommare, ma sottrarre. Il compilatore ti ha illuso che le cose andavano bene, ma non è così. L’unico modo che hai per avere un codice sicuro non è il controllo del compilatore ma test, test e test. Ti consiglio di dare un occhio all’articolo di Robert Martin (aka Uncle Bob) Are Dynamic Languages Going to Replace Static Languages?.
Una cosa che proprio non capisco di Java è: Bar foo = new Bar();, è necessario il primo Bar? È ovvio che l’oggetto foo è di tipo Bar, perché devo scriverlo due volte?”

Q: “Design pattern, nel libro della Gang of Four sono presentati implementati in C++, altri libri li presentano in Java™. Come si comportano in un linguaggio dynamic typed come Python o Ruby? Sono tutti applicabili?”

A: “Non tutti i design pattern sono adatti a una implementazione in Python, ci sono dei video relativi alla questione che mi hai posto.”
[la risposta era più lunga, non mi ricordo molto visto che mi ero un po’ perso, be’ non faccio il giornalista…]

P.S. ho cambiato di nuovo il tema, è tornato quello di prima :/

From → computer, vita

6 commenti
  1. phil permalink

    secondo me le dichiarazioni e le parentesi sono inutili di x se’, ma se dobbiamo considerare la visibilita’ e la lettura del codice alla lunga posso risultare molto comode. Ho avuto modo di programmare in python e come linguaggio mi ha molto divertito pero’ la storia dell’identazione e’ un po’ rognosa

  2. Enrico permalink

    “Una cosa che proprio non capisco di Java è: Bar foo = new Bar();, è necessario il primo Bar? È ovvio che l’oggetto foo è di tipo Bar, perché devo scriverlo due volte?”

    Non sono d’accordo con questa critica.
    Immaginiamo che il comando sia:
    Bar java = new InheritedBar() //oggetto che eredita da Bar
    può python simulare esattamente questa situazione?
    Io non ne sono sicuro poiché non sono un esperto ma provo ad immaginare che un modo possa essere:
    python = buildInheritedBar() #funzione che ritorna un oggetto di tipo InheritedBar

    a questo punto in Java posso decidere di scrivere:
    java = new InheritedBar2() // altro oggetto che eredita da Bar

    posso in python scrivere:

    python = buildInheritedBar2()?

    da quel che mi risulta non è possibile poiché la variabile python è legata ad un tipo specifico dato dall’oggetto assegnato alla stessa. Se quello che dico è giusto giustifica l’esistenza del tipo statico di Java.
    Cosa dite?

  3. Grazie dell’ottimo riassunto! Vediamo se posso essere utile su qualche punto specifico…:

    a. un buon riferimento per “Spirit of C”: http://www.artima.com/cppsource/spiritofc.html

    b. un decoratore e` al 100% un’azione, NON una “dichiarazione”; e` *defininito* come azione proprio a livello semantico, perche` *per definizione* qualcosa come:
    @pippo(pluto)
    def paperino…
    SIGNIFICA che Python ESEGUE, *A RUN TIME*:
    def paperino…
    paperino = pippo(pluto)(paperino)

    L’unico, singolo bit di Python che PUO` essere concettualizzato come dichiarazione e` `global’: non “fa” nulla di specifico, bensi` “dice” qualcosa al compilatore (che, *a compile time*, ne e` influenzato). E infatti e` un “wart” (ed e` quasi sempre stile molto migliore quello di evitare le global).

    c. altro buon riferimento su “strong typing vs strong testing” e` di Bruce Eckel (autore dei best-seller “thinking in Java”, “thinking in C++”, ecc) a http://www.mindview.net/WebLog/log-0025

    d. @Phil: la leggibilita` di Python e` imbattibile, infatti e` “pseudocodice eseguibile”; i buoni testi di algoritmi (come il mio preferito, “Algorithms: a creative approach” di Udi Manber, oggi mio collega a Google) usavano pseudocodice per esprimere gli algoritmi anche prima che Python fosse inventato (lo pseudocodice che usava Udi gia` nel 1989, in particolare, e` quasi indistinguibile da Python)

    e. @Enrico: no, quello che dici (“la variabile python e` legata a un tipo specifico”) NON e` giusto: i nomi non hanno tipi, quindi puoi benissimo scrivere “python = quellochevuoi” del tutto indipendentemente dal fatto che il nome python fosse o meno legato in precedenza ad un oggetto di altro tipo. (Incidentalmente, il modo + semplice di costruire un’istanza di una classe, equivalente al “new LaClasse()” di Java, e` semplicemente chiamare “LaClasse()” senza quell’inutile ‘new’ davanti; praticamente ogni classe e` intrinsecamente una factory-function).

    I *buoni* linguaggi a tipizzazione statica (NON Java o C++, ma boo, haskell, ML, …) fanno “type inferencing” per evitare al programmatore la stupidita` di dover usare tanta ridondanza per “fare da babysitter al compilatore” (alcuni come C# 3 e Scala ci provano ma hanno forse troppe limitazioni in merito); vedi ad esempio http://boo.codehaus.org/Type+Inference — boo e` interessante perche` assomiglia molto a Python, ma con static typing e inferencing — peccato che sia implementato solo per .NET; ha anche un tipo ‘duck’ da usare esplicitamente nei rari casi in cui si vuole bloccare l’inferencing e mantenere invece tipizzazione dinamica. Ma certo i linguaggi dinamici (Python, Ruby, Erlang, Lisp, Scheme, …) sono assai + semplici, e si puo` sempre metterci un type inferencer Just-in-Time, come ad es. psyco per Python (http://psyco.sourceforge.net/), se si vogliono recuperare alcuni dei potenziali vantaggi prestazionali del type inferencing SENZA sprecare il tempo del programmatore a “babysit the compiler”;-)

    Alex

  4. vrde permalink

    vantandomi con gli amici commento di Alex Martelli mi sono dimenticato di rispondere :)

    @Alex Martelli: grazie per il prezioso ed esaustivo commento, penso non ci sia altro da aggiungere ;)

  5. gius permalink

    mi permetto di dissotterrare questo vecchio post del quale mi avevi parlato ;-)

    ora aspetto le tue riflessioni sulla pycon3 !!!

    • vrde permalink

      Ciao! Grazie :P
      riordino gli appunti che ho preso durante la conferenza e poi pubblico!

Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

%d blogger cliccano Mi Piace per questo: