On 13/dic/07, at 10:11, Lucio Liberi wrote:
Ho troppa stima di te, Massimo, per non ascoltare i tuoi
suggerimenti. Ed in effetti è esattamente come dici: tecnologie
nuove e metodi obsoleti...
Si è' vero. Devo elaborarlo...
Il fatto è che sono sempre stato abituato ad avere copia cartacea,
ben custodita, di tutto ciò che ho scritto: pensa ho ancora delle
routine in C che compilavo con il primo compilatore C per Mac:
Aztec C della Manx... Altri tempi, altre energie...
Ma tu, come fai con i files scritti con la versione 1.00? Li hai
ancora tutti? Vedi, io ho comperato RB perché mi risolveva quei
problemi di programmazione spicciola che dovevo (che devo)
affrontare nella professione. Non un programma, un applicativo
commerciale, ma un uso riduttivo (ma estremamente produttivo!!!) di
un sistema di sviluppo evoluto, flessibile e moderno. Pertanto, a
volte, sono solo una sequenza di formule e di controlli, che
generano un numero o un disegno... Che però necessitano di
manutenzione.
Mi spiego.
Mi serve un programma per disegnare un profilo ad 'L'. Bene, lo
faccio.
Se solo fossi un po' più figo, scriverei un programma che mi
consentisse di disegnare anche un profilo a 'T'... Non lo faccio
per questioni di tempo...
Ma prima o poi, l'esigenza del profilo a 'T' salta fuori. Quindi
devo riscrivere un altro programmino per il disegno del profilo a
'T'...
Ecco perché a volte mi nasce l'esigenza di andare a ricapare il
listato di quella cosa li'... "Com'è che l'avevo risolta? Aspe'...
Si... Mi sembra...".
Magari problema affrontato 6 anni prima... Sto descrivendo la mia
realtà, con la certezza che tra tutti gli utenti di RB ci sia
qualcuno che come me, non faccia della programmazione la propria
professione, ma solamente strumento di supporto.
Massimo, mi hai indotto ad una profonda riflessione e te ne
ringrazio...
Lucio, innanzi tutto ti ringrazio per la stima e la fiducia. Spero
sia ben riposta.
Vedi, anche se il tuo problema iniziale (i listati) era forse
inadeguato, hai però aperto quella scatola di vermi che è il problema
di obsolescenza dei supporti. E qui la parola "supporto" assume un
valore molto ampio.
Mi spiego meglio.
Un algoritmo, una routine di programma, ma anche una presentazione
creata in PowerPoint (meglio in Keynote), sono tutte creazioni che
descrivono una serie di operazioni per arrivare ad un risultato. Noi
usiamo strumenti diversi per queste creazioni e possiamo
effettivamente utilizzare due strumenti differenti per ottenere lo
stesso risultato. Il caso tipico è un algoritmo che può essere
scritto in differenti linguaggi.
Quando ci troviamo a dover conservare il nostro lavoro, lo
memorizziamo sotto forma di file in un formato che permetta di
aprirlo in un secondo tempo e modificarlo. Ma per fare questo noi
abbiamo bisogno di uno strumento. Nel nostro caso lo strumento è
REALbasic (l' IDE).
Ora RB salva in un formato proprietario le cui specifiche non sono
ufficialmente note e qui nasce un problema: cosa succede se le
successive versioni di RB non sono più in grado di aprire il mio
progetto creato con una vecchia versione? E' impensabile dover
perdere il proprio lavoro per colpa del media, il supporto che lo
contiene. E aggiungo, se io volessi distribuire il mio lavoro ad
altri, in modo che possano esaminarlo senza necessariamente avere RB,
come posso fare?
Questo problema se lo sono ovviamente posto in tanti e non solo
relativamente al linguaggio di programmazione, ma anche in altri
settori. In questo senso RB si discosta dagli altri ambienti di
programmazione che solitamente utilizzano un formato testo classico
per i sorgenti. Ma anche Xcode di Apple ad esempio, utilizza un
formato binario per i files .nib che descrivono l'interfaccia.
La soluzione esiste in definitiva, solo che richiede un poco di
lavoro in più e non è sempre comodissima. Più avanti te la spiego,
ora invece vorrei soffermarmi brevemente su un altro punto del tuo
dilemma: ordinare il codice.
Ora io non è che sia la persona più ordinata del mondo, però ho
imparato a sfruttare quanto più possibile i benefici della
programmazione ad oggetti per risolvere quando possibile il problema
degli spezzoni di codice.
Il fatto è che gli spezzoni di codice sono sicuramente utili, ma di
per se', non sono funzionali perchè riescono a prendere vita solo se
"impiantati" in un contesto. Ma se invece di lasciare qua e la degli
spezzoni si riesce ad organizzare una funzione completa o una classe
per questioni più complesse, allora diventano molto più utili. E' il
concetto della OOP quello di creare oggetti riutilizzabili. E questo
offre il vantaggio di non dover tutte le volte cercare di capire come
funziona un oggetto. Si spende un po' di tempo a creare un oggetto e
a testarlo. Quando questo funziona ci si può dimenticare come è
implementato al suo interno. Basta sapere come ci si interfaccia a
questo oggetto e lo si può riutilizzare. In realtà un problema spesso
lo si risolve creando un'interazione tra molteplici oggetti, e questo
dice che è meglio creare oggetti piccoli, poco specializzati che
possano servire da superclasse di altri oggetti via via più
specializzati. E' come con i mattoncini Lego: quelli piccoli sono
molto versatili perchè più piccoli e incastrabili ovunque. Mentre
quelli più grandi e specializzati sono utilizzabili in un numero di
contesti ridotto.
Ora, pur non conoscendo esattamente il tuo problema, sono abbastanza
sicuro che un simile metodo è applicabile anche al tuo caso.
Costruisciti una libreria di funzioni globali o di piccole classi e
vedrai che quando ti troverai a dover implementare un programma che
disegni il profilo a T oppure anche H o persino C, non dovrai partire
da zero "sbocconcellando" spezzoni di codice qua e la, ma potrai
invece iniziare da un classe intermedia che risolve i problemi base
del disegno di un profilo, e specializzarla creando una sottoclasse
che risolva il problema specifico.
E commenta il codice mentre lo scrivi. Oppure fallo dopo, ma diventa
più lungo e noioso e rischi di non farlo per mancanza di tempo/voglia.
Tornando alla questione dei supporti, oramai anche RB ha la
possibilità di salvare un progetto in formato "version control".
L'esigenza è nata per poter supportare i sistemi di collaborazione
basati su software quali "subversion", ma funziona bene anche come
metodo per archiviare un progetto in un formato umanamente leggibile.
Non è ancora perfetta l'implementazione in RB e mi pare ci sia
qualche problema, ma puoi fare delle prove. Infine c'è anche la
possibilità di esportare il progetto in formato XML. Non è umanamente
leggibile (o lo è solo in parte), ma ha il vantaggio di essere un
formato testo recuperabile e rimaneggiabile anche in un secondo tempo.
Massimo
|