[Soci SLIP] Da grande farò il programmatore

[llcfree]

On Wed, 2013-03-20 at 10:45 +0100, Lucio Crusca wrote:
> In data Tuesday 19 March 2013 19:37:30, llcfree ha scritto:

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

Bisogna immaginarsi nei panni dell'imprenditore universale e poi si
comincia a capire. I conti, come li facciamo abitualmente, sono tutti
falsati da un'astrazione: soldi. Ci si accorge che non puo' funzionare
quando crolla un sistema di una certa dimensione. Se si va a vedere, si
capisce che proprio non potrebbe funzionare. I soldi vengono stampati da
enti privati (la Fed e' privata, ed e' diventata tale con un emendamento
fatto passare al congresso americano il 23 dicembre 1913, anche allora
si usava fare le cose alla vigilia di Natale). I soldi non corrispondono
a nulla di reale. La quantita' in circolazione viene decisa al di sopra
delle nostre teste e nelle crisi genera inflazione fino al crollo
dell'intero sistema. 

Per fare i conti bene, occorre farli sulla realta', non sul nulla, per
quanto abituati siamo ad occuparci di questo nulla (poi, pero', i conti
non ci tornano).

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

Pero' se si capisce quello, si capisce dove stia lo spreco. Con un
esempio pratico.

Te ne faccio un altro: i sacchetti di plastica. Invece di insegnare alle
persone che gliene basta uno per tutta la vita e poi riciclare quell'uno
a testa quando la persona muore, si decide che non vanno piu' bene i
sacchetti di plastica e si costringe tutti a comprare invece i sacchetti
"ecologici" (molto piu' cari e quasi uso e getta).

Bel risparmio... Forse c'era un altro modo?

L'importante non e' usare o meno un bit su una macchina a 64 bit,
l'importante e' continuare a sapere che basta un bit per una scelta
binaria: 0/1, on/off, che ce ne vogliono due per quattro scelte
possibili, che ce ne vogliono tre per otto scelte possibili, che ce ne
vogliono n per 2^n scelte possibili). E' importante perche' e' un
concetto generale, che si applica a tutto, insieme al concetto che i bit
assumono il significato che gli diamo (codifica). E' importantissimo per
capire come comandiamo la ferraglia: solo grazie al fatto che ai valori
0 e 1 corrisponde un qualcosa di fisico, in questo caso due valori di
tensione. Diventa percio' chiaro perche' si usa il codice binario: e'
"difficile" (non certo impossibile) distinguere piu' di due valori di
tensione, etc. Si capisce che macchina a 8 bit significa che
l'operazione minima di trasferimento da memoria a cpu e viceversa porta
8 bit per volta. Si capisce la differenza tra RAM e registri, tra RAM e
dischi etc etc etc.

Con questo, ti ho "regalato" la prima lezione che propinavo io :)

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

Come si fa a far stare un programma e i suoi dati su arduino (per
esempio) senza sapere come osare la memoria in modo efficiente (cioe',
senza sapere?)

La tendenza e' quella di spostare i limiti, in nome di chissa' quale
efficenza, senza rendersi conto che con i limiti si butta via quello che
serve piu' di tutto, sapere.

Ora, bisogna esser ciechi (accecati) per non rendersi conto delle
conseguenze di questo atteggiamento psicologico di massa.


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

Due ben scelti servono a far capire quando un linguaggio e' adatto a
cosa. Ci vorrebbero almeno due distribuzioni, ad esempio, perche' la
gente non si ostinasse a far stupide battaglie per difendere la
"propria". Senza sapere che quella stupida battaglia e' solo la
pubblicita' indotta e gratuita e malfatta.

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

Anche se ci si mette a capire si va molto piu' adagio di quel che il
vortice richiede ai suoi granellini di sabbia che trascina. Bisogna
organizzarsi per poterselo permettere. E' una scelta cosciente. Uno lo
fa, come sempre, se si rende conto dell'importanza che ha e se lo puo'
fare. 

E poi chi va piano va sano e va lontano  e da sempre la fretta fa
nascere i gattini ciechi :)

Loredana