[PLUTO-help] [OT] Programmazione

[saint a eng.it]

>>>>> "FV" == Fabio Ven <fabiove a email.it> writes:

FV> E' ormai risaputo che l'uso del costrutto GOTO è "altamente
FV> sconsigliato",

La  definizione  di  Dijkstra  era  "considered  harmful".   Ma,  come
l'arsenico,   nelle  mani   giuste  in   dosi  minime   può   fare  la
differenza. Che la teoria vive nel  mondo delle idee ed i programmi li
eseguono i computer nel mondo reale.

FV> Di fatti se un algoritmo è ben pensato il problema non si porrà
FV> mai.  Questa è una delle primissime regole di programmazione che
FV> mi è stata insegnata.

Infatti, un buon algoritmo scritto  in modo non efficente batterà ogni
algoritmo cattivo scritto in modo efficente (o quasi, che una volta un
geniale algoritmo scritto da Matteo 'athena' Frigo venne battuto da un
algoritmo mattacchione scritto in assembler mascherato da C...).

Ma un buon algoritmo scritto in modo efficente (ovvero limando i tempi
di esecuzione dove veramente serve) è ancora meglio.

FV> Ma il punto è: il costrutto "CONTINUE" all'interno dei cicli non
FV> dovrebbe essere anche'esso sconsigliato?  Per come la vedo io è un
FV> modo più elegante e non pericoloso di scrivere un "GOTO", ma dal
FV> punto di vista stilistico lo trovo molto poco elegante e meno
FV> leggibile di un ciclo ben strutturato, specialmete se il ciclo e
FV> complesso e presenta al suo interno diversi punti di uscita, come
FV> return, break o altri continue.

Prima cosa:  le macchine fanno  i jump. Ovvero  i goto. O le  test and
branch. 

L'eleganza del codice non è nella pedissequa applicazione delle regole
di  strutturazione,  ma nella  formulazione  del  codice più  semplice
possibile, a cui  non puoi togliere nulla. 

Un continue  può portare  ad una scrittura  più semplice,  evitando ad
esempio  un else  che richiederebbe  un blocco  di codice  in  più che
'complica' la codifica  ed in lettura (ricordarsi, stare  dentro le 80
colonne per  quanto possibile!!!) e probabilmente  ance in esecuzione,
sopratutto se  il compilatore non  ottimizza bene. Ma qui  il discorso
oramai  è  difficile,  che  le  architetture  sono  così  dannatamente
complesse che un buon compilatore  è in grado di battere spesso l'uomo
nell'ottimizzazione.

Ad  esempio possiamo avere  un primo  layer hardware  che predigerisce
delle  istruzioni vecchio stile  per farle  elaborare ad  una macchina
RISC  sottostante - nascosta  all'utilizzatore -  che magari  cerca di
estrarre  a runtime  il parallelismo  -è quello  su  cui correntemente
lavora Frigo in Intel.

-- 
 /\           ___                                    Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_____               African word
  //--\| | \|  |   Integralista GNUslamico            meaning "I can
\/                   e coltivatore diretto               not install
                               di software                   Debian"