Newsgroup: it.comp.programmare
Titolo: int float

 si sviluppa un qualsiasi programma, anche un "hello world". Unica deroga
Per carita`.  L'esperienza di vent'anni potrebbe bastare eccome, ma...:
"Una persona puo` avere dieci anni di esperienza, o un anno di
esperienza ripetuto dieci volte" (Yukiso Yamamoto).  E visto che
siamo in tema di citazioni, continuiamo con alcune sul tema specifico
da parte di alcuni dei piu` grandi programmatori contemporanei:
"Si commettono piu` errori di programmazione nel nome dell'efficienza (senza
necessariamente raggiungerla) che per qualunque altra ragione, compresa la
pura stupidita`" (W. A. Wulf)
"Dimenticati le piccole efficienze, circa il 97% delle volte: 
l'ottimizzazione prematura e` la radice di tutti i mali" (D. Knuth)
"E` piu` facile ottimizzare il codice gia` corretto che correggere il 
codice gia` ottimizzato.  Il codice corretto non ti sorprende con tanti bug
latenti molto dopo che pensavi di aver finito" (B. Harlan)
"Regole per ottimizzare:
  1. non farlo.
  2 (solo per esperti): non farlo ancora." (M. A. Jackson)
Beh, puo` bastare.  Vediamo piu` analiticamente perche` le cose stanno 
cosi`...
Nei migliori processi di sviluppo, l'efficienza (ottimizzazione) e` 
"l'ultima" considerazione -- non in senso di importanza, in senso temporale:
1. fallo funzionare
2. fallo bello
3. fallo svelto
L'inizio dello sviluppo tipicamente ha le caratteristiche di "prototipo" e 
produce codice, anche di bassa qualita`, ma sufficiente a verificare le
funzionalita` desiderate.  La seconda fase si occupa soprattutto di
qualita` del codice: chiarezza, semplicita`, manutenibilita`.  Se il 
risultato non soddisfa gli obbiettivi di prestazioni, si entra nella terza
fase, che inizia MISURANDO (con un profiler) quali risorse sono consumate e 
da quali parti del programma.  Tipicamente, un 10-20% del codice di un
programma e` responsabile dell'80-90% del suo consumo di risorse, e la
misurazione ci dice quale e` questa parte critica: "se non puoi misurarlo,
non puoi controllarlo".
L'unica eccezione importante a questo schema generale e` nella scelta
di algoritmi e strutture dati (tipicamente in fase 2) che abbiano delle
caratteristiche prestazionali "decenti" -- non necessariamente ottimali
ma non asintoticamente disastrose in termini di notazione O(), che si
usa per indicare appunto le caratteristiche asintotiche di consumo di
risorse.  L'esempio tipico e` con gli algoritmi di ordinamento, dove quelli
"piu` elementari" come bubblesort consumano tempo proporzionale al
quadrato del numero di elementi [O(N**2)] mentre esistono algoritmi
O(N logN).  Il sort (ordinamento) e` un buon esempio anche perche` al
giorno d'oggi l'uso di una buona libreria, gia` ottimizzata per benino, e`
piu` spesso che no la scelta giusta.  Il "micro-ottimizzatore", rimasto
mentalmente al tempo in cui una macchina con 32K parole di memoria
era grossa e costosa, e` capace di preoccuparsi del "costo" di una
chiamata a funzione e trascurare il costo, questo si` enorme, che una
scelta sbagliata degli algoritmi (e strutture dati) comporta particolarmente
nei problemi "veri" (quelli che affrontano i clienti, tipicamente piu` 
grossi di quelli "giocattolo" da usare come test in fase di sviluppo).
Il problema principale dell'informatica (da decenni, ormai) e` quello della
correttezza (bug) e della manutenzione (correzione di bug e aggiunta di
feature).  L'efficienza ha la sua importanza, ma non e` mai al primo
posto.  Se il programma non fa quello che serve al cliente (perche` gli
manca la feature cruciale, o perche` i bug interferiscono) non importa
che fallisca in meta` o un terzo del tempo che impiega un altro programma
che invece il lavoro lo fa.  E` solo fra due programmi entrambi corretti e
funzionalmente completi che puo` interessare quale sia piu` veloce o
consumi meno memoria.  PUO` interessare, non necessariamente
interessa.  Se due programmi interattivi calcolano la stessa cosa, uno
ci mette 100 millisecondi, l'altro, tanto piu` veloce, solo 100 
microsecondi, questo non fa nessuna differenza per il cliente, che
comunque li vede entrambi "istantanei" dal suo punto di vista.  Questo
fenomeno e` gradualmente sempre piu` frequente man mano che i
tipici computer "da due soldi" sono sempre piu` potenti e veloci, e ricchi 
di risorse come la memoria.  Di conseguenza, l'efficienza risulta, con
ogni anno che passa, di sempre minore importanza pratica.
Alex

 ..... 
Grazie del supporto. ;)
...questi 'giovani' d'oggi.... 
8-P
-- 
Luc.

 che invece il lavoro lo fa.
Anche questa avrebbe dovuto essere nelle citazioni: non è tua!
--
Andrea Ferro
IHHC - Member of HT-Group  DVD Authoring operator  Fan of I.Asimov
C++ Master: 
http://www.brainbench.com/transcript.jsp?pid=2522556
This post expresses personal opinions which may or may not be the
opinions of the company(s) I work for. I speak for myself only.

 Anche questa avrebbe dovuto essere nelle citazioni: non è tua!
Possibilissimo, ma se cosi` e`, e` citata "subconsciamente" -- credevo
qui di stare dicendo con parole mie questi concetti certo ovvi (ma non
per tutti, visto che c'e` bisogno di dirli e ridirli).  URL please...?
Alex

 wrote in message
news:DuE58.5990$om6.1...@news1.tin.it...

Ho detto che non è tua perchè l'ho già letta. Ma se sapessi dove l'avrei
già indicato. Non credo comunque che fosse su internet. Credo un libro
(o al massimo una rivista). Comunque l'argomento era esattamente quello
in questione (ovviamente). Ma potrebbe essere stata ovunque. Persino in
un libro di OOAD (magari mischiata alla definizione di Eiffel o alla
spiegazione di cosa significa una nuvoltetta). Potrebbe persino essere
sull'unico testo by-microsoft che, fra le varie cose, comunica anche
qualche concetto intelligente (Code Complete). Oppure su una rivista
americana (DDJ?).
In ogni caso ... materiale di parecchi anni fa.
