Python e me

Nei giorni scorsi ero alle prese con la preparazione di uno dei nostri articoli di ricerca, in cui ad un certo punto abbiamo cercato di comparare tre strumenti software di analisi. Ognuno degli strumenti è in realtà un prodotto di ricerca, e ognuno è scritto con un linguaggio diverso: il nostro programma, RTSCAN, è scritto in C++; IMITATOR, un tool che hanno sviluppato qui in Francia, è scritto in OCaml; e infine MAST è uno strumento sviluppato all’Universidad de Cantabria in Spagna, ed è scritto in Ada. Ognuno produce risultati in maniera completamente diversa, e c’era quindi la necessità di elaborare questi dati in output in maniera uniforme, per poi produrre dei grafici “decenti”.

Avevamo quindi bisogno di un po’ di script per generare dei dati in input ai tre strumenti, lanciarli, collezionare e uniformare gli output. Abbiamo cominciato con un grande classico: un po’ di bash scripting. Però dopo un po’ ci siamo resi conto che non saremmo andati molto lontano. Un po’ perché io sono sempre stato lento con bash: non mi piace molto la sintassi, e quindi trovo difficile memorizzarla. Un po’ perché sarebbero stati necessari dei tool esterni non banali, e quindi alla fine il risultato non sarebbe stato molto portabile.

Per fortuna che c’è Python. Io non ho mai davvero imparato il Python, perché non ne ho mai avuto il tempo. Non ho tempo per mettermi davanti a un libro o a un corso (anche di quelli accellerati) per imparare l’ABC di un linguaggio. E soprattutto, non ho tempo per imparare a usare le varie librerie (e ce n’è davvero tante). Ma per fortuna, Python ha due caratteristiche peculiari:

1) E’ facile cominciare. Cioè, in realtà all’inizio potete considerarlo tranquillamente come se fosse un linguaggio di scripting. Non c’è bisogno di astruse direttive, di dichiarare variabili, di scrivere funzioni, non c’è bisogno neanche di un main. Si parte a scrivere codice come viene viene, ed è molto probabile che funzioni subito come avevamo pensato.

2) In linea c’è tutto. Qualunque cosa tu voglia fare, basta googlare, e finisci o sul manuale di Python in linea, o su stackoverflow, dove hanno sempre la ricetta pronta per te.

Naturalmente, bisogna conoscere un minimo le basi della programmazione. Ma dal pensiero alla realizzazione passa davvero molto poco.

E passiamo a scrivere brevemente il nostro lavoro. Come prima cosa, avevamo bisogno di specificare il sistema da far analizzare ai tre strumenti. Per semplicità ed immediatezza, abbiamo scelto il formato JSON, che adesso va per la maggiore.  E naturalmente Python ha una libreria per leggere e interpretare un file JSON con sole due funzioni, e il risultato è una lista di dizionari.

Poi, abbiamo scritto 3 funzioni per visitare la lista di dizionari e produrre tre file di input per i tre strumenti. Poi abbiamo scritto 3 funzioni per lanciare i 3 strumenti. Infine, abbiamo fatto post-processing sugli output. Tutto questo in una mezza giornata. Un altro paio di giornate è passato a mettere a posto le cose (perché c’è sempre qualcosa da sistemare, naturalmente) e a cercare di far produrre dei grafici decenti a gnuplot (e ci siamo riusciti solo parzialmente).

Ma la cosa bella di Python è che non si limita ad essere un semplice linguaggio di scripting, ma ha tutte le potenzialità di un vero linguaggio di programmazione. Costrutti evoluti, Object Orientation, ma anche un po di functional programming. C’è la tipizzazione a run-time (il cosidetto duck-typing), il garbage collector. Utilizzando uno stile di programmazione pulito, Python consente di scrivere programmi molto eleganti e “belli”, senza grosso sforzo.

E’ insomma un linguaggio scalabile: si può andare facilmente dal piccolo script di poche linee, al programma mediamente complesso senza grossi problemi. Inoltre ti consente di fare fast prototyping: se hai un’idea, la butti giù e la testi in pochi minuti e con poco sforzo, e la puoi tenere lì in caldo pronto a riprenderla e ad evolverla in qualcosa di più complesso più avanti.

Ha dei difetti? Non sono sicurissimo di quanto possa scalare Python. Se il progetto diventa veramente grande, e con tanti programmatori, non sono sicuro che Python basti. Per esempio, il codice Python può diventare orribile se scritto male e senza giudizio; il fatto che si usi duck-typing richiede una certa dose di coordinazione sulle interfacce quando si lavora in tanti; e quando un progetto è grande, non è detto che tutti i programmatori siano allo stesso livello.

Insomma, mi sa che mi tocca studiarmelo meglio. Adesso che l’ho provato in un caso quasi reale, penso che comincerò ad utilizzarlo sempre più spesso!

Cloud computing

A Natale mi sono regalato uno smartphone Android, per la prima volta nella vita, e quindi ho passato un po’ di tempo a spippolare, come sempre succede in questi casi. Ho installato tutti i miei social network, ora sono un individuo sempre connesso (o quasi), e nei prossimi mesi esplorerò per bene le funzionalità dell’aggeggio (da non utente, sono sempre stato scettico sulla reale utilità di questi aggeggi, ma forse potrei cambiare idea in un futuro non troppo remoto).

Ad un certo punto ho provato a scrivere delle note tramite il tastierino, ma non è che funzioni benissimo: lo schermo è piccolo, i miei polpastrelli sono grandi, e azzeccare il tasto giusto non è facilissimo. Per fortuna che c’è il riconoscitore vocale! Clicchi sull’icona del microfono, e cominci a parlare normalmente, e il testo appare magicamente sullo schermo dopo pochi istanti e con pochissimi errori. “Uau”, ho pensato, “funziona benissimo!”

A dire la verità funziona anche troppo bene. Mmm, facciamo una prova. Disabilito il wireless e la connessione dati, e riprovo. Ma l’icona del microfono adesso non c’è più: non è possibile fare riconoscimento vocale quando sono off-line. Ecco la spiegazione: l’applicazione di riconoscimento vocale è un classico esempio di cloud computing.

Che vuol dire? Vuol dire in generale che la potenza di calcolo di un computer o di un dispositivo mobile viene aumentate usando ricorse remote di rete: la famosa nuvola. Lo smartphone viene utilizzato come un terminale evoluto, il cui scopo è semplicemente di prendere l’input dell’utente, e di mostrare l’output. Il calcolo vero e proprio viene “off-loaded” a un computer remoto. Possibilmente il calcolo viene parallelizzato in modo da eseguirlo più velocemete su tanti calcolatori.

Ora, i nostalgici che frequentano qusto blog ricorderanno come funzionavano i maniframe di una volta: un solo calcolatore centrale (il mainframe) e tanti terminali stupidi tutti collegati (in seriale!) al calcolatore centrale. Qui la faccenda è molto più complicata: problemi di sicurezza, distribuzione del carico, parallelizzazione, ottimizzazione delle risorse, risposta in tempo reale… c’è tanta ricerca, ricerca in cui naturalmente le grandi aziende come Google sono molto avanti, mentre  l’università arranca molto dietro.

Nel nostro caso, l’app prende la nostra voce (e chi sa che altro) e la spedisce ai server google, che rispediscono indietro il testo. Naturalmente, viene subito fuori il probema della privay: che se ne fa Google dei nostri dati? Beh, li usa per i suoi scopi, ovviamente. O pensate che a Mountain View siano tutti dei benefattori dell’umanità? Per ora, Google dice che i nostri dati vengono trattati in maniera anonima. Ma se nel futuro dovessero trovarsi eonomicamente in difficoltà, io non mi stupirei più di tanto se ricevessi sulle pagine web pubblicità personalizzata a seconda di quello che ho dettato a Google! Che ne so, se prendo una nota “prenotare l’aereo per Pisa”, i banner pubblicitari delle compagnie interessate a venermi un biglietto Parigi-Pisa cominceranno ad apparire sulle pagine web che visiterò da quel momento in poi.

E poi, ci potrebbe essere di peggio, naturalmente: se siete persone importanti, e con nemici importanti, evitate di usare i riconoscitori vocali moderni, mi raccomando!

WIMP o cmd?

OK, avevo detto che niente più post nostalgici di come erano i ‘puters una volta ma poi domenica 9 James Hague di programming in the
twenty-first century se ne esce con questo post: The UNIX Philosophy and a Fear of Pixels  e allora devo scrivere qualcosa. Poi smetto, davvero.

Quando io ho cominciato le schede perforate non si usavano più. Quasi: per esempio al Poli per gli studenti ma sul lavoro ormai c’erano i TTY (allora i terminali, monitor e tastiera attaccati, collegati tramite RS232 all’elaboratore si chiamavano così). Tutto testuale e ogni computer aveva un proprio sistema operativo. Dovevi imparare una dozzina di comandi, segnateli, ti dicevano. Allora: logarti, lanciare i programmi che usavi, stampare i risultati, slogarti. Ecco il problema era che i programmi richiedevano dei dati, sì avresti potuto inserirli interattivamente ma se erano tanti e poi tu sei lento e il tempo macchina è prezioso.

Uh! allora dovevi imparare a usare un editor. Avete presente ed? Sì c’è ancora, quasi mi ricordo tutti i comandi. Non è che fosse così davvero, ogni macchina aveva il suo, per esempio sul Prime i comandi erano simili ma non gli stessi. Poi sarebbe venuto vi (sta per visual, era diverso da quello di adesso, poi Emacs, grazie a RMS). Con l’editor ti preparavi il tuo (o i tuoi) file di dati, seguendo le specifiche tramandate sul retro di tabulati (i fogli della stampante), li controllavi e finalmente li davi in pasto al computer per l’elaborazione, il batch.

Poi a un certo punto le cose sono cambiate: è arrivato UNIX (allora si scriveva così). E Unix era diverso. I comandi erano molti di più ma soprattutto pieni di opzioni. C’erano i manuali (come il man che c’è ancora adesso, sia on- che off-line) ma risultavano incomprensibili se eri nuovo. Da lì l’idea che Unix era difficile. Errore! Dovevi solo impararlo e poi era una meraviglia.

Delle cose che prima avresti fatto con un programmino in Fortran (c’era solo quello) adesso potevi farlo con un comando. Magari lungo, complesso, pieno di segni misteriosi, i caratteri speciali. Sì perché c’era una meraviglia mai vista prima: la pipe che ti consentiva di concatenare i vari comandi.

Le interfacce grafiche a finestre (WIMP) sarebbero venute molto dopo.

Il che non vuol dire che prima ce ne fossero, testuali. Per esempio su Prime c’erano i CPL (Command Process Language), un linguaggio di script, su Apollo c’era Dialog (anzi due versioni, prima che Apollo adottasse Unix e poi venisse comprato da HP e fagocitato). Con Unix si usava Tcl/tk (ma dopo, 1988 dice Wikipedia).
Intanto erano comparsi i personal computer, in genere con il Basic, si faceva tutto con il Basic. Poi il Mac e Windows. Ma prima c’era avevo avuto un lungo interludio con Turbo Vision della Borland.

Ecco questo, mica come oggi che si fa tutto con WIMP, “window, icon, menu, pointer“.

Anzi è vecchio, Micro$oft dice che dobbiamo usare Metro, che non si chiama più Metro perché quella è la metropolitana.

E pensa te che quest’anno io ho contribuito a un grosso lavoro tutto (OK, quasi tutto) gestito con comandi. E poi c’è il mio amico Luigi Bit3Lux che continua a racontare come usare gli attrezzi di una volta, senza spaventarsi di quelli più feroci, come AWK, guarda qui.

Prima di Linux

Ogni tanto –un paio di volte all’anno– salta fuori la nuova classifica dei ‘puter più potenti, la lista Top 500.
Oggi ci ho ravanato un pochino e ho scoperto cose –a me nessuno dice mai niente, capace che le sanno già tutti, in tal caso non leggete questo post– che voglio condividere.

Questa torta è sconvolgente. “Sicuri che non siano invertite le scritte Linux e Windows?” chiederebbero parecchi miei conoscenti, anche tecnici, p.es. quelli di Telecom. Anzi questi ultimi, se onesti, arriverebbero a dire “Linux, mai sentito, sei sicuro? Sicuro-sicuro?”. E dov’è il Mac?

OK, torniamo a noi. Mica mi sono fermato a quella pagina, ecco qua:
Ah! Ma allora non è sempre stato così, c’è un evoluzione (atz! anche qui si parla di evilussione, tutto per far inkatsare i creotardi!).

Uh! Ma allora, prima del ’99 cosa c’era? Il MacOS? O l’M$DOS? O cosa?

Ah! Ecco: c’era Unix, il papà di Linux.
O non è il papà e si tratta di un caso di convergenza evolutiva (creotardi: tiè!)?
No, perché Linux l’ha creato Linus. E io mi ricordo che una volta Unix si usava solo quando serviva davvero perché era costoso. E difficile da usare, si dice, benché sia semplice:

UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity. (Dennis Ritchie)

Poi, già che ci sono: quando io ero piccolo i programmatori erano divisi in due categorie: scientifici e gestionali. Ora, a parte i dubbi se gli ingegneri siano scienziati e la certezza che i gestionali avevano capito tutto (lì ci $ono i $oldi!) tra i nostri c’erano parecchi che vedevano solo e stravedevano per VAX/VMS. Questo post me lo segno, se rivedo qualcuno glielo dico; PS sto pensando a te!
Ma avevano ragione anche loro, googlando salta fuori nelle prime posizioni INTRODUCTION TO VAX/VMS, del ’95, ma tanto non è cambiato.

---

Le fonti per questo post sono:

94 Percent of the World’s Top 500 Supercomputers Run Linux

Operating system Family / Linux

Development over Time (dovete scegliere Operating system Family)

Digitali & no

Io su Facebook ci passo pochissimo tempo. Più che altro ci metto la pubblicità: annuncio ogni nuovo post dei blog e qualcuno ci casca e clicka, quelli che sanno di trovarlo e ci rimarrebbero male se non glie lo dicessi.

I linuxiani credo siano pochissimi, io ne ho solo un paio tra i ‘mici. Altre categorie di persone invece lo usano, parecchio, anche per cose non banali. Insomma non ci sono solo bimbiminkia, anche se questi sono parecchi; e quelli che mi chiedono la micizia non dico mai di no, tanto lo fanno per averne molti e non interagiscono.

Poi capitano cose come quella che vado a illustrarvi; un disegno vale mille parole e io ve ne metto due

Poi la conversazione va avanti, mappe, browser e quant’altro. Ma credo sia sufficiente a illustrare un paio (abbondante) di punti:

• l’utente normale non deve essere un sistemista;
• se sei (come nel caso illustrato) in un posto dove c’è un sistemista devi poter avere il suo supporto non solo telefonico;
• quelli saputi non dovrebbero fare battutine da saputi;
• i fanboy di tutti i generi non dovrebbero approfittare di ogni occasione per evangelizzare il disgraziato di turno;
• Apple non è più quella di quando c’era lui; oppure
• non è che Apple sia perfettissimissima, anzi…

Poi, già che ci sono, ci sarebbe ancora un altro argomento da trattare: non tutti gli utenti hanno le stesse esigenze. Recentemente un amico mi raccontava (viaggio lungo in macchina, se parla non si addormenta) che sta pensando seriamente di sostituire i portatili a parecchi suoi sottoposti con tablet per tutti quelli che usano il PC come macchina per scrivere (quelle di una volta), visualizzare video e presentazioni PP, magari in un browser.
Ah sì il Web e il (la?) cloud. E il wi-fi che manca. E le mappe: nessuno ormai riesce a ritrovare la strada di casa senza collegamento e app ad hoc.

Ben oltre Perl: J

Questa è solo una storiella, il resoconto di un incontro tra vecchi smanettoni (ormai appartengo alla classe dei nonni), di quelle che si fanno a fine anno o nelle ferie. Questa è della settimana scorsa.

+/1e6<,!/~>:i.100

Questo è un programma; no, non un’istruzione, un programma intero.
Sintetico vero? Cosa fa ve lo dico in fondo (tipo “a pag.46″ della Settimana Enigmistica) ma per intanto la storiella.
Io Unix l’ho scoperto attorno al 1984-1985 (circa, nèh!). E per il primo lavoro serio il capo era ZAP (adesso non usa più questo nick), un matemattoico di qualche anno più anziano di me, sia per età che esperienza.

Naturalmente si faceva tutto in Fortran, come al solito. Però c’era da fare un post-processore semplice e io l’ho fatto usando sed, awk, grep e non so cos’altro. Anche perché dovevo impratichirmi e poi ero rimasto entusiasta della pipe (questo mi fa pensare che forse era anche prima dell’84, la pipe, rudimentale, c’era anche nel DOS).
ZAP, senza nemmeno starmi a sentire mi impose di tradurre tutto in Fortran. Delusione, profonda, ma lui era il capo.

Poco dopo se ne andò a lavorare da un’altra parte e mi chiese se volevo seguirlo; risposi che avevo un sacco di cose da finire e persi l’occasione

OK, adesso si occupa di problemi statistici (in realtà non ho capito cosa fa) e usa linguaggi come A+ e J. J in particolare è l’ultimo discendente di APL, roba astrusa quanto basta per piacere ai matematici.

Avete presente il Perl, quello che

Perl frightens me. It looks like an explosion at an ASCII factory

(qui ma se googlate perl factory explosion rimarrete stupiti).

Ecco Perl in confronto a J è normale, anzi prolisso. Davvero. Io ZAP l’ho perdonato ma sappia che è (anche) colpa sua se adesso uso Python.

Eccoci giunti a p.46, la soluzione la trovate qui.

E se qualcuno vuole saperne di più su J c’è sempre Wiki, come faremmo senza Wikipedia?

Errori

There’s a saying that the difference between theory and practice
is that in theory, there is no difference between theory and practice;
but in practice, there is.

Provo a riallacciarmi ai post precedenti raccontando un piccolo fatto capitato recentemente. Non so se i tre protagonisti di questa storiella saranno d’ora in poi classificati nella categoria dei programmatori amatoriali (io sono uno dei tre) ma questo è più o meno quello che è successo.

Il codice era in Fortran (l’ho imposto io, mi era stato imposto di imporlo) ma non è necessario conoscere il linguaggio.

MarkCC si è lamentato su Twitter di questa condizione

ma di solito in questi casi basta qualche correzione e il numero di errori segnalati cala rapidamente. Certo che 996 se sono il frutto di una persona sola fa pensare. A meno che abbia scritto tutto senza provare a compilare mai. Poi non so Scala che bestia sia (e nemmeno voglio saperlo).

Il nostro caso era diverso: il compilatore non dava errore, produceva regolarmente l’eseguibile che funzionava. Quasi. Dopo qualche giro è saltato fuori un risultato inaspettato, in una zona piuttosto piccola. Ripetendo il run questo risultato cambiava, sempre nella stessa zona ma l’ampiezza poteva variare. Naturalmente c’erano di mezzo matrici (array bidimensionali, credo si chiamino abitualmente così) decisamente grandi e il controllo facendo scrivere i valori erano di difficile valutazione. I test erano stati fatti su un caso di 6 x 6 (circa, non ricordo, cioè non vi dirò mai cose per cui posso essere incriminato) e era risultato tutto OK.

In questi casi io conosco un modo solo: esaminare il codice riga per riga. Non è ne veloce ne divertente.
Si era convenuto, contro la prassi corrente, di dichiarare tutte le variabili (mediante implicit none) e la prima verifica è stata di controllare i tipi: non è che c’è un integer al posto di un real? No, tutto OK. Però anche lì c’ modo e modo di farlo: posso scrivere

integer :: i1, i2, i3
real(8) :: r1, r2, r3

magari con nomi significativi ma, almeno per le variabili globali si dovrebbe scrivere

integer :: i1 ! descrizione della variabile
integer :: i2 ! descrizione della variabile
integer :: i3 ! descrizione della variabile

dividendole per gruppi. Poi si potrebbero creare strutture ma nel nostro caso non eravamo arrivati a tanto.

Uh! variabili globali, non è che… Sì sono tanto comode ma se si pasticcia nella definizione ne può scappare una (con il nome TL per noi) che resta lì addormentata. Se tenti di ridefinirla in una funzione ricevi un errore di ridifinizione. Ecco dev’essere successo quello, cancelli la seconda definizione pensando di averla fatta 2 volte nella stessa funzione. E userai la variabile globale, senza accorgertene.

OK, trovato l’errore basta rimuovere la variabile globale e ridefinirla localmente.
Tutto a posto? No! A differenza di qualche linguaggio la definizione di una variabile non setta la stessa a un valore predefinito, zero nel caso di interi. Mica siamo in Basic qui!
Ci sarebbero ancora altre cose, tipo se sia meglio un modulo (quello che permette di definire le variabili globali, e no solo) unico, grosso o tanti piccoli? E non dimenticare la direttiva private.

Forse è meglio una situazione come quella di Mark, certo che 996…

Poi va a finire che se la prendono con me! e mi retrocedono in serie B, come il Toro

Programmatori amatoriali

Ultimamente è saltata fuori la moda che tutti vogliono (o addirittura devono!) saper programmare. Il nostro esimio collaboratore Pier Giuliano ha segnalato questo pezzo su G+:

Rise of Coding: Why We Should All Learn a Little Code

dove si sostiene (non senza un certo poco celato conflitto di interessi) che tutti dovremmo saper programmare. Tutti, ma proprio tutti? Eh, certo se tutti sapessero cosa vuol dire programmare, forse schiferebbero meno e apprezzerebero un po’ di più il lavoro dei programmatori professionisti; per lo meno sarebbero in grado di apprezzare la difficoltà e la complesità di certe realizzazioni. Sembra che addirittura il sindaco di New York abbia deciso di imparare. Qui si dice anche che i CEO dovrebbero imparare un po’ di tecnologia, per il loro bene.

Non tutti sono d’accordo però. Alcuni rimpiangono i vecchi tempi quando per programmare si indossaa il camice bianco: l’epoca dei sacerdoti dei mainframe! Altri più realisticamente, affermano che programmare non è proprio per tutti. Per esempio, su slashdot mi informano di questo rant (ehm post):

Making non-coders code

E in effetti non ha tutti i torti: se uno non vuole imparare, se non si sente portato, perché deve imparare per forza? E addirittura produrre codice da mettere sui prodotti! Non invidio i programmatori profesionisti in quell’azienda.

Un flame simile c’era stato qualche tempo fa. Coding horror si era scagliato contro la moda. E qui avevano risposto molto ironicamente (direi sfottendo Atwood alla grande). Leggete perché ne vale la pena!

Boh, insomma, a me sembra si esaeri da una parte e dall’altra. Obbligare qualcuno a programmare, direi di no. Ma se tutti avessero un minimo di basi non sarebbe male. Non dico haskell, ma se tutti imparassero per lo meno a impostare uno spreadsheet per calcolarsi il budget familiare o le rate del mutuo, ecco io sarei pù contento. E voi che ne pensate?

Usare propriamente gli attrezzi giusti

Una delle cose che dice Guido  che più mi piacciono è:

Don’t write Java (or C++, or Javascript, …) in Python.

E ci aggiungerei: leggete il manuale, tutto, più volte.
Tipo ieri che mi è capitato di dover intervenire in pronto soccorso codice rosso per uno scriptino-ino-ino in Gnuplot.

La versione che era stata montata in base ai miei esempi era –come si dice– pasticciosa, ecco. Si poteva fare molto più direttamente, più brevemente, dopo aver letto il manuale e navigato un po’ su Gnuplotting.

Tutto questo succede perché ci si deve comunque ambientare, non è possibile saltare la fase di apprendimento, non si può solo copiare l’esempio che fa quasi quello che si vuole e aggiustarlo a martellate.
E ogni aggeggio dev’essere usato nel modo appropriato, non come si usano gli attrezzi simili, proprio come dice Guido.

D’altronde, sempre per il caso di ieri, si è visto come usare una versione decente recente del Fortran porta a impostare diversamente il codice (mi riferisco all’uso dei moduli al posto dei common).
E serve anche una dose sufficiente di elasticità mentale per passare da un linguaggio a un altro.

A proposito: imparare un nuovo linguaggio può essere più o meno facile, dipende da quello che già si sa e dalle caratteristiche del linguaggio. Io per esempio ho difficoltà con quelli funzionali (non ne conosco neanche un po’ nessuno). E non si può neanche barare, come qui:

If you have ever worked with imperative languages, statements such as i++ may be normal to you; in functional programming they are not allowed. In fact, changing the value of any variable is strictly forbidden! This may sound weird at first, but if you remember your math classes, it’s in fact how you’ve learned it:

y = 2
x = y + 3
x = 2 + 3
x = 5

Had I added the following:
x = 5 + 1
x = x
∴ 5 = 6

No, dai! questa è propaganda! Se vuoi altri linguaggi al posto di i++ hanno:
inc(i) -> Delphi
(inc i) -> newlisp
(1+ i) -> CL
+1 no! questo è il like di Google plus

E sai una cosa? in tutti i casi l’incremento può essere anche maggiore di 1; certo, devi usare le variabili

Penna e calamaio

Oggi ho letto questa perla di saggezza:

Best programming advice you’ll ever get: before coding, sit back and think. Then think again.

(su Twitter da @miljar, ri-postato da Claudio Cicali su FF).
E non posso che essere d’accordo. Dirò di più: io sarei per tornare alla programmazione carta e penna.

Scrivere programmi col pennino?

Qualche anno fa, al corso di Sistemi Operativi del prof. Ancilotti a cui facevo da assistente, l’esame scritto consisteva nello scrivere un programmino con carta e penna. Capisco che a prima vista può sembrare folle: programmare con carta e penna? Beh, si, secondo me è più istruttivo, più didatticamente adeguato. Nel corso di Sistemi in Tempo Reale, ancora oggi faccio fare uno scritto in cui il primo esercizio consiste nello schematizzare un programma con carta e penna. In entrambi i corsi lasciavamo agli studenti la possibilità di usare tutto il materiale che volevano, (appunti, libri, slides, ecc.) tranne il PC.

A mia discolpa, dirò che non ho mai preteso una sintassi perfetta. Se uno scorda un punto e virgola, oppure scrive print invece di printf, non è un problema, purché il programma sia logicamente corretto. Se volete è un vantaggio per lo studente: non c’è bisogno di essere super precisi, purché l’algoritmo che ci sta sotto sia corretto.

Quando devo scrivere un algoritmo complicato, io di solito faccio con carta e penna così:

• Prendo un foglio A4 pulito, o ancora meglio un quadernone a quadretti.
• Comincio a fare uno sketch dell’algoritmo (di solito una singola funzione) con una matita. Da una parte a destra del foglio segno le variaili locali che mi servono di volta in volta.
• Qualche volta mi permetto di abbreviare: for all x in v invece del classico ciclo for, while senza condizione (la metto dopo), ecc.
• La regola pù importante è che la funzione deve stare tutta in un singolo foglio. Se mi accorgo che viene troppo lunga, spezzo in più funzioni, da mettere nei fogli successivi
• Se resta spazio, di solto metto qualche breve esempio di esecuzione, o qualche schemino che spiega graficamente il funzionamento.
• E’ importante fare il primo debug a occhio direttamente sul foglio.
• A volte, lascio lì il foglio per un po’ e vado a fare altro (che ne so, a farmi la barba). Il mio cervello in background continua a pensarci su (io sono fatto così), e spesso trovo dei bug o dei controesempi mentre mi aggiusto le basette.
• Quando ci ho pensato un po’ e sono abbastanza contento, è il momento di andare sul PC. Questa è la parte più meccanica di tutta la faccenda, ma anche quella che da più soddisfazione, specialmente se alla fine funziona!!

Sembra che Djikstra una volta abbia detto:

“Computer science is no more about computers than astronomy is about telescopes.”

e può darsi che si riferisse a questa cosa qui!