[Soci SLIP] Da grande farò il programmatore

[Lucio Crusca]

In data Tuesday 19 March 2013 19:37:30, llcfree ha scritto:
> Senza sapere cosa si ottimizza, infatti, non ha significato. Potrebbe
> non essere il tempo del programmatore la variabile da ottimizzare.
> 
> Per chi si occupa di sprechi, mi sembra ovvio che sia importante capire
> dove nasca lo spreco (prima di e per decidere se ridurlo o no). Per
> questo, occorre fare i conti giusti.

Sì, sono d'accordo. Magari le prestazioni del software in oggetto sono 
veramente tanto pietose rispetto alla mole di dati trattata da richiedere 
interventi. Il sospetto però in questo caso è che le ottimizzazioni non 
basteranno, ma si renderà necessaria una riscrittura degli algoritmi (o nel 
caso peggiore del software intero, se originariamente era stato proprio 
scritto male).

> Per chi fa l'imprenditore, mi sembra ovvio che il successo dipenda
> soprattutto dal buon progetto e il buon progetto e' quello che non
> spreca nulla, per definizione 

Non è detto, ovvero non è sempre quella la definizione di "buon progetto". 
Seguendo la tua regola zero, che riassumo con "tutto è relativo", cosa sia 
buono e cosa no dipende dagli obiettivi che ci poniamo. Io da imprenditore 
direi che un buon progetto è quello che soddisfa il cliente. Se poi spreca 
qualcosa che ad oggi costa quasi zero, pazienza. 

Faccio un esempio pratico: se scrivo un software che usa delle variabili 
intere per rappresentare dei valori booleani (vero o falso), sto sprecando 
tipicamente 31 bit su 32 per ogni valore booleano che memorizzo. Se il compito 
del software è memorizzare e gestire sequenze lunghissime (svariati miliardi) 
di valori booleani, forse varrebbe la pena ottimizzare il codice, utilizzando 
un solo bit per ogni valore e quindi memorizzando ben 32 valori in una sola 
variabile intera. Risparmierei circa il 95% della memoria. Dico forse però, 
perché poi dipende dagli algoritmi che dovrò applicare su quelle sequenze: se 
gli algoritmi diventano complicati per il fatto che per accedere ad uno dei 
booleani non posso più usare funzioni già predisposte in varie librerie, 
probabilmente non conviene ottimizzare nonostante il risparmio di memoria. 
Se invece il mio software usa una al più manciata di booleani che servono a 
memorizzare le preferenze dell'utente e qualche altra variabile booleana 
sparsa qua e là per il codice, in questo caso non c'è proprio nulla che 
giustifichi l'ottimizzazione: la soluzione è usare un intero per ogni booleano, 
anche se si sprecano 31 bit su 32 (fossero anche 63 su 64 il discorso non 
cambia). Il tutto IMHO.


> Ergo, e questa invece e' la domada:
> 
> Come pensi si possano "scegliere" i pezzi da comporre (che e' quello che
> il tuo approccio giustamente suggerisce) senza sapere cosa facciano,
> come comporli e quali siano i costi reali (tutti, non solo il costo del
> programmatore, ma anche il costo dell'oggetto che ne risulta, rispetto a
> quello che l'oggetto puo' fare)?
> 
> Voglio dire, come si fa a far rendere tutto il possibile, senza sapere
> esattamente cosa sia possibile e cosa no, che e' poi il criterio con cui
> lavorare in modo sano?

Non sono sicuro di capire la domanda, provo a rispondere, ma se rispondo fuori 
tema prova a farmi un esempio pratico, anche se inventato.

I pezzi da comporre (le librerie) non si possono scegliere se non sai che cosa 
fanno. Prima ancora devi sapere cosa vuoi fare tu con il tuo software. Quando 
lo sai ed hai una visione delle funzionalità che ti servono, cominci a cercare 
(su Google), per ogni funzionalità, se esiste una libreria che la implementa. 
Se la trovi, sai che cosa fa (visto che l'hai cercata per un motivo). Se non 
la trovi... beh o cerchi meglio, o è una funzionalità specifica del tuo 
software e quindi te la devi scrivere. Ho risposto?

> 
> > 6. qualsiasi linguaggio va bene.
> 
> Ma ogni linguaggio ti porta piu' o meno vicino allo spazio di problemi
> che puo' risolvere in modo efficiente. Imparare un nuovo linguaggio di
> programmazione e' davvero banale, infinitamente piu' semplice
> dell'imparare un lingaggio naturale. Il vero probelma e' imparare a
> programmare, con un linguaggio qualsiasi (qualsiasi ??? alcuni sono
> infinitamente peggio di altri, per questo scopo).

Diciamo che c'è una distinzione fra il linguaggio e le librerie disponibili 
per quel linguaggio. Imparare un linguaggio, ovvero una sintassi, è 
effettivamente banale. Corrisponde grosso modo ad imparare come si strutturano 
soggetto, verbo e complementi in una nuova lingua che vogliamo imparare ed in 
cui non esistono eccezioni (utopia nel caso delle lingue).

Imparare invece le librerie che sono disponibili per un determinato linguaggio 
è un po' come imparare, oltre al tedesco, anche tutta la letteratura e la 
storia della Germania, la filosofia tedesca, il sistema legislativo, politico ed 
economico, in modo da avere gli strumenti per sostenere un discorso di 
qualsiasi livello con chiunque quando si andrà in Germania in vacanza. 
Ovviamente possiamo imparare solo una parte della lingua e nulla di tutto il 
resto e tanto ci basterà ad arrangiarci in vacanza. Allo stesso modo, nei 
linguaggi di programmazione, basterà imparare una piccola parte delle librerie 
e tanto basterà ad arrangiarsi, ovviamente accettando il fatto che i programmi 
risultanti sembreranno come discorsi di un italiano in germania che ha 
imparato il tedesco con il corso deagostini.

> Senza conoscerne "almeno" due, come si fa? 

Non si fa. Questo è un punto che aggiungo volentieri all'elenco.

12. Sapere un solo linguaggio non basta. Di solito non basta saperne neppure 
solo due, se consideriamo linguaggi anche le sintassi puramente dichiarative 
come HTML, XML, CSS e cose del genere. Non è però necessario essere esperti di 
tutto quanto. Un linguaggio sarà il nostro preferito, quello con li quale 
risolveremo il 90% dei problemi. Per il restante ed irrinunciabile 10%, 
obbligatorio perché il nostro programma necessariamente dialogherà con altri 
programmi e sconfinerà in spazi di problemi in cui il nostro linguaggio 
preferito non calza a pennello, dobbiamo avere almeno le basi di alcuni altri 
linguaggi.

> I problemi da risolvere e gli
> strumenti per farlo spaziano dall'arduino al cray. Come giustamente dici
> anche tu. Ma chi sa solo un linguaggio, a quello si affeziona. L'ho
> visto succedere con il bellissimo, elegantissimo "scheme": frotte di
> programmatori sfornati da scienze dell'informazione che usavano le liste
> invece degli array 

Sì, è vero, io sono uno di quelli (non di quelli affezionati a scheme, ma di 
quelli affezionati al concetto di programmazione funzionale). Al primo 
programma scritto in C che va in stack overflow perché il C è il linguaggio 
sbagliato per scrivere funzioni ricorsive, ci si rende conto che forse esiste 
anche un mondo là fuori, inteso fuori dall'università, e che forse scheme non 
è necessariamente la risposta a tutti i mali.

> In buona sostanza, non pensate di diventare miracolosamente ottimi
> progettisti/programmatori (un programmatore e' un soggetto che progetta
> software) senza l'esperienza necessaria. 

Soprattutto non pensate che bastino i 12 punti elencati... :D

> Potete ritrovarvi ad essere
> ottimi "sprecatori", al piu', e vi funzionera' solo finche' non sarete
> messi alle strette dai limiti imposti dalle risorse disponibili o dalla
> competizione (sacrosanta, quando non violenta) sui mercati.

Se ci si mette ad ottimizzare i bit però si sarà messi alle strette dalla 
competizione molto prima di quanto uno sprecatore sarà messo alle strette 
dalle risorse disponibili (a meno che non si parli di microcontrollori, in 
quel caso può essere molto più importante non sprecare, a seconda di cosa si 
vuol far fare ad arduino o chi per lui, pena il rischio di non riuscire 
proprio a farglielo fare).