Archive for the ‘Programmazione’ Category

PEP 20: The Zen of Python

giovedì, febbraio 18th, 2010

Parliamo di programmazione. Quella sui computer intendo.

Per i non addetti ai lavori è una occupazione fredda, scientifica che non lascia spazio all’impronta umana e che porta il marchio di una lavoro fatto in serie, anonimo.

Niente di più falso.

Da come un programmatore scrive il codice si possono capire molte cose, un po’ come in grafologia:
se è conformista, se tende ad ammassare il codice o  se preferisce aggiungere degli spazi; se preferisce scrivere con il CamelCase o più visivamente dividere le parole nelle variabili usando_il_trattino_basso; se esplicita il funzionamento del codice facendo sì che ogni riga effettui (o chiami ;) ) un’unica funzione o magari se è produce codice sincopato… insomma è possibile capire chi abbia scritto del codice (purché sufficientemente lungo) se se ne conosce lo stile.

Anche la linearità o meno del pensiero e il modo di scomporre i problemi in blocchi più semplici e più facilmente affrontabili fa parte della forma mentis del programmatore, tant’è che esiste una letteratura sugli argomenti “filosofia e programmazione” o “la programmazione e la vita di ogni giorno”. E perché no anche su la programmazione intesa come arte.

Un lungo programma ben strutturato offre la possibilità di inserire e far sfoggio di virtuosismi tecnici e stilistici, mostra come il programmatore ha preparato i dati, li ha trasformati per ottenere ciò che desiderava e con quale abilità e strumenti, lasciando dei segni caratteristici assimilabili ai tratti caratteristici di un disegnatore o di un artigiano.

Certo per cogliere questi aspetti più tecnici si deve avere una preparazione specifica più o meno profonda a seconda del SW in corso, ma  direi che lo stesso è  valido per alcuni “capolavori” di arte astratta o contemporanea :roll:

Per molti programmatori di linguaggi moderni e capaci di accettare e gestire (per dirla in termini semplici) tutte le sfumature tra lo 0 e l’1, l’approccio ai problemi della vita quotidiana e quelli della programmazione si fondono.

Ti lascio con dei pensieri tratti dal linguaggio di programmazione python, ottenibili tramite un Easter Egg dell’interprete dei comandi (provate a scrivere import this):

The Zen of Python

  • Beautiful is better than ugly.
  • Explicit is better than implicit.
  • Simple is better than complex.
  • Complex is better than complicated.
  • Flat is better than nested.
  • Sparse is better than dense.
  • Readability counts.
  • Special cases aren’t special enough to break the rules.
  • Although practicality beats purity.
  • Errors should never pass silently.
  • Unless explicitly silenced.
  • In the face of ambiguity, refuse the temptation to guess.
  • There should be one– and preferably only one –obvious way to do it.
  • Although that way may not be obvious at first unless you’re Dutch.
  • Now is better than never. Although never is often better than *right* now.
  • If the implementation is hard to explain, it’s a bad idea.
  • If the implementation is easy to explain, it may be a good idea.
  • Namespaces are one honking great idea — let’s do more of those!

Trikado ovvero “Sferruzzamento”

lunedì, febbraio 15th, 2010

Incurisito un po’ da Mariateresa un po’ dal relativo articolo su wikipedia, ieri pomeriggio ho voluto provare a lavorare a maglia (triki in esperanto significa lavorare a maglia).

Devo dire che l’attrattiva maggiore è stata quella di capire la struttura degli intrecci e come i successivi intrecci del filo  in quantità massicce creano degli effetti visivi.

Da un punto di vista del coinvolgimento però, non fa proprio per me:

  • la parte di progettazione e scelta dei punti è interessante e creativa MA
  • è un lavoro estremamente ripetitivo, e programmabile  a priori, particolarmente adatto ad una macchina che riceve le istruzioni, più che a una persona;
  • i ferri che ho usato, lunghi appena 35 cm non arrivavano fino ai miei fianchi e quindi non potevo tenerli fermi, dovendo quindi fare con le dita oltre che il lavoro di intreccio anche quello di sostegno;
  • in questa fase iniziale non so come fare l’undo (sempre se è possibile) di un errore (e realizzare la successiva patch) senza dover disfare tutto il lavoro a valle del punto critico (alla fine una maglia è una continua ritorsione di un singolo filo).

Da un certo punto di vista ricorda un po’ la programmazione:

  • c’è una fase di progettazione della scelta della lana, colore, dimensione del ferro, texture voluta, rendering di preview dell’aspetto finale;
  • la creazione di un progetto di esempio per vedere come renderà il filo e quali problemi e proporzioni offrirà;
  • un po’ di trace e dump delle maglie fatte per vedere se ci sono errori e la relativa correzione;
  • stanca la vista come quando si sta a lungo davanti al monitor (a meno che non si abbia un buon monitor o un filo con colori che variano spesso);
  • un controllo a grandi linee di quel che si è fatto per vedere come è;
  • quando si inzia ad intravedere qualcosa di concreto dà soddisfazione;
  • arrivati a buon punto… ci si stufa :lol: .

Ma la differenza più grossa e fondamentale è la mancanza di librerie o freameworks :-D dato che ogni volta si deve inziare da zero e fare sempre gli stessi due (tipi di) movimento… (e d’altronde anche in esperanto la radice -ad- in trik-ad-o indica azione continuata e duratura!)

Vedremo se ai prossimi tentativi l’andazzo cambierà… ti farò sapere.

PS: a Pisa c’è un gruppo di sferruzzamento: knittable. Come puoi vedere cliccando sul precedente link, si riuniscono ogni giovedì dalle 18:30 nel Royal Hotel Victoria per lavorare a maglia, passare la serata insieme e gustare un aperitivo.