Una curiosità sulla programmazione oggi.

[sebago]

...il prodotto di una tendenza, largamente promossa in tutti i settori commerciali, mirante a promuovere l'idea che sapere e capire non serve a nulla: basta fare - la pratica val più della grammatica, una pretesa bella vecchiotta ma sempre bella vispa purtroppo!

Mi sembra di sentire l'elogio della "didattica laboratoriale " (non chiedetemi cos'è, per favore) dell'ennesima riforma, colpo di coda della "Buona Scuola" di renziana memoria.

[Piercarlo]

Forse devi dare una pulitina alle orecchie... o agli occhiali. Io sono totalmente contrario alle "pratiche laboratoriali" che mandano la gente a lavorare gratis con la scusa che "devono imparare" (già ampiamente in vigore ben prima che Renzi addirittura nascesse...). E quello che ho detto va in direzione esattamente opposta visto, in sintesi propone il primato della teoria (se c'è naturalmente) su quella della "pratica" che poteva andar bene quando il settanta per cento della popolazione lavorava la terra e nient'altro che la terra per tutta la vita. Oggi non credo proprio che sia un sistema riproponibile...

Mi pare fosse Boltzmann che ha detto più o meno che "non c'è niente di più pratico di una teoria fatta bene" (o qualcosa di molto simile).

[EdmondDantes]

Sul tema del riutilizzo di codice sono parzialmente d'accordo.
Ha senso riscrivere un pezzo di codice già esistente e testato da decine di anni da migliaia di utilizzatori, se non abbiamo avuto una evoluzione teorica tale giustificare questa operazione?
Prendiamo il caso dei pacchetti nominati da DarwinNE.
Esistono centinaia di funzioni scritti in Fortran testati e utilizzati da 40 anni. Possiamo dire con relativa certezza che sono privi di bug (affermazione pesante in questo ambito, lo so). Perché devo riscrivirli se questi pezzi di codice non sono lo scopo del mio lavoro? Aumentarei solo la probabilità di inserire nuovi bug.
Se devo risolvere un problema che richiede di utilizzare il metodo del simplesso, perché devo scrivere anche tale algoritmo se il mio scopo è quello di risolvere il mio problema?
Mi riferisco ovviamente a pacchetti testati e non a quelli scaricati da un forum qualsiasi.

[arkeo2001]

Se ricordo bene persino Matlab si appoggia su alcune routine di linpack, penso che sia tra i rari oggetti software che non possano davvero avere bachi. Un collaudo di quasi 50 anni con un riuso di chi sa quante centinaia di migliaia di girate, se non milioni. Fantastico!

[EdmondDantes]

Ora mi riscrivo la FFT ogni volta che devo svolgere un conto. Assurdo. Sono sicuro però che i diversi partecipanti non si riferissero a questi casi estremi.

Se ho appena finito di studiare una FFT e voglio provare a scriverne il codice posso e devo farlo, ma è solo un esercizio. Per le cose serie mi rivolgo agli avi e ai programmatori di professione.

[Piercarlo]

Tutto questo mi ricordano, in senso lato, le raccomandazioni di prudenza nell'uso di Spice. Se sai cosa stai facendo e che cosa aspettarti va bene. Se usandolo intendi invece fare a meno del lavoro di un ingegnere o addirittura di fare a meno fare delle conoscenze sottostanti il suo lavoro allora no, proprio non ci siamo.

[EdmondDantes]

Che intendi, Piercarlo?

Riferiamoci ad un utilizzatore esperto in grado di programmare, ma non e' un programmatore.
A questo utilizzatore interessa fare un calcolo tramite una funzione presente in linpack, ad esempio. Questo calcolo e' solo un passaggio intermedio: non e' lo scopo del proprio codice.
Non sa come e' stata scritta questa funzione (non e' in grado di capirlo, ammettiamo anche questo aspetto). Sa che con quelli ingressi otterrà quell'uscita. Non puo' riutilizzare quel codice gia' scritto?

[venexian]

Non stiamo parlando di cose astruse: il 'Make-or-Buy Decision' è argomento trattato a tutti i livelli.

In meccanica nessuno si costruisce le viti e neppure i cuscinetti. I supporti dei cuscinetti invece c'è chi li acquista fatti e chi li costruisce come parte della macchina. L'analogia con il software è più che evidente.

Cosa spinge verso una o l'altra via? Il costo, i tempi, l'affidabilità, la precisione, la 'passione' verso il farlo con le proprie mani piuttosto che assemblare lavoro altrui.

In elettronica è più semplice: se escludiamo i trasformatori e poco altro, tutto il resto è necessario acquisirlo da terzi.

Il software, rispetto a un transistor o a un cuscinetto ha però una grande deficienza: la mancanza di standardizzazione e la mancanza di solide specifiche. Tutto ciò che si trova delle librerie è in pratica l'elenco delle funzioni con la loro sintassi, o poco più.

Molti, quando scrivo in assembly per i micro, nelle intestazioni delle funzioni elencano le revisioni, i registri utilizzati, quelli modificati, il numero minimo e massimo di cicli macchina seguendo una propria maschera di riferimento. E' un metodo che funziona bene, ma incorporando anche solo una libreria altrui, questa meticolosità diventa totalmente inutile, e la questione resta aperta.

[EdmondDantes]

Credo che tu sia d'accordo con me, mi pare di capire.
L'esempio di Spice e' fuorviante. In quel caso sto utilizzando un intero programma per svolgere il mio compito, ma in realta' non capisco lo schema circuitale.

Nel mio esempio affermo di sapere cosa sia una trasformata, so che esistono algoritmi in grado di calcolarla, ma non saprei come scriverli in modo efficiente (e priva di bug). Utilizzo il codice gia' scritto e vado avanti.

[WALTERmwp]

Il software, la programmazione, è presente in molti ambiti, diversi tra loro.
In certe realtà spesso non c'è scelta, si prende, si copia, e a volte non si sa bene cosa, si ri-utilizza, l'importante è finire il prima possibile, e se fosse ancor prima sarebbe comunque già oltre i limiti della commessa ... primum vivere, deinde philosophari.
Poi salterà fuori qualche problema, ci saranno dei comportamenti strani, si dovrà intervenire, poi ...
E' un modo "sano" di lavorare ?
No, però, in certe realtà non c'è scelta.

Saluti